[Halld-cal] BCAL objects in DANA

Fernando J. Barbosa barbosa at jlab.org
Fri Feb 12 11:55:41 EST 2010


I Eugene,

I agree. The simulations should also address the number of photons 
expected on each SiPM and on the summed arrays because of dynamic range 
issues.

Best regards,
Fernando




Eugene Chudakov wrote:
> An off topic comment on combining the photodetectors:
>
> radial summing seems reasonable for the inner 6 layers
> of the detectors, but is not obvious for the outer 4 layers.
> I would try to combine the outer layers in groups 2x2.
> It may happen that the shower will spread to fewer
> readout channels.
>
> We should simulate the energy resolution for these two options,
> taking into account the noise in SiPMs.
>
> Eugene
>
> On Fri, 12 Feb 2010, Fernando J. Barbosa wrote:
>
>> Hi Beni,
>>
>> The present plan is to get sums of three inner SiPMs and sums of  
>> four outer SiPMs, all radially. This is not fixed yet but budgets 
>> don't allow for finer granularity.
>>
>> Best regards,
>> Fernando
>>
>>
>>
>> Beni Zihlmann wrote:
>>> Hi All,
>>> there is one more point to consider. Since we decided to go for SiPM 
>>> we also want to sum up signals from the SiPMs before
>>> digitization. As a consequence there will be no direct relation 
>>> between the "True Hit" in a cell (single SiPM) from geant and
>>> the digitization which has to be done after summing several SiPM 
>>> first. I am not sure if the exact number of SiPM that need
>>> to be summed is already fixed or not.
>>>
>>> cheers,
>>> Beni
>>>
>>> Hi David,
>>>
>>>> Sure there are "two levels" of truth information, I don't much see 
>>>> the point in having cell-level truth information though other than 
>>>> its one time use for doing digitization.  Practically, if I want to 
>>>> know anything about resolution then I need the DBCALTruthShower, 
>>>> which *is* well named to correspond with DBCALShower.  Comparing 
>>>> these two objects will tell me interesting things like my shower 
>>>> resolution and efficiency (this is why we have truth information 
>>>> for the user).
>>>>
>>>> I'm not sure what your suggestion is... if you want to get rid of 
>>>> HDDM in the name then simply renaming the class DHDDMBCALHit to 
>>>> DBCALTruthHit can be done.  I think don't see any problem with the 
>>>> name and organization of the other classes though, with the 
>>>> exception that eventually the source of DBCALHit should come from 
>>>> mcsmear and not the DBCALMCResponse_factory.
>>>>
>>>> -Matt
>>>>
>>>>
>>>> On Feb 11, 2010, at 5:10 PM, David Lawrence wrote:
>>>>
>>>>
>>>>> Hi Matt,
>>>>>
>>>>>     I'm invoking the 3-e-mail exchange rule and cc-ing this to the 
>>>>> halld-cal list....
>>>>>
>>>>>
>>>>>     Perhaps it's just semantics. I see 2 levels of "truth" 
>>>>> information. The first is the energy of the photon incident on the 
>>>>> calorimeter and the second is the energies deposited in the 
>>>>> individual detectors. The pre-smeared energy in the individual 
>>>>> detector represents the "true energy deposited", but does not 
>>>>> represent the "measured energy". Since it is unrealistically good, 
>>>>> we should tag it as such. The string "HDDM" is really unrelated to 
>>>>> whether the data is "truth" or "digitized" so doesn't serve that 
>>>>> purpose very well.
>>>>>     We currently have the incident photon energy in 
>>>>> DBCALTruthShower (which is not particularly well named either 
>>>>> since it contains only information that exists prior to the shower 
>>>>> occurring). Nonetheless, DBCALTruthHit doesn't overlap with that 
>>>>> name and would seem, at least to me to be fairly descriptive of 
>>>>> the information it contains.
>>>>>
>>>>>     The FCAL actually ends up having 3 objects:
>>>>>
>>>>> DFCALTruthShower
>>>>> DFCALHit:TRUTH
>>>>> DFCALHit
>>>>>
>>>>> The DFCALHit object is used for both "truth" hits (DFCALHit:TRUTH) 
>>>>> and "digitized" hits (DFCALHit). This is possible since there is a 
>>>>> 1-to-1 correspondence between the information coming from hdgeant 
>>>>> and the digitzed values used in the reconstruction. The BCAL, as 
>>>>> you say, has a single hit coming from hdgeant that must be turned 
>>>>> into 2 hits before starting the reconstruction. This means you 
>>>>> can't really recycle classes in the same way. The point being, 
>>>>> however, that there are effectively 3 objects in the FCAL as well. 
>>>>> The DBCALTruthHit would then just correspond to DFCALHit:TRUTH.
>>>>>
>>>>> Regards,
>>>>> -David
>>>>>
>>>>>
>>>>>
>>>>> Matthew Shepherd wrote:
>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>> I"m not sure 1 is possible.  The truth hit and hddm hit are 
>>>>>> fundamentally different things.  Truth hit is the location of a 
>>>>>> true photon that struck the BCAL, more like a truth _shower_, 
>>>>>> while HDDM hit is the energy deposition from GEANT in a single 
>>>>>> cell.  This then energy deposition then has to be turned into two 
>>>>>> hits, one for upstream and one for downstream sensors.  I agree 
>>>>>> this would be better done in 1.
>>>>>>
>>>>>> I don't think the FCAL code behaves as you say.  Note there are 
>>>>>> two classes in FCAL also:  DFCALTruthShower and DFCALHit.  This 
>>>>>> again, is the fundamental difference between energy deposition in 
>>>>>> a cell and clustered hits, which represent actual photons (which 
>>>>>> can then be compared to truth information).
>>>>>>
>>>>>> Moving code to mcsmear is a good idea.  I think I volunteered to 
>>>>>> do that, once we had an agreement on how MC smear would handle 
>>>>>> the fact that the class it read in DBCALHDDMHit (1 instance per 
>>>>>> cell) has a different structure than the class it writes out 
>>>>>> DBCALHit (2 instances per cell).
>>>>>>
>>>>>> -Matt
>>>>>>
>>>>>> On Feb 11, 2010, at 1:54 PM, David Lawrence wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>>     IMHO the "HDDM" was intended to indicate some type of 
>>>>>>> low-level information that is contained directly in the HDDM 
>>>>>>> file. I would suggest that to be more consistent with our 
>>>>>>> current naming conventions that we do one of the following:
>>>>>>>
>>>>>>> 1. Rename "DHDDMBCALHit" to "DBCALTruthHit". This follows our 
>>>>>>> agreed upon (and often not followed) convention to include the 
>>>>>>> word "truth" in the names of objects that carry information that 
>>>>>>> will not be available in the real data.
>>>>>>>
>>>>>>> 2. Re-tool things to follow the scheme used for the FCAL where 
>>>>>>> there is only one class, DFCALHit, but the un-smeared objects 
>>>>>>> have the tag "TRUTH" and the smeared ones have no tag. This may 
>>>>>>> not be as easy (or even desirable) for the BCAL due to the 
>>>>>>> double ended readout.
>>>>>>>
>>>>>>> I would volunteer to implement 1. if there was general 
>>>>>>> agreement. Implementing 2 would be better done while moving the 
>>>>>>> smearing code from the reconstruction into mcsmear since it 
>>>>>>> involves a little more manipulation so I'm not quite 
>>>>>>> volunteering for that yet.
>>>>>>>
>>>>>>> Again, just my opinion.
>>>>>>>
>>>>>>> Regards,
>>>>>>> -David
>>>>>>>
>>>>>>> Zisis Papandreou wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Hello Matt:  thanks for clarifying this.  Cheers, Zisis...
>>>>>>>>
>>>>>>>> On 2010-02-10, at 8:11 PM, Matthew Shepherd wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> DBCALHit is the thing that most clearly resembles raw data. as 
>>>>>>>>> this is effectively the signal coming out of a photosensor.  
>>>>>>>>> However, DHDDMBCALHit cannot be dropped since it is needed to 
>>>>>>>>> deliver the energy deposition in a cell (what Geant actually 
>>>>>>>>> tracks) to the framework.  In the framework, the 
>>>>>>>>> "digitization" process is completed and the DBCALHit objects 
>>>>>>>>> are produced.
>>>>>>>>>
>>>>>>>>> -Matt
>>>>>>>>>
>>>>>>>>> On Feb 10, 2010, at 6:21 PM, Zisis Papandreou wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> David, Matt:  Any idea?
>>>>>>>>>>
>>>>>>>>>> Thanks, Zisis...
>>>>>>>>>>
>>>>>>>>>> Begin forwarded message:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> From: Blake Leverington <leverinb at uregina.ca>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Date: February 10, 2010 5:15:54 PM GMT-06:00
>>>>>>>>>>> To: Zisis Papandreou <zisis at uregina.ca>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Cc: Matt Shepherd <mashephe at indiana.edu>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Subject: Re: Fwd: BCAL objects in DANA
>>>>>>>>>>>
>>>>>>>>>>> I'm not the one to answer this. I've never looked at that 
>>>>>>>>>>> file before.
>>>>>>>>>>>
>>>>>>>>>>> -Blake
>>>>>>>>>>>
>>>>>>>>>>> On 10/02/10 04:57 PM, Zisis Papandreou wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Hi guys:
>>>>>>>>>>>>
>>>>>>>>>>>> can one of you answer Elliott and cc: me?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks, Zisis...
>>>>>>>>>>>>
>>>>>>>>>>>> Begin forwarded message:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> From: Elliott Wolin <wolin at jlab.org>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Date: February 10, 2010 2:51:18 PM GMT-06:00
>>>>>>>>>>>>> To: Zisis Papandreou <Zisis.Papandreou at uregina.ca>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cc: Mark Ito <marki at jlab.org>, David Lawrence 
>>>>>>>>>>>>> <davidl at jlab.org>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Subject: BCAL objects in DANA
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Zisis,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I see DBCALHit.h and DHDDMBCALHit.h in the repository.  
>>>>>>>>>>>>> They are very similar.  Which one represents the HDDM data 
>>>>>>>>>>>>> the best, i.e. the one I should dump to EVIO files? Also, 
>>>>>>>>>>>>> can one be eliminated since they are so similar?  And 
>>>>>>>>>>>>> whatever remains should be called DBCALHit.h (drop HDDM in 
>>>>>>>>>>>>> the name).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>
>>>>>>>>>>>>>    Sincerely,
>>>>>>>>>>>>>     Elliott
>>>>>>>>>>>>>
>>>>>>>>>>>>> ================================================================================ 
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Those raised in a morally relative or neutral environment 
>>>>>>>>>>>>> will hold
>>>>>>>>>>>>>      no truths to be self-evident.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Elliott Wolin
>>>>>>>>>>>>> Staff Physicist, Jefferson Lab
>>>>>>>>>>>>> 12000 Jefferson Ave
>>>>>>>>>>>>> Suite 8 MS 12A1
>>>>>>>>>>>>> Newport News, VA 23606
>>>>>>>>>>>>> 757-269-7365
>>>>>>>>>>>>>
>>>>>>>>>>>>> ================================================================================ 
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> ---
>>>>>>>>>>>> Dr. Zisis Papandreou |  email: zisis at uregina.ca
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Department of Physics |  tel. : (306) 585-5379
>>>>>>>>>>>> University of Regina |  tel. : (306) 585-4149
>>>>>>>>>>>> Regina, SK  S4S 0A2 |  fax. : (306) 585-5659
>>>>>>>>>>>> World Wide Web: http://www.phys.uregina.ca/sparro/zisis/
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>> Dr. Zisis Papandreou        |  email: zisis at uregina.ca
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Department of Physics    |  tel. : (306) 585-5379
>>>>>>>>>> University of Regina        |  tel. : (306) 585-4149
>>>>>>>>>> Regina, SK  S4S 0A2        |  fax. : (306) 585-5659
>>>>>>>>>> World Wide Web: http://www.phys.uregina.ca/sparro/zisis/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> ---
>>>>>>>> Dr. Zisis Papandreou        |  email: zisis at uregina.ca
>>>>>>>>
>>>>>>>>
>>>>>>>> Department of Physics    |  tel. : (306) 585-5379
>>>>>>>> University of Regina        |  tel. : (306) 585-4149
>>>>>>>> Regina, SK  S4S 0A2        |  fax. : (306) 585-5659
>>>>>>>> World Wide Web: http://www.phys.uregina.ca/sparro/zisis/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> -- 
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------ 
>>>>>>>
>>>>>>>  David Lawrence Ph.D.
>>>>>>>  Staff Scientist                 Office: (757)269-5567   [[[  
>>>>>>> [   [ [ Jefferson Lab                   Pager:  (757)584-5567   
>>>>>>> [  [ [ [ [ [ http://www.jlab.org/~davidl     davidl at jlab.org
>>>>>>>
>>>>>>>          [[[  [[ [[ [[[
>>>>>>>
>>>>>>> ------------------------------------------------------------------------ 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>> -- 
>>>>>
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>>  David Lawrence Ph.D.
>>>>>  Staff Scientist                 Office: (757)269-5567   [[[  [   
>>>>> [ [ Jefferson Lab                   Pager:  (757)584-5567   [  [ [ 
>>>>> [ [ [ http://www.jlab.org/~davidl     davidl at jlab.org
>>>>>          [[[  [[ [[ [[[
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Halld-cal mailing list
>>>> Halld-cal at jlab.org
>>>> https://mailman.jlab.org/mailman/listinfo/halld-cal
>>>>
>>>
>>> _______________________________________________
>>> Halld-cal mailing list
>>> Halld-cal at jlab.org
>>> https://mailman.jlab.org/mailman/listinfo/halld-cal
>>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: barbosa.vcf
Type: text/x-vcard
Size: 188 bytes
Desc: not available
Url : https://mailman.jlab.org/pipermail/halld-cal/attachments/20100212/b74f4735/attachment.vcf 


More information about the Halld-cal mailing list