[Halld-offline] Calorimetry reconstruction

[Blake Leverington]

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