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