[Clas12_calcom] database tables

[Cole Smith]

Hi Raffaella,

I agree with your points.
My main concern is with physics triggers rather than self-triggering
cosmics.   We don't yet know the how much time jitter the capture window
will have, due to various propagation times and cluster reconstruction
latencies.  When FTCAL is the trigger is shouldn't be a problem.  But if 
the FADC window offset changes for any reason (such as different 
trigger configurations) detectors that use fixed integration windows will 
need to know that offset to compensate.  So Nick's question should
be addressed.

Cole


On Tue, 12 Apr 2016, Raffaella De Vita wrote:

> Hi Cole,
> for Mode 1 my preference would be to keep the options of emulating mode 7 or 
> working with fixed windows. For small signals with small time jitter (this is 
> the case of FTCAL cosmic signal that are barely above noise) it may be 
> convenient to work with fixed pulse integration windows. In addition, if I'm 
> not mistaken, in mode 7 pedestals are calculated only using 4 samples that 
> may not be sufficient when the signal/noise ratio is small.
> Regards,
>     Raffaella
>
> Cole Smith wrote:
>>
>>  The FADC250 firmware parameters are already in the datastream, which is
>>  where the decoder should ultimately look to configure itself. However if
>>  we decide to run in Mode 1 it is my opinion the decoder should emulate
>>  Mode 7 pulse integration rather than use fixed pulse integration windows.
>>
>>  Cole
>> 
>>
>>  On Mon, 11 Apr 2016, nick markov wrote:
>> 
>> >  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
>> > > > > 
>> > > > > 
>> > > > > 
>> > 
>> > 
>>> _______________________________________________
>> >  Clas12_calcom mailing list
>> >  Clas12_calcom at jlab.org
>> >  https://mailman.jlab.org/mailman/listinfo/clas12_calcom
>> > 
>
> _______________________________________________
> Clas12_calcom mailing list
> Clas12_calcom at jlab.org
> https://mailman.jlab.org/mailman/listinfo/clas12_calcom
>