Print

Print


Hi,

I think it would actually be preferable that uploading the conditions to the database happens when the DAQ settings are changed.  If we need to write a utility to extract this information automatically from the DAQ config into the proper format, it is possible and probably not that hard.  This way when the monitoring app initializes, it will see those conditions in the database and pre-load them in the standard way before event processing starts.  The conditions system is not designed to be updated "on the fly" from the event stream, so I would rather not try and make it do this.

It would require extra work to instead read this information on the fly from the data stream, convert it to a collection of conditions objects, and then update all the relevant Drivers.  In fact, there is no real standard way to do this, as forcing a conditions system update to automatically notify relevant Drivers would not be easy (because the detector and run number would not have changed so a conditions change event could not be propagated automatically).  And the entire system could get pretty confusing if both options were available and simultaneously active with one overriding the other, etc.

So I think we should prefer going through the standard way of doing this by pre-loading the conditions into the database before the run starts, even if it does add an additional step to configuring the ECAL DAQ itself.

--Jeremy

-----Original Message-----
From: Maurik Holtrop [mailto:[log in to unmask]] 
Sent: Thursday, March 05, 2015 4:25 PM
To: McCormick, Jeremy I.
Cc: hps-software; Nathan Baltzell
Subject: Re: ECAL hardware conditions

Nathan and Kyle,

The code that does the trigger verification would need to be modified to make use of these new conditions. 
What would be the best way to fill the conditions tables? 

The monitoring code should probably pick up the values automatically from the EVIO banks, if possible. That will avoid errors when the trigger is changed but the database is not also updated. Alternatively, we can have a small utility that uploads the values to the DB, and whoever changes the trigger settings will need to remember to run this utility as well.

Best,
	Maurik




> On Mar 5, 2015, at 4:10 PM, McCormick, Jeremy I. <[log in to unmask]> wrote:
> 
> Hi,
> 
> As per discussion in the software meeting this morning, I have made new conditions tables for the ECAL hardware gains and calibrations, so that they can be managed separately from the existing analysis-based/offline conditions.  This also means that both types of conditions can be loaded simultaneously in the same job without interfering with each other.  
> 
> There is a test in HPS Java which shows how to read these collections from the database ...
> 
> conditions/src/test/java/org/hps/conditions/ecal/EcalHardwareConditionsTest.java
> 
> Basically, you would use the following code to get the hardware calibration collection ....
> 
> EcalCalibrationCollection calibrations = manager.getConditionsData(EcalCalibrationCollection.class, "ecal_hardware_calibrations");
> 
> And this code would get the gains ...
> 
> EcalGainCollection gains = manager.getConditionsData(EcalGainCollection.class, "ecal_hardware_gains");
> 
> The classes used for gains and calibrations are the same as before, but there is now an entirely separate table for the hardware values.
> 
> Currently, there are only "run 0" collections in the database for these conditions, which have the gains set to 1.0, pedestals to 120, and the noise to 10.  Actual hardware conditions will need to be loaded into the database now.  (I think Nathan is planning to do this.)
> 
> I hope that's clear.  Let me know if you have any questions.
> 
> --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