[Halld-cal] BCAL objects in DANA

Matthew Shepherd mashephe at indiana.edu
Fri Feb 12 11:10:13 EST 2010


Hi Dave,

OK we can change the name.  At one point we all agreed to put HDDM in  
the name since these were in fact DANA versions of specific HDDM  
structs that were provided by the HDDM event source and not derived  
from any factory.  I had envisioned also a raw hit object for data  
that may have low level detector info such as crate, slot, channel.   
The chain for data and MC then merges one level above these objects at  
the DBCALHit level.

Matt

----
This message was sent from my iPhone.

On Feb 12, 2010, at 9:34 AM, David Lawrence <davidl at jlab.org> wrote:

>
> Hi All,
>
>     I think the main point here is that whatever you choose to call  
> the objects, the string "HDDM" should not be part of the name. For  
> example, when we get a raw data hit from the DAQ system, we're not  
> going to call it DEVIOBCALHit. When you make a reconstructed photon  
> you won't call it DROOTBCALPhoton (or whatever your output file  
> format happens to be named). I don't really care what you call the  
> object currently called "DHDDMBCALHit", but I think the "HDDM"  
> string provides very little information as to the nature of its  
> content to a new user.
>
> -David
>
> Mark M. Ito wrote:
>>
>> Folks,
>>
>> A general comment: I think we should have as many classes as are  
>> needed
>> to conveniently express/model the physical processes in energy
>> deposition, detection and reconstruction. As Beni and others have
>> pointed out, there won't always be a one-to-one correspondence as one
>> goes through the processes. If you add accidentals, then the
>> correspondences get even more complicated. The right structure for  
>> the
>> classes is then highly detector dependent. Some of these classes  
>> would
>> be intermediate ones, not generally used, but could be useful for
>> detailed studies.
>>
>> There might be some overhead in creating more classes; that would  
>> be a
>> unpleasant side effect. One could certainly go too far by
>> microscopically representing every subprocess (atoms with excited  
>> states
>> emitting photons...whoops, need more memory). But all of the steps  
>> need
>> to be represented somehow or another anyway. Distinct classes for
>> different stages (as is reasonable) would make the code easier to
>> understand/maintain as well.
>>
>> Whether a particular object is called the "truth" or not is not  
>> really
>> the important issue, IMHO, as the truth has many levels.
>>
>>    -- Mark
>>
>> On 02/12/2010 07:53 AM, 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
>>>
>>>
>>
>> _______________________________________________
>> Halld-cal mailing list
>> Halld-cal at jlab.org
>> https://mailman.jlab.org/mailman/listinfo/halld-cal
>>
>
> -- 
>
> --- 
> ---------------------------------------------------------------------
>  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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.jlab.org/pipermail/halld-cal/attachments/20100212/551768db/attachment-0001.html 


More information about the Halld-cal mailing list