 |
 |
Yes, I can get it by sorting through the list of hits and picking the highest energy hit. I can't get the x/y crystal index though. Trying to causes an error pertaining to an IDDecoder class. Thanks, Kyle On Jun 21, 2014 4:30 PM, "McCormick, Jeremy I." <[log in to unmask]> wrote: > 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 > > ######################################################################## 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