Hi Kyle,

Maybe I got this wrong, but:

On #1, if I understand your issue, one complication there is that the truth-reconstructed relationship is inherently not one-to-one due to real simulation of pileup (i.e. multiple beam bunches / physics reactions overlayed prior to digitization for creating hits, cluster, tracks, ...).

And similarly on #3, rolling buffers of hits are stored across many time samples (and events), not just to treat time-evolution of pulses and clusters, but also to account for pileup and allow to (realistically) trigger on combined, uncorrelated events.

I thought there’s already another readout driver that doesn’t do pileup (i.e. every event from GEANT is treated independently), in which case both of those above get much easier, but then you lose some reality.

-Nathan



> On Jul 12, 2017, at 9:15 PM, McCormick, Jeremy I. <[log in to unmask]> wrote:
> 
> Hi, Kyle.
>  
> 1.       The standard way to associate two objects in LCIO is using a LCRelation collection.  There are a number of examples of how to do this in hps-java, and I agree that it would be useful to preserve the MC truth information in clustering if it isn’t already.  Implementing this should be pretty straightforward.
> 2.       I agree that the readout code is messy as it has a lot of different flags and settings in it for the “old” 2014 behavior.  If you want to try and separate this out I think it is a worthy project.  I’m not even sure that we need to keep the old behavior at all as it probably isn’t even used anymore.
> 3.       Unfortunately, the person who wrote this module originally (Sho) is no longer on the collaboration – and there is no real expert for this part of the code.  If you want to trigger in the readout simulation on calorimeter and hodoscope hits then you are going to have to figure out how best to do it yourself.  (Sorry, that’s probably not the answer you want to hear.)
>  
> --Jeremy
>  
> From: [log in to unmask] [mailto:[log in to unmask]] On Behalf Of Kyle McCarty
> Sent: Wednesday, July 12, 2017 3:08 PM
> To: hps-software
> Subject: Meeting Update
>  
> Hello,
>  
> I wanted to bring up a few things that I intended to discuss in the meeting today, but was unable to due to an unexpected issue to which I had to attend.
>  
> The first issue I wanted to discuss concerns truth information in clustering. I found that all of the truth information is lost from clustering Monte Carlo at the digitization stage. I think it would be useful to retain this. However, I see that we create "RawCalorimeterHit" and "RawTrackerHit" objects, which do not support storing this information. Does anyone have any suggestions on what the correct way to store truth information would be in this case?
>  
> The second issue is that currently, our readout code is a bit messy. I think that it would be improved by separating out the 2014 functionality, which is currently mixed in with the regular behavior in a bunch of if/else blocks. This makes the code much harder to maintain and also increases the risk that any changes to it will break the old functionality. I think it would be better to lock the old 2014 code in its current state in separate drivers explicitly for that purpose.
>  
> Lastly, I wanted to see if anyone had advice concerning the best way to handle an LCSim issue. As we move forward with the hodoscope trigger, it will become necessary to trigger on both the hodoscope and the calorimeter simultaneously. Currently, this is actually somewhat challenging. The reason for this is that many LCIO objects in the data stream are "time-displaced" in the readout stage. This occurs because, for things like pulse emulation and clustering, we have to wait extra events passed where an object actually occurs, to create the simulated object. This is easiest to see for clustering. A cluster can only be formed by looking over a +/-T ns window. Since events are 2 ns beam bunches in readout, this means we need to wait at least T/2 events before performing clustering. However, when we then create clusters, they must be inserted into the current event, which is T/2 events in front of the seed hit's original event. This creates an issue when the hodoscope hit is now in a totally separate event from the clusters and depends in a complicated fashion on both the "displacement" induced by the digitization/hit formation drivers and clustering drivers. (These in turn depend on their own settings.) Can anyone suggest a way to handling this to ensure that the correct hodoscope hits and clusters are compared, short of maintaining a large buffer?
>  
> Thanks,
>  
> Kyle
>  
> 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
> 

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