Thanks Jeremy,
Sounds to me like there is too much overhead to bother caching conditions from non-Driver classes.
And that there should be only one instance of the conditions that everyone can read from.
-Nathan
On Jan 12, 2015, at 8:18 PM, "McCormick, Jeremy I." <[log in to unmask]> wrote:
> Hi, Nathan.
>
> To answer the question about caching conditions from non-Driver classes….
>
> If the object is an instance variable on a Driver, you can simply push information into it from Driver.detectorChanged() using “set" methods etc.
>
> Or if you want more direct access, the non-Driver class may implement ConditionsListener from the lcsim conditions API, which is what Driver actually uses behind the scenes, e.g. something like
>
> import org.lcsim.conditions.ConditionsEvent;
> import org.lcsim.conditions.ConditionsListener;
>
> class MyConditionsListenerClass implements ConditionsListener {
>
> public void conditionsChanged(ConditionsEvent conditionsEvent) {
> // Do something with conditions here.
> }
> }
>
> And then it would need to be created and registered with the conditions system….
>
> MyConditionsListenerClass listener = new MyConditionsListenerClass();
> DatabaseConditionsManager.getInstance().registerConditionsListener(listener);
>
> Your class could then access and/or reset the conditions information in the overridden method.
>
> You have to be careful with this though, because you have to register the listener before the conditions system actually initializes, or obviously you will not then catch the change. You could do this, for instance, in a Driver’s constructor, because the Drivers are all created before the detector is initialized.
>
> You could probably also do this in startOfData() because that is called before detectorChanged() though I probably wouldn’t rely on this. (Haven’t checked this recently but I think it would work.)
>
> —Jeremy
>
> On Jan 12, 2015, at 5:00 PM, Nathan Baltzell <[log in to unmask]> wrote:
>
>> 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
