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