LISTSERV mailing list manager LISTSERV 16.5

Help for HPS-SOFTWARE Archives


HPS-SOFTWARE Archives

HPS-SOFTWARE Archives


HPS-SOFTWARE@LISTSERV.SLAC.STANFORD.EDU


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Monospaced Font

LISTSERV Archives

LISTSERV Archives

HPS-SOFTWARE Home

HPS-SOFTWARE Home

HPS-SOFTWARE  July 2017

HPS-SOFTWARE July 2017

Subject:

Re: Meeting Update

From:

Nathan Baltzell <[log in to unmask]>

Reply-To:

Software for the Heavy Photon Search Experiment <[log in to unmask]>

Date:

Thu, 13 Jul 2017 07:41:15 -0400

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (61 lines)

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

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

April 2024
March 2024
February 2024
January 2024
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
December 2022
November 2022
October 2022
September 2022
August 2022
June 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011

ATOM RSS1 RSS2



LISTSERV.SLAC.STANFORD.EDU

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager

Privacy Notice, Security Notice and Terms of Use