[Halld-offline] Calorimetry reconstruction

[Kornicer, Mihajlo]

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