Isn't the seed hit just the one with the most energy anyways?

On Jun 21, 2014, at 12:49 PM, "McCormick, Jeremy I." <[log in to unmask]> wrote:

Yes you have it right.  You need to talk to Sho and the calorimeter group about this.  The proper way to do this is an LCRelation object to link the seed hit to the cluster.  Extending Cluster was a bad design choice and should be fixed I guess.

On Jun 21, 2014, at 12:33 PM, "Kyle McCarty" <[log in to unmask]> wrote:

I figured out how to make an output driver, but it seems I misunderstood what you were trying to tell me before. I guess the entire LCIO framework is only able to handle the writing SIOCluster objects, in addition to not being able to access the HPS classes. I assume that the LCIOWriter has either been given specific instructions on how to write the base LCIO classes or the base LCIO classes have a method to give the writer their output format for it to write. (This makes sense in hindsight; the way I had been thinking it worked would be dramatically more complicated.)

Looking more at the objects, it seems an HPSEcalCluster is basically just a BaseCluster that stores a seed hit and a cell ID. A seed hit is just a CalorimeterHit. Both of these are part of the LCIO package, but as I don't have the source code, I can't tell if they are part of our modified LCIO or if they are implementations of the base classes. How hard would it be to generated HPSEcalCluster objects from SIOClusters? I assume that it is easy to do with CalorimeterHit objects from their respective base object, since I didn't experience any errors when treating them as the same thing.

If this is not possible (or feasible), I need to be able to access the cluster energy, the seed hit, and the x/y crystal indices. SIOCluster has cluster energy, so that isn't a problem. SIOCluster appears to store the cluster component hits, so I should be able to extract the seed hit. As it is always the highest energy hit in the cluster, it should just be a matter of looping over the hits and pulling out the one with most energy. The one I'm really not sure about, though, is the x/y crystal indices. I think that these are specific to HPS, so there is presumably no analogous parameter in the base hit class and I would need to map the hit absolute position parameters to a crystal index. I'm not sure how to actually do this, though.

Thanks,

Kyle

On Sat, Jun 21, 2014 at 3:12 PM, McCormick, Jeremy I. <[log in to unmask]> wrote:

What info do you need from the HPS cluster class that is not in the standard API?

On Jun 21, 2014, at 10:22 AM, "Kyle McCarty" <[log in to unmask]> wrote:

Thanks for the reply. Is the source code available somewhere? I could just pull a copy into an HPS package for my local version so it could recognize the class. Alternatively, I could potentially make a new driver for HPS if I knew how it worked.

Thanks,

Kyle

On Jun 21, 2014 12:19 PM, "McCormick, Jeremy I." <[log in to unmask]> wrote:

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