[Clas12_calcom] database tables

Mon Apr 4 09:09:30 EDT 2016

Hi,
let me say that by proposing to use run numbers as discussed in the 
document, we are not implying we should never use variations for Monte 
Carlo studies. There are cases where the use of a variation would be 
quite natural and maybe the example that Mac made on alignment studies 
is one of them.

However having the possibility of choosing both variation and run number 
gives a certain redundancy that we can exploit:

- as pointed out in the document, physics runs will not start from 1 and 
these will leave a certain range of run numbers that would be free in 
the main database or default variation;

- what we are proposing is simply to use some of these run numbers in 
the default variation to store constants corresponding to particular 
conditions (ideal detector with infinite resolution for example) that 
most detector groups would likely be interested in simulating; it is 
true that we can do the same with a variation but then we should make 
sure that variation, in addition to the default one, would not be 
accidentally altered over time;

- in my opinion the use of run numbers in this fashion should be limited 
to cases that are of general interest for the entire CLAS12 and not only 
for a specific sub-detector: this would also justify the effort of 
collecting constants corresponding to a particular conditions for all 
sub-detectors; if we do so, then to run simulations, let's say, for the 
ideal detector it will be enough to specify the correct run number with 
not need of worrying about the variation;

- more specific conditions as the one of Mac's example on luminosity 
study should in my opinion use a variation since those are interesting 
for a specific detector.

Best regards,
     Raffaella

Mac Mestayer wrote:
> Cole;
>
> We absolutely have to be able to control variations of other
> detector's configurations.  I agree on that.
>
> So let's say we want to understand the effect of geometry
> misalignments.  So we say, "runs 120-160 will be devoted to
> alignment studies".  How is that easier than saying "variations
> named "alignment studies" will be devoted to alignment studies"?
>
> An appropriate use of run numbers is to study run-dependent
> changes to gemc, for example.  So maybe Mauri generates events
> at five different values of luminosity and gives them run numbers
> 121 - 125.  That's fine.  Then you do your luminosity studies
> while changing your cluster-finding algorithms using your variation
> names "little cluster", "medium cluster" and "big cluster" for the
> calorimeters.  And say you want to keep the DC's constant.
> So you use the DC calibrations "nominal" with a fixed time-stamp.
> Then you do your studies and see how your efficiency changes with
> luminosity.  I would argue that you don't want me or the DC group
> to know anything about those run numbers because it gets really
> confusing if we start putting in run-number dependent constants.
>
>                 - Mac
>
> "mestayer at jlab.org", (757)-269-7252
>
> On Fri, 1 Apr 2016, Cole Smith wrote:
>
>>
>> Mac,
>>
>> The discussion about how to use run ranges in MC studies mainly
>> arose to avoid complicated naming schemes for variations.  This
>> was noted as a potential problem in the original CCDB specification
>> document by Mark.  Some of us want to do sector only or layer only
>> variations for calibration systematics studies and may want to exclude
>> other detector variations that introduce unwanted variations. Somehow
>> it has to be made easy to know whose variation does what. So either
>> we impose some naming convention for variations or restrict run ranges
>> to specific combinations.
>>
>> That said, I like the suggestion that run ranges denote broad study
>> categories like luminosity, geometry configurations, KPP or calibration.
>> Perhaps that is a better way to preserve some order and avoid variation
>> proliferation.
>>
>> Cole
>>
>> On Fri, 1 Apr 2016, Mac Mestayer wrote:
>>
>>> Dear CALCOM group;
>>>
>>> Thanks for the concise and well-written guidelines.
>>> They are very good for focussing discussion.
>>>
>>> I agree with most of the 'best practices' advocated, so
>>> I will only mention my two disagreements here:
>>>
>>> 1) sector, layer, component need not be enforced on the
>>> tables (CCDB is much more flexible than CALDB was in this regard).
>>> Not only that, but sector, layer, component is not at all applicable
>>> to the drift chamber data-base.  See 
>>> https://clasweb.jlab.org/wiki/index.php/DC-calibration_Constants
>>> for a description of the DC calibration table structure.
>>> We use indices like region, superlayer or region, superlayer, board, 
>>> connector, etc. and I refuse to call a superlayer a layer, etc.
>>> There is no need to try to enforce a false structure on everyone.
>>>
>>> 2) we should not use run number to denote a variation, such as
>>> Monte Carlo.  This is precisely what variations are designed to do.
>>> Talk to Hall D to find out how they use various variations to denote
>>> Monte Carlo.  In fact, I think we may want to use actual run number
>>> ranges for the Monte Carlo variations to follow, for example, different
>>> luminosities and this proposed use of run numbers will just confuse
>>> people.
>>>
>>>                 regards, Mac
>>>
>>> "mestayer at jlab.org", (757)-269-7252
>>>
>>> On Fri, 1 Apr 2016, Raffaella De Vita wrote:
>>>
>>>>  Dear Harut and Bryan,
>>>>  following the discussion we had on the database, we have collected 
>>>> a set
>>>>  of "guidelines" concerning the calibration constants table 
>>>> structure, the
>>>>  use of variations, the use of run numbers etc.  that we would like to
>>>>  distribute. You can find in attachment the document we have produced.
>>>>  Let us know what you think about it.
>>>>  Best regards,
>>>>     Raffaella
>>>>
>>>>
>>> _______________________________________________
>>> Clas12_calcom mailing list
>>> Clas12_calcom at jlab.org
>>> https://mailman.jlab.org/mailman/listinfo/clas12_calcom
>>>
>>>
>>