[Halld-offline] Calorimetry reconstruction

[Matthew Shepherd]

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
>>>    
>> 
>> 
>>  
> 
>