[Halld-cal] BCAL Reconstruction Meeting Minutes 2015-04-30

Elton Smith elton at jlab.org
Fri Aug 28 17:16:59 EDT 2015


Hi Richard,

 From my point-of-view, having hdgeant4 supporting only mode 3 is fine. 
This is essentially the decision we made with the recent updates to 
hdgeant3. In principle mode 2 provides a more detailed microscopic 
description of the generation of BCAL pulses, but we found that our 
implementation was incomplete and would require substantial effort to 
make it match existing data.

We do want to make sure that we understand what is being included in the 
MC, so it would be good for you to give us an update at one of our BCAL 
reconstruction meetings.

Thanks, Elton.

Elton Smith
Jefferson Lab MS 12H3
12000 Jefferson Ave STE 4
Newport News, VA 23606
(757) 269-7625
(757) 269-6331 fax

On 8/28/15 3:35 PM, Richard Jones wrote:
> Hello Tegan,
>
> I am setting up to implement the readout of BCal hits in hdgeant4, and 
> I have a question about which mode of output you want me to support. 
> The hddm output record defines several different styles for recording 
> event output:
>
>  1. bcalSiPMupHit/bcalSiPMdownHit - these are marked "obsolete" in the
>     template
>  2. bcalSiPMSpectrum - introduced to try and understand the role of
>     noise in the fADC stream
>  3. bcalADChit / bcalTDChit (and their "digi" counterparts) - probably
>     the closest to what the DAQ actually produces.
>
> If I had my druthers, I would only support output from hdgeant4 in 
> mode 3, and not modes 1 or 2. If I were to do that, would there be 
> significant information lost that you would like to recover? Would you 
> like to have both modes 2 and 3 available, selectable by an option in 
> control.in <http://control.in> or something like that? Or is mode 2 
> pretty much obsolete as well?
>
> Anyone else in the calorimeter working group that has an opinion on 
> this should feel free to respond to my question as well, but I 
> understand from Justin that Tegan is probably the man to ask.
>
> -Richard Jones
>
> On Thu, Apr 30, 2015 at 4:47 PM, Elton Smith <elton at jlab.org 
> <mailto:elton at jlab.org>> wrote:
>
>     Hi Tegan,
>
>     Sorry we missed the meeting this morning. I will try to provide
>     answers/comments where I can. Others can also provide feedback.
>
>     = New code =
>     * Poisson statistics smearing still needs a value for the energy
>     of one dark hit.
>
>     Attached is a script and plots of a single pixel firing, with the
>     normalization of summed energy of 0.31 MeV/pixel. Note, however
>     that his depends on several factors. This is an average value for
>     energy deposited in the middle of a module. Of course the actual
>     amount of energy deposited with that amplitude will depend on the
>     position of the energy deposition. Also, I have used a gain factor
>     of 0.046 MeV/integral count. But these vary quite a bit from cell
>     to cell. See Will's log entry detailing the gain factors obtained
>     for the fall run:
>     https://logbooks.jlab.org/files/2015/03/3328508/BCAL_Calib_Update_Mar20.pdf.
>     However, the question itself regarding what energy corresponds to
>     a single pixel is a little misleading. If one is simulating dark
>     hits (i.e. single pixels), these do not correspond to energy per
>     se but rather an amount of charge into the FADC. This is better
>     characterized by the number of FADC counts that correspond to one
>     pixel firing (see figure). This is independent of attenuation
>     length. It is does depend on the gain of the sensor and
>     electronics. However, there are many contributions to the "gain"
>     or conversion from counts to MeV. For example, the
>     acceptance/transmission of the light guides contributes to the
>     overall gain factor and this has nothing to do with the size of
>     the single pixel. Therefore, it might make more physical sense to
>     simulate the dark hits with minimal dependence on each channel. If
>     we operate the SiPMs at the same over bias, this should correspond
>     to the same gain for all sensors. Therefore, the large variation
>     we are seeing in "gains" may not be primarily due to the actual
>     sensor gains themselves.
>
>     Hope this gives you sufficient information to think about how to
>     move forward.
>
>     * What should we use for an energy threshold to write out events? 
>     A 4 mV threshold was used before.  4 MeV?
>
>     The threshold should be given in counts, which corresponds to the
>     DAQ threshold of 105. The pedestal is nominally at 100, so 5
>     counts above pedestal. We are using the 2 V scale on the FADCS,
>     which are 12 bits, so one count = 0.0004884 V. Therefore 5 counts
>     is 2.44 mV assuming the pedestal does not drift. Of course it
>     does, so another question is whether we wish to include pedestal
>     drifts in the simulation. Generally one tries to setup hardware,
>     so the software can ignore such details, but this may not be
>     possible in this case.
>
>     In any case, the thing to do is to convert the energy deposited
>     into counts, use the pulse shape I have provided (or your own
>     favorite) to convert this into fADC counts. The threshold would be
>     applied to this pulse train.
>
>
>     * The change to the data structure will be just adding
>     'incident_id="int"' to 'bcalTruthHit.'
>
>     Others with more expertise should comment on this one.
>
>     ** If we don't change the data structure, we'll change bcal_index
>     in the code and get rid of the incident particle filling.
>     ** I'd prefer changing the data structure, since we'll eventually
>     want to implement incident particle dependent smearing (I assume),
>     and it seems relatively easy to do it now.
>
>     * Time smearing: the time resolution in the code for the fADC is
>     stated as 4 ns / sqrt(12).  This was used before because we were
>     using 0.1 ns bins rather than 4 ns bins.
>
>     This is probably an old guess based on assuming the time coming
>     from the fADC comes from picking the first FADC sample above some
>     some threshold. We are doing much better than this by essentially
>     finding the time at half height. The resolution for this is about
>     0.2 - 0.3 ns, but Mark can probably provide a better number. I
>     suggest you put in a value based on Marks latest studies and we
>     can adjust it as more studies are done.
>
>     ** Is this value what we'd want to use for smearing a single truth
>     time?
>
>
>     = Old code =
>     * We need to decide whether or not we want to keep this method
>     available for people to choose to use.
>     * If we do keep it:
>     ** Need to find a value for the energy of one dark hit that causes
>     waveforms to more closely resemble data and also that gives
>     reasonable pedestal variation.
>
>     Using the attached scritps used for the pedestal studies, I think
>     we a first stab at this.  See GlueX-doc-2695
>     http://argus.phys.uregina.ca/cgi-bin/private/DocDB/ShowDocument?docid=2695
>     You can find all the scripts in the tar.gz file. If there is
>     anything missing, let me know and I can make it available.
>
>     ** By fixing an electronic noise smearing, then altering the dark
>     hit energy, it looks like we want something like the current
>     energy divided by 10 or so.
>     ** It should be easy to set the dark hit energy based on what
>     amplitude in mV we want the dark pulses to have, if we have any
>     feeling for that (1 mV amplitude ~ 1 MeV energy deposition).
>
>     See the notes and GlueX notes above, which should provide good
>     answers to these questions.
>
>
>     Elton Smith
>     Jefferson Lab MS 12H3
>     12000 Jefferson Ave STE 4
>     Newport News, VA 23606
>     (757) 269-7625 <tel:%28757%29%20269-7625>
>     (757) 269-6331 <tel:%28757%29%20269-6331>  fax
>
>     On 4/30/15 1:12 PM, Zisis Papandreou wrote:
>>     Hi folks:
>>
>>     the minutes from our short meeting this morning have been posted:
>>     https://halldweb.jlab.org/wiki/index.php/BCAL_Reconstruction_Meeting_2015-04-30
>>
>>     Please note that since there was a controlled access in the hall
>>     at the same time as the meeting, JLab was not able to join us. 
>>     Therefore, we posted Tegan's questions on HDGEANT and mcsmear on
>>     the Wiki (see above minutes). I've placed this discussion at the
>>     top of the agenda of next week's Calorimetry meeting, as it is
>>     important to progress on this and complete the tasks.  Will L.
>>     will also join us for next week's meeting.
>>
>>     We are hoping that after the commissioning ends on Monday, folks
>>     will have a chance to read this list so that we can decide upon
>>     the items and move forward.
>>
>>     I also posted the minutes from the April 16 meeting:
>>     https://halldweb.jlab.org/wiki/index.php/BCAL_Reconstruction_Meeting_2015-04-16
>>
>>     Thanks and cheers, Zisis...
>>
>>     Dr. Zisis Papandreou
>>     Professor of Physics, Ph.D., P.Phys.
>>     ---------------------------------------------------------
>>     Department of Physics
>>     University of Regina
>>     3737 Wascana Parkway
>>     Regina, SK  S4S 0A2 CANADA
>>
>>     *Phone: (306) 585-5379 <tel:%28306%29%20585-5379>*
>>     Fax: (306) 585-5659
>>     Email: zisis at uregina.ca <mailto:zisis at uregina.ca>
>>     Website:
>>     http://www.uregina.ca/science/physics/people/faculty-research/zisis-papandreou/index.html
>>
>>
>>
>>
>>
>>
>>
>>     _______________________________________________
>>     Halld-cal mailing list
>>     Halld-cal at jlab.org <mailto:Halld-cal at jlab.org>
>>     https://mailman.jlab.org/mailman/listinfo/halld-cal
>
>
>     _______________________________________________
>     Halld-cal mailing list
>     Halld-cal at jlab.org <mailto:Halld-cal at jlab.org>
>     https://mailman.jlab.org/mailman/listinfo/halld-cal
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-cal/attachments/20150828/8618d309/attachment-0001.html>


More information about the Halld-cal mailing list