 |
 |
As I told you, the driver under discussion (EcalRawConverterDriver) makes the output CalorimeterHit collection iff the input RawCalorimeterHit collection exists. I think this is reasonable behavior for any driver (absence of an expected collection is information that should be preserved), and in this specific case it is necessary for the ECal readout simulation. I don't know what's going on with these problem events, but if there is actually no ECal bank, that should be handled either at the first stage (in the EVIO converter) or the last (in the monitoring/analysis drivers). I don't see why you would want to handle it in the middle of the event processing chain. On Tue, 15 Jul 2014, McCormick, Jeremy I. wrote: > It seems that in the ECAL reconstruction, sometimes the output CalorimeterHit collection is NOT created when there are no RawCalorimeterHit objects present in the event. This means that all Driver process methods should use EventHeader.hasCollection() to check whether a collection exists before using it in the monitoring. Otherwise, errors will occur. > > I personally do not like this, as I feel that it results in a lot of (what should be) unnecessary boilerplate code in Drivers, but I am told that due to some complexities of the ECAL reconstruction and the readout simulation, it might not be easily fixed. Or at least modifying existing recon Drivers in place could be non-trivial. > > I think I'd prefer that all events have exactly the same collections in them after the reconstruction is run on the raw data collections (e.g. the RawTrackerHit and RawCalorimeterHit collections), even if some of the output collections have nothing in them. This was what we determined should be the case for the MDC. This way Driver code, in monitoring or elsewhere, can count on them being there and not causing data access errors when EventHeader.get() is called. > > Anyone have thoughts on this? > > -----Original Message----- > From: McCormick, Jeremy I. > Sent: Tuesday, July 15, 2014 2:55 PM > To: hps-software > Subject: monitoring bug > > Hi, > > I'm trying to work on this bug reported by Maurik... > > https://jira.slac.stanford.edu/browse/HPSJAVA-222 > > As far as I can tell, the app doesn't hang but it crashes after a certain number of events. > > The problem appears to be that a expected hits collection which is read by a Driver is not present actually present in the event. > > Caused by: java.lang.IllegalArgumentException: Unknown event component EcalCalHits > at hep.physics.event.BaseEvent.get(BaseEvent.java:48) > at org.lcsim.event.base.BaseLCSimEvent.get(BaseLCSimEvent.java:104) > at org.hps.monitoring.drivers.ecal.BasicMonitoringPlotsDriver.process(BasicMonitoringPlotsDriver.java:83) > at org.lcsim.util.Driver.doProcess(Driver.java:273) > at org.lcsim.util.Driver.processChildren(Driver.java:284) > at org.lcsim.util.Driver.process(Driver.java:198) > at org.lcsim.util.DriverAdapter.recordSupplied(DriverAdapter.java:74) > at org.freehep.record.loop.DefaultRecordLoop.consumeRecord(DefaultRecordLoop.java:832) > ... 9 more > > Any ideas? I thought we had fixed this long ago. Did something change in the ECAL reconstruction or the EVIO to LCIO builder that would have broken this under certain conditions? (e.g. no ECAL hits) > > --Jeremy > > ######################################################################## > Use REPLY-ALL to reply to list > > To unsubscribe from the HPS-SOFTWARE list, click the following link: > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1 > ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the HPS-SOFTWARE list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1