[Halld-offline] Calorimetry reconstruction

[Blake Leverington]

Hi Mihajlo,

When I looked at the matching DPhotons to charged tracks, I swam a bunch 
of protons and charged pions and compared their positions to the DPhoton 
position. I looked at the difference distributions of radius, z, and phi 
and made a box cut of 3 sigma (I think, maybe 4), so any charged 
particle that is within this box is tagged as from possibly a charged 
particle. The box cut size can be increased or decreased from the 
command line at run time.

-Blake

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