 |
 |
Thanks Jeremy, See my new comments within: On Jan 12, 2015, at 7:29 PM, "McCormick, Jeremy I." <[log in to unmask]> wrote: > Hi... > >> I have a channel_id and I want to get the corresponding pedestal from the >> conditions database. I have a cached instance of EcalConditions. Here's >> what I managed to figure out that works: >> >> ecalConditions.getChannelConstants(ecalConditions.getChannelCollection().findChannel(channel_id)).getCalibration().getPedestal(); > > Is channel ID here the sequential 1-442 number? Or is it a cell ID from the hit? (I think it must be the first. Otherwise it wouldn’t work!) Yes, it is the former, the unique 1-442 number. > That seems like an okay way to do it. You could add this as a utility method someplace e.g. EcalConditions.findPedestal(channelID) if this needs to be called from multiple places. The method chaining is a bit ugly I guess. (It might look a little simpler if you were using directly the EcalCalibrationCollection instead of EcalChannelConstants which is basically just > provided for convenience.) Yes, a helper method will be nice, maybe later. >> Also, maybe related to Luca's issue, what happens if the run number changes? >> Will a cached EcalChannelCollection and/or EcalConditions need to be updated manually? > > If a new run number is encountered in the same job, the conditions system is completely reset, and new conditions are loaded, as well as a new detector object. You can catch this via the Driver.detectorChanged() API method. So basically once you have cached a collection reference, it is only valid for that run. If you get notified of new detector conditions, then the Driver should update itself accordingly, including setting a reference to the new collection object. > Ok, this sounds important. Should only classes inherited from "Driver" ever store conditions stuff across events? And then do they automatically inherit the ability to catch the detectorChanged() method and update their conditions accordingly, or does it need to be done manually? Thanks, Nathan >> >> -Nathan >> >> >> On Jan 11, 2015, at 10:06 PM, "McCormick, Jeremy I." <[log in to unmask]> wrote: >> >>> This util method should do that >>> >>> EcalChannel channel = EcalConditionsUtil.findChannel(IIdentifierHelper helper, long cellId); >>> >>> where >>> >>> helper = subdetector.getDetectorElement().getIdentifierHelper(); >>> >>> There should be a few examples of it in the code. >>> >>> Or you can call >>> >>> EcalChannelCollection.findGeometric(hit.getCellID()); >>> >>> if you have the EcalChannelCollection cached. >>> ________________________________________ >>> From: [log in to unmask] <[log in to unmask]> on behalf of Nathan Baltzell <[log in to unmask]> >>> Sent: Sunday, January 11, 2015 3:09 PM >>> To: hps-software >>> Subject: hit channel_id >>> >>> If I have a RawCalorimeterHit object, and I want the corresponding channel’s unique >>> channel_id from the database. I came up with this that seems to work (in that it looks >>> like it’s always between 0 and 441, but I didn’t check it any more than that): >>> >>> findChannel(hit.getCellID()).getCalibration().getChannelId() >>> >>> Does anyone know if it is correct? >>> >>> -Nathan >>> ######################################################################## >>> 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 > ######################################################################## 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