[Halld-offline] Calorimetry reconstruction

Blake Leverington leverinb at uregina.ca
Mon Nov 23 14:42:09 EST 2009 

I've commited my version of the DPhoton_factory to the repository. It 
looks at the list of particles, swims them (no scattering) and compares 
final positions at the calorimeter to determine if any DPhotons are from 
charged particles.  However, I'm not familiar enough with the code 
hierarchy to make any comments on whether this should determine if 
DParticle and DPhoton should remain separate or not.

-Blake

Curtis A. Meyer wrote:
> Depending on what one is doing, it is sometimes useful to have
> photons isolated (e.g. finding pi0's) and it is othertimes useful to
> have all final state particles in a single place.
>
> Of course, as far as the data-stream goes, we need to choose one
> or the other. We do not want to leave a choice on which to use.
> There should be exactly one source for the photons.
>
> Ultimately, in doing physics it is charged particles and pi0 (eta)s that
> matter. However, in Crystal Barrel (an perhaps in CLEO?), we left this
> latter step to physics analysis rather than reconstruction. We used 
> kinematic
> fitting to check every possible combination of photons against the 
> desired
> final state, and typically retained all that worked.
>
>  We also had a step to deal with hadronic split-offs where we also looked
> at events and treated every photon (individually) as a charged 
> split-off. We
> then treated every possible pair this way.
>
>   Thus identifying pi0 and eta became a part of the topological 
> selection, rather
> than the event reconstruction.
>
>  curtis
> Matthew Shepherd wrote:
>> Hi Simon,
>>
>> Between you and Blake we probably only need one algorithm.  I'm not 
>> sure how different they are or which one is better.
>>
>> I had envisioned DPhoton as a "high level" object reconstructed from 
>> the calorimeter.  It would have an analog, maybe DParticle, or 
>> DChargedParticle, that is a high level tracking object.  These seem 
>> to be what people what to do deal with most in their analysis:  a 
>> list of photons or a list of charged tracks.  I think this design was 
>> mainly driven by my past experience with how the CLEO code was 
>> organized. 
>> Certainly these could be combined into a single DParticle object....  
>> we should decide if that is what we want to do.  Would analyzers in 
>> general find it useful to have a single list of all particles in the 
>> event?  I see your DParticle objects now include photons but these 
>> can be in principle different from those in DPhoton factory.
>>
>> This sounds like a few agenda items for the next software meeting:
>>
>> - presentation from Simon role of DParticle_factory
>> - presentation from Matt, Blake, or Mihajlo on photon reconstruction 
>> chain
>> - discussion and decision on how to unify high-level objects
>> Cheers,
>>
>> -Matt
>>
>> On Nov 23, 2009, at 1:14 PM, Simon Taylor wrote:
>>
>>  
>>> Hi, Matt.
>>>
>>> I have not put my algorithm into the DPhoton factory, rather in the 
>>> DParticle factory, although I can put the code in the DPhoton 
>>> routine if that would be useful.  My idea was to use the DParticle 
>>> object to store both photons and charged particles.
>>>
>>> Simon
>>>
>>> Matthew Shepherd wrote:
>>>    
>>>> Hi Simon and Blake,
>>>>
>>>> Have you guys checked in your matching algorithms?  I just checked 
>>>> out the most recent copy and it seems like in the DPhoton factory 
>>>> we are still using Mihajlo's (crude) method of checking angles 
>>>> between generated tracks.  Once we get this in and streamlined 
>>>> Elton can directly extract kinematically fitted pi^0's to use in 
>>>> reconstruction.
>>>>
>>>> -Matt
>>>>
>>>> On Nov 19, 2009, at 8:37 AM, Simon Taylor wrote:
>>>>
>>>>  
>>>>      
>>>>> Hi, everyone.
>>>>>
>>>>> I have implemented matching between FCAL/BCAL clusters and 
>>>>> projected tracks without using truth information in the DParticle 
>>>>> factory.   The DParticle object is intended contain both charged 
>>>>> (with some preliminary PID) and neutral particles.  The matching 
>>>>> algorithm has not been optimized at all.
>>>>>
>>>>> Simon
>>>>>
>>>>> Kornicer, Mihajlo wrote:
>>>>>           
>>>>>> Hi David
>>>>>>
>>>>>> I agree 10 seems too many: "raw" photon multiplicity should be 
>>>>>> close to the number of final-state particles, due to both photon 
>>>>>> conversions and showers from charged tracks. In case of b1pi I 
>>>>>> would expect the number to peak around 7-8, so definitely needs 
>>>>>> to be investigated.
>>>>>>
>>>>>> Issue #2 I'll take a look at this.
>>>>>>
>>>>>> Question for Blake: did you come up with some criteria to tag 
>>>>>> photons as charged using swim tracks? It looks to me that default 
>>>>>> method for tagging charged showers is using angular separation, 
>>>>>> which I would not trust in the case of multiple charged particles.
>>>>>>
>>>>>> Regards,
>>>>>> Mihajlo
>>>>>>
>>>>>> Quoting Blake Leverington <leverinb at uregina.ca>:
>>>>>>
>>>>>>
>>>>>>               
>>>>>>> Hi David,
>>>>>>>
>>>>>>> I regards to 1), are these 10 all the DPhotons, or just the 
>>>>>>> uncharged
>>>>>>> ones (there is a Tag for FCAL=1, BCAL=2, Charged=3)? There is a
>>>>>>> routine for swimming charged tracks to the calorimeter faces and
>>>>>>> comparing with DPhoton showers, and tags the DPhoton as charged 
>>>>>>> if it
>>>>>>> is too close to a charged track.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> -Blake
>>>>>>>
>>>>>>> David Lawrence wrote:
>>>>>>>
>>>>>>>                   
>>>>>>>> Hi Mihajlo,
>>>>>>>>
>>>>>>>>   We are now starting to look at busier events where there are
>>>>>>>> more realistic backgrounds in the GlueX detector. It has caused 2
>>>>>>>> issues to emerge with the calorimeter reconstruction. (I'm 
>>>>>>>> assuming
>>>>>>>> you're still the go-to guy on this).
>>>>>>>>
>>>>>>>> 1.) When following the prescription at:
>>>>>>>>
>>>>>>>> http://www.jlab.org/Hall-D/software/wiki/index.php/HOWTO_simulate_and_analyze_b1pi_events 
>>>>>>>>
>>>>>>>>
>>>>>>>> I see nearly 10 reconstructed DPhotons on average even though 
>>>>>>>> only 2
>>>>>>>> are generated for each event. I haven't looked closely at the 
>>>>>>>> nature
>>>>>>>> of these, but off hand it seems 10 is just too many.
>>>>>>>>
>>>>>>>>
>>>>>>>> 2.) The FCAL code is currently not thread-safe to the point 
>>>>>>>> that you
>>>>>>>> pretty much are guaranteed to crash if you run it with more than
>>>>>>>> thread. A quick scan of the code shows things like this as a 
>>>>>>>> member
>>>>>>>> of the DFCALCluster class:
>>>>>>>>
>>>>>>>> static const userhits_t* fHitlist;
>>>>>>>>
>>>>>>>> It may be a simple as making these static data members non-static.
>>>>>>>> Could you have a look to see if you can make the FCAL 
>>>>>>>> reconstruction
>>>>>>>> thread safe?
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> -David
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                        
>>>>>> _______________________________________________
>>>>>> Halld-offline mailing list
>>>>>> Halld-offline at jlab.org
>>>>>> https://mailman.jlab.org/mailman/listinfo/halld-offline
>>>>>>
>>>>>>                
>>>>> _______________________________________________
>>>>> Halld-offline mailing list
>>>>> Halld-offline at jlab.org
>>>>> https://mailman.jlab.org/mailman/listinfo/halld-offline
>>>>>            
>>>>  
>>>>       
>>>     
>>
>>
>> _______________________________________________
>> Halld-offline mailing list
>> Halld-offline at jlab.org
>> https://mailman.jlab.org/mailman/listinfo/halld-offline
>>
>>   
>
>

More information about the Halld-offline mailing list