LCIO only knows about its base types and can't load back extended classes with extra information (e.g. class variables).
This is a reason to use the "generic object" functionality rather than a custom class. Or we can request a new addition to the IO format but we have not been good about this.
You can however still get at those objects from Cluster.class using get(). They won't have any of the extra information.
I guess you need to talk to the author of the custom cluster class to see what can be done about this,
> On Jun 21, 2014, at 12:55 AM, "Kyle McCarty" <[log in to unmask]> wrote:
>
> Hello Jeremy,
>
> I'm getting a strange error. I created a file for spaced A' events and ran reconstruction over it, outputting the results to a new SLCIO file. Since the input file was spaced heavily, I know that all clusters and FADC hits that occur in the empty events between those containing raw calorimeter hits came from the last event which has the raw calorimeter hits. To both reduce the file size and make analyzing them easier, I wrote a script that goes through and grabs the FADC hits and clusters and adds them to the source event. However, I found that the method
>
> event.hasCollection(HPSEcalCluster.class, COLLECTION_CLUSTERS)
>
> always comes up false. I have examined the input file in JAS3 and there is in fact a collection with the given name (String COLLECTION_CLUSTERS = "EcalClusters") containing clusters in several events. Additionally, these clusters are created with an unmodified version of the GTP clusterer driver which Sho and I wrote, so I know that they are output as class HPSEcalCluster.
>
> I did some more research and, calling the method
>
> event.getLists()
>
> I was able to obtain all the collections stored in the event. Getting the first element from the lists and outputting its class name gives, among others, a collection of type "SIOCluster." These only appear in the events that contain clusters and are acquired when I call
>
> event.get(HPSEcalCluster.class, COLLECTION_CLUSTERS)
>
> without error. However, attempting to manipulate the objects from the resultant list causes a ClassCastException, saying that an SIOCluster can not be case to an HPSEcalCluster. This is clearly the cluster collection, and was originally created as an HPSEcalCluster collection.
>
> My theory is that the clusters are HPSEcalClusters objects originally, but are being saved as SIOClusters (which seems to be missing some parameters such as seed hit) by the LCIO save driver. This is supported by the fact that the trigger driver, if added to the reconstruction chain, does not have any errors despite explicitly calling HPSEcalCluster methods like getSeedHit() that do not exist in SIOCluster. The script, however, uses the saved output rather than LCSim's internal memory so it gets the reduced version.
>
> I'm not sure what the correct course of action for resolving this is. Is there a better version of the LCIO write driver that can handle HPSEcalCluster objects? I can't find the driver in the source files anywhere, so I assume it is part of the LCSim project that is presumably pulled in (precompiled?) by Maven, so I can't just change the driver.
>
> To make it easier to check my theory or test the problem, I have attached the steering file and input data file I have been using along with the script.
>
> Thanks,
>
> Kyle
> <ClusterProcessing.lcsim>
> <cluster-100mev-window1.slcio>
> <EventUnifier.java>
########################################################################
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
|