[Clas12_calcom] database tables

[nick markov]

Dear all,
these are not part of the decoder, but in my opinion in would be convenient to have them stored somewhere other than fadc configuration file.
Nick.
> On Apr 11, 2016, at 11:09 AM, Raffaella De Vita <Raffaella.Devita at ge.infn.it> wrote:
> 
> 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
>>> 
>>> 
>>>