 |
 |
Hi, I agree with Norman that it is absolutely essential that all hits associated with a cluster are passed along in the output information (shared hits included). I think Sho's suggestion is indeed natural, and I will look into this. Actually, since I store the shared hits in the cluster hit list and in a shared hit list, the online monitoring can access the shared hit list associated with a cluster and illustrates these crystals with a different color (they still highlight for both associate clusters). Ok, this is a feature in HPSEcalClusterIC so maybe not LCIO.... The clustering code sets the energy of the cluster with this weighting and this is what is read back into the event display so this is not a problem either (displays correct cluster energy). Shared hits are important as there is not necessarily a way to distinguish with certainty if a common hit belongs to a particular cluster (entirely). The use of common/shared hits is a part of clustering algorithms such as the Inner Calorimeter and Alice (as well as others that are documented). It's important for HPS to preserve this feature even if it is not occurring in most events. Thank you for the helpful suggestions. -Holly On Wed, Dec 17, 2014 at 5:58 PM, Graf, Norman A. <[log in to unmask]> wrote: > > Holly, > You should associate all the hits with the cluster. For those hits whose > energy you would > like shared you should create a weighted LCRelation as Sho suggests. That > will persist the > information. However, certain functions will not be able to pick this up > automatically, > such as the event display. The hits drawn as part of the cluster will be > drawn with their > full energy. Various other utilities will also not automatically respect > this energy sharing. > What's the motivation for this? Do you expect a large number of clusters > to overlap? > Norman > > -----Original Message----- > From: Sho Uemura [mailto:[log in to unmask]] > Sent: Wednesday, December 17, 2014 2:47 PM > To: McCormick, Jeremy I. > Cc: Holly Vance; Graf, Norman A.; hps-software > Subject: RE: shared hits > > Weighted LCRelations (cluster->hit, weight equal to the sharing fraction) > seem natural. You can decide whether shared hits show up in the hit list > for the cluster; I think yes. > > The cluster energy and position saved to LCIO is whatever your cluster > class reports it to be, and are not recalculated after the cluster is read > back out of LCIO, so those will not be affected by the details of how you > represent things in LCIO. > > On Wed, 17 Dec 2014, McCormick, Jeremy I. wrote: > > > 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 > > > > > > -- > > > > > > > > > > ###################################################################### > > ## > > 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 > > > > > -- > BEGIN-ANTISPAM-VOTING-LINKS > ------------------------------------------------------ > > > Teach CanIt if this mail (ID 03NsKXsmv) is spam: > > Spam: > https://www.spamtrap.odu.edu/canit/b.php?i=03NsKXsmv&m=0cc0222f1240&t=20141217&c=s > > Not spam: > https://www.spamtrap.odu.edu/canit/b.php?i=03NsKXsmv&m=0cc0222f1240&t=20141217&c=n > > Forget vote: > https://www.spamtrap.odu.edu/canit/b.php?i=03NsKXsmv&m=0cc0222f1240&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