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
