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.


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

> 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>
>>> > <>
> ------------------------------
> Use REPLY-ALL to reply to list
> To unsubscribe from the HPS-SOFTWARE list, click the following link:

Use REPLY-ALL to reply to list

To unsubscribe from the HPS-SOFTWARE list, click the following link: