 |
 |
The rejected hit list should already be accessible in a separate hits collection. You added this to your IC clustering Driver and I've ported this to the new ecal.cluster package as well. So I think that problem is solved. For the shared hits, internally, you will need to keep track of which hits are shared for your energy calculation, but you can't directly store two separate lists of hits within a cluster. It has only one list of hits. Later on in analysis you could tell that a hit is shared, because it will be present in more than one cluster. So if all you want to be able to do is tell if a hit is shared, simply add it to more than one cluster. Then take the sharing into account within your energy calculation somehow. With this approach though, you will lose the low level information about how you split up that hit's energy between multiple clusters. If you actually need to keep track of and persist to LCIO the individual shared energy contributions per hit, in other words breaking up the hits themselves into their contributions you've calculated per cluster, then I think the best approach is probably creating new CalorimeterHit objects with these individual energies, in a new LCIO hit collection which you would write to the event. Then the hit which has the partial energy in it would only be added to that cluster's hit list, and you could tell later which hits are shared by using the ID. With this approach, you would have multiple hits per crystal for those hits which are shared. Hope that makes sense... -----Original Message----- From: Holly Vance [mailto:[log in to unmask]] Sent: Wednesday, December 17, 2014 2:01 PM To: McCormick, Jeremy I. Cc: Graf, Norman A. Subject: Re: shared hits Hi Jeremy, We absolutely need to keep this information. It should be accessible just as the rejected hit list should also be accessible. I am not sure the simplest way to do this. -Holly On Wed, Dec 17, 2014 at 4:50 PM, McCormick, Jeremy I. <[log in to unmask]> wrote: Hi, Holly is trying to write clustering code that "shares" hits between different clusters. Can you provide some guidance on this? I was not sure of the best way to do it. Right now there is code in the Cluster extension class HPSEcalClusterIC which has a list of shared hits, but of course it isn't persisted to LCIO. Because shared hits are not part of the LCIO API. I thought that if this information needs to be recoverable later, there should be a relation collection that associates the cluster with its shared hits, but I'm not sure. Do we really need this list of hits when reading back from an LCIO file? Or is it okay to take this into account in the energy calculation and hide it from an analyst? --Jeremy -- BEGIN-ANTISPAM-VOTING-LINKS ------------------------------------------------------ NOTE: This message was trained as non-spam. If this is wrong, please correct the training as soon as possible. Teach CanIt if this mail (ID 03NsJPaa0) is spam: Spam: https://www.spamtrap.odu.edu/canit/b.php?i=03NsJPaa0&m=79da0dd8b8d7&t=20141217&c=s Not spam: https://www.spamtrap.odu.edu/canit/b.php?i=03NsJPaa0&m=79da0dd8b8d7&t=20141217&c=n Forget vote: https://www.spamtrap.odu.edu/canit/b.php?i=03NsJPaa0&m=79da0dd8b8d7&t=20141217&c=f ------------------------------------------------------ END-ANTISPAM-VOTING-LINKS ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the HPS-SOFTWARE list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1