[Halld-offline] Calorimetry reconstruction

[Blake Leverington]

Hi Matt,

Seems the version there is missing what I had put there awhile ago. I'll 
see if I can update that.

-Blake

Matthew Shepherd wrote:
> Hi Blake,
>
> I don't see it in this file:
>
> https://halldsvn.jlab.org/repos/trunk/src/libraries/PID/DPhoton_factory.cc
>
> Am I blind?
>
> -Matt
>
> On Nov 23, 2009, at 11:53 AM, Blake Leverington wrote:
>
>   
>> Hi Matt,
>>
>> I just looked at the most recent trunk version in the repository. My matching algorithm "DPhoton_factory::dFromSwumChargeMC" is there and seems to be implemented. I had left Mihajlo's code in there, although it is no longer implemented.
>>
>> -Blake
>>
>> 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
>>>>    
>>>>         
>>>  
>>>       
>
>