[Halld-offline] Calorimetry reconstruction
Curtis A. Meyer
cmeyer at ernest.phys.cmu.edu
Mon Nov 23 13:37:23 EST 2009
Depending on what one is doing, it is sometimes useful to have
photons isolated (e.g. finding pi0's) and it is othertimes useful to
have all final state particles in a single place.
Of course, as far as the data-stream goes, we need to choose one
or the other. We do not want to leave a choice on which to use.
There should be exactly one source for the photons.
Ultimately, in doing physics it is charged particles and pi0 (eta)s that
matter. However, in Crystal Barrel (an perhaps in CLEO?), we left this
latter step to physics analysis rather than reconstruction. We used
kinematic
fitting to check every possible combination of photons against the desired
final state, and typically retained all that worked.
We also had a step to deal with hadronic split-offs where we also looked
at events and treated every photon (individually) as a charged split-off. We
then treated every possible pair this way.
Thus identifying pi0 and eta became a part of the topological
selection, rather
than the event reconstruction.
curtis
Matthew Shepherd wrote:
> Hi Simon,
>
> Between you and Blake we probably only need one algorithm. I'm not sure how different they are or which one is better.
>
> I had envisioned DPhoton as a "high level" object reconstructed from the calorimeter. It would have an analog, maybe DParticle, or DChargedParticle, that is a high level tracking object. These seem to be what people what to do deal with most in their analysis: a list of photons or a list of charged tracks. I think this design was mainly driven by my past experience with how the CLEO code was organized.
>
> Certainly these could be combined into a single DParticle object.... we should decide if that is what we want to do. Would analyzers in general find it useful to have a single list of all particles in the event? I see your DParticle objects now include photons but these can be in principle different from those in DPhoton factory.
>
> This sounds like a few agenda items for the next software meeting:
>
> - presentation from Simon role of DParticle_factory
> - presentation from Matt, Blake, or Mihajlo on photon reconstruction chain
> - discussion and decision on how to unify high-level objects
>
> Cheers,
>
> -Matt
>
> On Nov 23, 2009, at 1:14 PM, Simon Taylor wrote:
>
>
>> Hi, Matt.
>>
>> I have not put my algorithm into the DPhoton factory, rather in the DParticle factory, although I can put the code in the DPhoton routine if that would be useful. My idea was to use the DParticle object to store both photons and charged particles.
>>
>> Simon
>>
>> Matthew Shepherd wrote:
>>
>>> Hi Simon and Blake,
>>>
>>> Have you guys checked in your matching algorithms? I just checked out the most recent copy and it seems like in the DPhoton factory we are still using Mihajlo's (crude) method of checking angles between generated tracks. Once we get this in and streamlined Elton can directly extract kinematically fitted pi^0's to use in reconstruction.
>>>
>>> -Matt
>>>
>>> On Nov 19, 2009, at 8:37 AM, Simon Taylor wrote:
>>>
>>>
>>>
>>>> Hi, everyone.
>>>>
>>>> I have implemented matching between FCAL/BCAL clusters and projected tracks without using truth information in the DParticle factory. The DParticle object is intended contain both charged (with some preliminary PID) and neutral particles. The matching algorithm has not been optimized at all.
>>>>
>>>> Simon
>>>>
>>>> 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
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Halld-offline mailing list
>>>> Halld-offline at jlab.org
>>>> https://mailman.jlab.org/mailman/listinfo/halld-offline
>>>>
>>>>
>>>
>>>
>>
>
>
> _______________________________________________
> Halld-offline mailing list
> Halld-offline at jlab.org
> https://mailman.jlab.org/mailman/listinfo/halld-offline
>
>
--
Prof. Curtis A. Meyer Department of Physics
Phone: (412) 268-2745 Carnegie Mellon University
Fax: (412) 681-0648 Pittsburgh PA 15213-3890
cmeyer at ernest.phys.cmu.edu http://www.curtismeyer.com/
More information about the Halld-offline
mailing list