[Clas12_calcom] database tables

[Raffaella De Vita]

Hi Cole,
in the discussion we had on Friday, it came out that what would be 
useful to have in the DB (to remove hard coded parameters from 
calib/monitor code) are the pedestal and pulse ranges that the decoder 
uses to get the pulse charge for mode 1 data.
If necessary, we can also add the windows parameters but, if I 
understood correctly, these are not needed to decode the data.
Regards,
     Raffaella

Cole Smith wrote:
>
> I wasn't at the meeting but Nick's original question referred
> to the capture window parameters.  I would suggest window_offset and 
> window_width instead of pulse, to avoid confusion over the meaning.
> Using fixed pulse integration windows could be dangerous.
>
> Cole
>
>
> On Mon, 11 Apr 2016, Raffaella De Vita wrote:
>
>> Dear All,
>> following Nick's question and the discussion we had last Friday, I 
>> edited the document (see attachment) to reflect the proposed change 
>> to the /daq/fadc table that would now also contain the parameter for 
>> Mode 1 analysis. The proposed names are pedestal_start, 
>> pedestal_width, pulse_start, pulse_width .
>> Comments are welcome.
>> Best regards,
>>     Raffaella
>>
>> nick markov wrote:
>>>  Dear CALCOM group,
>>>  I wonder if it possible and needed to add to the DAQ parameters tables
>>>  parameters of MODE1 readings:
>>>  FADC250_W_OFFSET
>>>  FADC250_W_WIDTH
>>>  Nick.
>>> >  On Apr 1, 2016, at 11:09 AM, Mac Mestayer <mestayer at jlab.org> 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
>>
>>
>>