So things are rather more complicated now after the merge.  Let me see if I can clarify some of the different configurations....

There is not really a manual "override" at the moment to force using the millepede constants from the compact file.  

If you are running MC which has run numbers of '0' in the LCIO files, then the compact Millepede numbers will be used.  This is because there is no 'run 0' conditions set for this in the database (I removed this being associated to the 'nominal' alignment because I realized it wasn't a good idea to force MC to use those constants).  So if you're running on simulation data, then there are basically two options available to you.  You can use the conditions force/freeze options via ConditionsDriver to set a run number, and then those constants would be loaded from the database for that run number, e.g. mimicking the alignment constants for a particular run in your MC recon job.  Or you may use the default 'run 0' conditions that are activated, which means the Millepede constants would be read from the compact description, as run '0' has no alignment constants associated to it in the database.

For processing real data, if the SVT detector converter class (now in hps-java) sees a valid set of alignment constants for the active run number in the conditions system, then these will *always* be used, overriding those from the compact detector.  If there are no alignment constants for the run, then it will default to using the ones in the compact description.  Even if you use all the different detector models with the hard-coded SVT opening angles when processing data, it will read from the database if the run number is in there, and the numbers in the compact file will be overridden.  BUT, effectively, I believe this should be fine, because the numbers should match up (e.g. for a 5mm detector model it will find the 5mm opening angle in the db by the run number in the data you are processing).

Finally, when converting to an LCDD file from compact, the database constants will *never* will never be seen, and right now it is not possible to support this.  Because there is not a run number set in the conditions system when that is done, and the conditions system is not initialized.  There is also no switch for the "geometry converter" frontend to set a run nubmer.  So, in this case, the alignment constants would always come from the compact description.  

I am (mildly) against having some kind of "override" option because there is a potential for a mismatch, e.g. if you run a recon job using the override, someone could later on look at your data without the override active.  This would mean that potentially they would see the wrong alignment in their in-memory detector model.  So my opinion is that now it is better if we use the database to activate these alignments automatically when processing/analyzing real data.

If something you are trying to accomplish is now difficult or (hopefully not) impossible because of these defaults, or if something I described seems like incorrect behavior, then please let me know and we will think about how best to make improvements.

Hope things make more sense now!

-----Original Message-----
From: Hansson Adrian, Per Ola 
Sent: Wednesday, May 27, 2015 1:06 PM
To: McCormick, Jeremy I.
Cc: hps-software
Subject: Re: SVT merge is coming


On May 27, 2015, at 11:44 AM, McCormick, Jeremy I. <[log in to unmask]> wrote:

> Hi,
> 
> I'm going to merge in the branches of lcsim and hps-java to their respective trunks for supporting the read of the alignment constants from the database.  From my testing this is working fine and the fallback of using the millepede params from the compact seems to be functioning correctly.
> 

Can you remind us how to override?

> Your local copies of these projects might get weird if you 'svn up' during this so you may want to hold off on updating them until I'm done.
> 
> --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