Any text based conditions which are currently being used on the trunk and are not present in the database should be ported to the new API, if it is determined they are still needed and not duplicating something in the db. This involves adding a few classes to the conditions API, creating the database table with the conditions information, and then adding a conditions record with a valid run number. This sounds complicated but it isn’t really that hard to do, though the procedure is not documented. (I will add conditions doc to our Confluence when I get a chance.)

If there are specific requests in this area, I can work on them given enough information about the conditions and what the API methods should look like to access the data.

The “official” B-field currently comes from the detector and cannot be retrieved via run number. This is probably a design flaw of lcsim that we will need to work around or fix. I think we probably do need to add a way to get the B-field from the database so that we can at least store this information by run number, even if it is not fully integrated into the recon until later. This will make sure that at least the information is there. I would need to know exactly what information you want to store here, e.g. is it a single number? Or would it be planned that we would have B-field measurements at more than one point? etc.

I did not have a great deal of information about what beam conditions were going to be stored for the run, so currently there is only a set of beam current measurements from the test run, which is basically only used for testing purposes. If you can identify for me the beam conditions that should be stored in the database, I would like to rework this part of the API. I think it would make sense if there were a single database table containing all this information (beamspot position, beamspot covariance, beam current, etc). Once we decide upon the beam information that we will need later in recon, then this should be added to the API so it is easily retrievable by run number.

On Nov 3, 2014, at 8:11 AM, Mathew Graham <[log in to unmask]> wrote:

BeamSpot.java (Matt this belongs to you, do you want to keep it?)

Mathew Graham:

Is there another class that holds the beamspot position & covariance?

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?)

Mathew Graham:

This read in the B-field from a text file...probably Norman/Jeremy use something else so probably this can go.

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