[Halld-offline] Calorimetry reconstruction

[Kornicer, Mihajlo]

Hi David,

Issue #2 is not as simple as converting static members to non-static,
They are there for some (historic) reasons, which will take some 
editing of a day or so. Please bear with me while I am working on this.

Regards,
Mihajlo


Quoting David Lawrence <davidl at jlab.org>:

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