This was my initial thought, but the problem with actually persisting this is that the C++ will read this single value as the length of a list of items, because that's how the LCIO format is defined.  And it will then crash.  So we can't do it that way...

The proper thing to do would be implement the PID + likelihood list properly using an SIO class.  Is this something we need?  I don't think it would be that difficult.

It could also be done using an LCRelation and LCObject collection but a proper implementation of the format is obviously preferable.

-----Original Message-----
From: [log in to unmask] [mailto:[log in to unmask]] On Behalf Of Holly Vance
Sent: Monday, February 06, 2017 2:44 PM
To: McCormick, Jeremy I.
Cc: hps-software
Subject: Re: Cluster particle id

We could just set the first item in the list to be the PID we use for the corrections. What does that require for us to change in the code?

On Fri, Feb 3, 2017 at 5:32 PM, McCormick, Jeremy I. <[log in to unmask]> wrote:


	Okay, so looking further at the LCIO API, it seems that each Cluster is supposed to have a list of PID values sorted by their likelihood and that this was never implemented in lcsim.  Should you instead be working from information in ReconstructedParticle?  This is not something that can be fixed just by just adding a single particle ID to the output because I guess zero here is actually the length of the PID list.  Probably it needs to stay that way to be compatible with the C++ API.


		On Feb 3, 2017, at 1:02 PM, McCormick, Jeremy I. <[log in to unmask]> wrote:

		The particle ID is available at runtime via BaseCluster but the persistency is broken because the PID is hard-coded to zero (no idea why).

		We should be able to fix this in lcsim, and then the information should be available.  You shouldn’t need to cast to BaseCluster — the information will be available via the Cluster.getParticleId() method (once it is actually written out).


			On Feb 3, 2017, at 12:54 PM, Holly Vance <[log in to unmask]> wrote:

			In our reconstruction code, ReconParticleDriver.java, we set the pid of the cluster in track cluster matching. This definitely happens because this then goes to set energy and position corrections to the cluster in ClusterEnergyCorrection.java and ClusterPositionCorrection.java. Both of these correction drivers call "cluster.getParticleId()" to determine what particle type is associate with this cluster.  

			I'm guessing that this is not getting written out to the cluster collections somehow, although it should be written out to the corrected collection. The reason this is good information to have is to know which corrections were used for a cluster. 

			I've been trying to read the particle id of clusters when running the tuple driver, but it is not working since they are all set to 0. Maybe casting it wasn't the correct thing to do, but then I want to know why this is not being written out to the corrected cluster collection.

			On Fri, Feb 3, 2017 at 3:08 PM, McCormick, Jeremy I. <[log in to unmask]> wrote:
			

				Hi,

				From what I can tell the particle ID on Cluster was never implemented.  It is always hard-coded to ‘0’ in the output code, but this could be easily changed to write out the value from getParticleId() and still be backward compatible (there is a space for an int there in the Cluster output that we are already using/reserving).  It looks like maybe the LCIO standard indicates there could be multiple particle IDs, as there is some commented out code in the SIO class for writing a list of PID values.

				The SIOCluster class seems to implement Cluster directly, so it isn’t a BaseCluster (for some reason it was done differently than the other SIO classes that extend a base class).  That’s why the cast fails.  I’m not sure what you are trying to do, but you can use the copy constructor of BaseCluster to create an object with the same information.  If you’re trying to modify the collection in place though, this probably won’t do what you want.  You would probably need to create a new collection to contain the copied Cluster objects.
				

				—Jeremy


					On Feb 2, 2017, at 6:19 PM, Holly Vance <[log in to unmask]> wrote:

					Hi Jeremy, 

					I'm trying to write out from recon files what the pid is of the cluster. During recon, we assign this as a BaseCluster and setParticleId(). Additionally, when applying cluster corrections to energy and position, we use cluster.getParticleId(), and this returns something like +/-11, 22.

					However, when I look at a fully reconstructed file and try to do cluster.getParticleId(), it is always set to 0. 

					I tried casting this to BaseCluster, but it doesn't work. I've tried this on both collections "EcalClusters" and "EcalClustersCorr".  


					   if (event.hasCollection(Cluster.class,"EcalClustersCorr")){

					            List<Cluster> ecalClusters = event.get(Cluster.class,"EcalClustersCorr");

					Cluster c1 = ecalClusters.get(0));

					
					

					            System.out.println("Cluster pid:\t"+c1.getParticleId());

					
					

					If I try to do: 

					((BaseCluster)c1).getParticleId()
					

					then I get 

					org.lcsim.job.EventMarkerDriver process :: Event 10085820 with sequence 0

					java.lang.ClassCastException: org.lcsim.lcio.SIOCluster cannot be cast to org.lcsim.event.base.BaseCluster

					 <https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif> 

					Is there a reason this is not persisted?

					-Holly

					
					







________________________________

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 


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