[Clas12_calcom] database tables

Raffaella De Vita Raffaella.Devita at ge.infn.it
Thu Apr 14 04:49:51 EDT 2016


Hi Cole,
I understand your concerns: let's talk about this at the CalCom meeting 
on Friday.
Regards,
     Raffaella

Cole Smith wrote:
>
> 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
>>



More information about the Clas12_calcom mailing list