Print

Print


Hi,

I have merged in all all work that was done on the database conditions
development branch into the trunk.  I was surprised that there weren't any
major conflicts and the merge went smoothly.  Here are a few things to keep
in mind when beginning to work with the new conditions system:

1) The following drivers have been deprecated and will be deleted in the
next couple of days:

BeamSpot.java (Matt this belongs to you, do you want to keep it?)
CalibrationDriver.java (Used to load the flat file conditions)
EcalConditions.java (Old ECal conditions)
FieldMap.java (Matt this belongs to you, do you want to keep it?)
HpsConditionsReader.java (Old engineering run conditions reader)
HPSSVTCalibrationConstants.java (Old SVT conditions)
HPSSVTSensorSetup.java (This will be moved to the HpsSiSensor objects)
StereoPair.java (Has been moved to lcsim)
SvtUtils.java (Replaced by HpsSiSensor)
TestRunConditionsReader.java (Old test run conditions reader)

If anyone has any objections, please speak up.  Otherwise, they will be
removed.

2) The drivers used to load both the engineering and test run conditions
can be found in org.hps.conditions (ConditionsDriver and
TestRunConditionsDriver).  Depending on what type of data you are looking
at, one of these needs to be included in your steering file.  I went ahead
and updated all steering files in

analysis
production
readout
recon

The rest will need to be updated by their owners.  You can look at the
steering files in these folders to get an idea of what needs to be added.

3) Currently, only ideal conditions are loaded into the conditions database
for the engineering run.  They are loaded as run number 0 in order to
remain compatible with all mock data.  Unfortunately, this also means that
if you have generated MC data with a random run number assigned to it, the
conditions system will fail to find a suitable conditions set and fail.  I
doubt anyone has done this, but contact me if you have this issue.

  For the test run, most of the conditions that were present in the flat
files have been loaded.  The validity range for these conditions is run
0-1365. At some point, some ideal conditions for the test run will also be
loaded (I don't think it's urgent).

4)  At the moment, since we are denoting ideal MC conditions as run 0 (not
set in stone), this doesn't allow us to load multiple ideal conditions sets
without causing conflicts.  Jeremy and I are working on using tags to
resolve this.

This also means that a user wont be able to change the detector conditions
easily, as that would require modifying the conditions database.  We should
discuss the procedure for requesting the loading of a new ideal conditions
set at some point soon.  We probably should have subsystem conditions czars
that review, approve and load the conditions in order to avoid clobbering
the conditions database.

5)  For those working with the SVT, all conditions are now encapsulated by
an HpsSiSensor/HpsTestRunSiSensor objects.  Please refer to the API for the
details (or talk to me).  The sensor objects also contain information about
their position, orientation etc. I'll talk about this on Thursday.  I'm not
sure if there is something similar for the ECal.  I'll let Sho comment on
this.

6) The EVIO to LCIO converters used for the test run are currently broken
when processing SVT data.  I decided it was a bad idea to hack the
converters in order to provide a temporary fix, especially since the
converters are going to get partially rewritten soon.

7) For now, running the new conditions system requires an internet
connection.  Jeremy and I will work on a solution to allow users to load a
local database.

8) If you have some drivers in your local working copy that use the old
conditions, they will need to be updated.  I would start by looking at
other users drivers to get an idea of how to do this.  Otherwise, contact
Sho, Jeremy or myself.

9) Jeremy made a backup branch which still uses the old conditions system.
I don't recommend using this branch, especially since any changes committed
to the branch will need to be merged into the trunk (not going to happen,
unless you manually merge).  This branch will mainly be used to reproduce
old results if needed.

For the most part, working with data should be business as usual.  I'll try
to provide some examples on working with SVT data on Thursday.  Feel free
to send around any questions that may come up.

--Omar Moreno

########################################################################
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