Hello Matt,
I believe this is exactly what Ron's cluster analysis package is
meant to do. He's checked the code into cvs, and is now working on
the documentation for it. If you haven't already, give it a try
and see if it fills your needs.
Enjoy the weekend,
Norman
P.S. I would again suggest that this type of discussion be posted
to the forum.
> -----Original Message-----
> From: [log in to unmask]
> [mailto:[log in to unmask]] On Behalf Of
> Matthew John Charles
> Sent: Friday, February 17, 2006 1:12 PM
> To: lcd-dev
> Subject: Re: Thoughts on a calibration interface?
>
> Hello all,
>
> It seems like the consensus is that this it *too*
> algorithm-specific and
> belongs to individual implementations. I can accept that (and if we do
> find later that there is a lot of duplicated code we can refactor it).
> This does imply that CalorimeterHit.getCorrectedEnergy() needs to be
> roughly right out of the box as Ron pointed out.
>
> Flushed with this success, I'd like to kick around another
> idea for an
> interface: truth-matching. Very often I have bits of code
> that ask one
> of the following:
>
> 1. Which MCParticles (from a particular list) contribute to
> a certain
> cluster, and which one is dominant?
> 2. Which clusters (from a particular list) does a certain MCParticle
> contribute to, and which one is dominant?
> 3. Are this cluster (from a particular list) and this MCParticle
> (from a particular list) truth-matched?
> 4. Is this cluster (from a particular list, and given a particular
> list of MCParticles) a fragment?
>
> and I'm pretty sure that everyone on this list has their own code
> snippets that do the same thing. Can we put an interface or set of
> interfaces into the main org.lcsim tree to cover these? (And maybe a
> standard implementation...)
>
>
> Cheers,
>
> Mat.
>
|