[Clas12_calcom] database tables

Sat Apr 16 14:09:12 EDT 2016

Hi Nick,

I propose renaming the FPGA tables /daq/fadc/mode7/<detector> since the 
firmware settings NSA,NSB,TET,PEDESTAL apply in that mode.  Also Gagik's
decoder needs these settings to supply the user with pedestal subtracted
adcs.

For mode1 data only TET and PEDESTAL apply, but PEDESTAL is used 
only to set the proper threshold (TET+PEDESTAL).  For mode1 data the user
should have several options available from the decoder:

1) Supply the raw samples without any processing.

2) Emulate mode7 using NSA,NSB,TET,PEDESTAL from 
/daq/fadc/mode7/<detector>.

3) Emulate mode7 with user supplied NSA,NSB,TET,PEDESTAL (for testing?).

4) Fixed width pulse and pedestal windows with user supplied constants.

Customized parameters from 3) or 4) would be eventually stored in 
/daq/fadc/mode1/<detector>, as you suggested in your previous email.
Probably during commissioning we will need to take lots of mode 1 data
to disk anyway to allow fine-tuning these custom parameters.  For physics
running we may have a mixture of mode7 and mode1 data.

Cole

> Dear Cole,
> since I assume that several detectors will use Mode1 table we can create a separate directory with tables like:
> /daq/mode1/htcc
> /daq/mode1/ltcc
> etc.
> I am not sure I fully understand difference between custom fitter and FPGA constants:
> FPGA contains things like NSA, NSB, TET, etc and are currently stored in
> /daq/fadc/ec
> /daq/fadc/ltcc
> What will table for a custom fitter contain?
> Nick.
>
>> On Apr 15, 2016, at 8:11 PM, Cole Smith <lcs1h at imap.phys.virginia.edu> wrote:
>>
>>
>> Nick,
>>
>> To be clear, are you proposing to create a /daq/fadc/mode1 directory tree which would contain the htcc table?  I think this might be a
>> good idea to have /daq/fadc/mode1 and /daq/fadc/mode7 subdirs to cleanly
>> separate the custom fitter and firmware/FPGA constants. Especially if
>> we have a mixture of mode1 and mode7 data, Gagik's fitter will know just
>> from the bank type which table to use.
>>
>> Cole
>>
>>
>> On Fri, 15 Apr 2016, nick markov wrote:
>>
>>> Hi,
>>> As we agreed during meeting I have created a Mode 1 parameters table in the test area:
>>>
>>> https://clasweb.jlab.org/cgi-bin/ccdb/show_request?request=/test/cchv_markov/daq/mode1/htcc:0:default:2016-04-15_13-23-30 <https://clasweb.jlab.org/cgi-bin/ccdb/show_request?request=/test/cchv_markov/daq/mode1/htcc:0:default:2016-04-15_13-23-30>
>>> If it looks ok I will move to to a real /htcc/daq/ area.
>>> Best regards, Nick.
>>>> On Apr 14, 2016, at 4:49 AM, Raffaella De Vita <Raffaella.Devita at ge.infn.it> wrote:
>>>>
>>>> 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
>>>>>>
>>>
>>>
>
>