[Halld-offline] Calorimetry reconstruction

[David Lawrence]

Hi Mihajlo,

    I followed folks' suggestion and tried cutting on 
getTag()!=DPhoton::kCharge. A quick check looks like it reduces the 
number of "photons" down to just over 2. I haven't looked yet to see if 
this cuts out any good photons. For now though, this looks like it may 
be a case of operator error on my part.

    Issue #2 still is hindering us a bit and so should be considered the 
higher priority.

Regards,
-David

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

-- 

------------------------------------------------------------------------
 David Lawrence Ph.D.
 Staff Scientist                 Office: (757)269-5567   [[[  [   [ [       
 Jefferson Lab                   Pager:  (757)584-5567   [  [ [ [ [ [   
 http://www.jlab.org/~davidl     davidl at jlab.org         [[[  [[ [[ [[[
------------------------------------------------------------------------