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  September 2012

HPS-SOFTWARE September 2012

Subject:

Re: Simulation chain and stereo hits

From:

"Hansson Adrian, Per Ola" <[log in to unmask]>

Reply-To:

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

Date:

Thu, 20 Sep 2012 11:54:48 -0700

Content-Type:

multipart/mixed

Parts/Attachments:

Parts/Attachments

text/plain (90 lines) , winmail.dat (90 lines)

Hi All,

with Omar's help I was able to track this down to simply being a problem with the "filtering" of MC bunches. The nr of empty bunches inserted was defaulted to zero and thus all triggers were stacked with 2ns spacing.

When filtering with 250 bunches I get a more reasonable nr of hits.

The issue with many strip clusters being converted to the same HelicalTrackStrip position was not a problem, what I was checking was the origin (for some reason!) and if I compared the measured strip position ("umeas") I see that they are indeed different. My bad.

I should note that there are currently two procedures to run readout simulation of the SVT. After checking I don't think it matters which one I run for this (looks similar) but we should make sure that there is one default for people that are not studying this. We should make sure that it is the one in the steering files that is used for our confluence instructions. Sho and Omar should decide based on expert knowledge of this and either change or keep things as is. I'll stay with what is there now (SimpleSvtReadout) but please send out email if I should change and rerun.

I also learned from Omar that currently we are not using the calibration from data. I suggest that Omar updates this so that we all use the best known calibrations. If it breaks something we can deal with it (just send out a warning email).

Cheers,

Pelle


On Sep 19, 2012, at 11:27 PM, Nelson, Timothy Knight wrote:

> Hey Pelle,
>
> I'm not sure what's going on here. There shouldn't be anything that requires stereo pairs to have the same normal vector, but I suppose I might have done that since perfectly aligned designs don't depend upon that.
>
> The duplicates sound like ghost hits. As long as *both* strips that make up the 2d hit aren't the same, they have to be considered as separate hits. If you haven't figured out what's going on by the time I get back, we can look at it then.
>
> -Tim
>
> On Sep 20, 2012, at 3:11 PM, Hansson Adrian, Per Ola wrote:
>
>> Hi,
>>
>> warning for a long and involved email.
>>
>>
>>
>> Today, after updating all packages, I got an error that said "Failed! Planes aren't parallel" when running over simulated events.
>>
>> This is what I'm doing:
>> - run slic over std hep files
>> - run filtering of MC bunches
>> - run readout simulation ( java -jar ../hps-java/target/hps-java-1.2-SNAPSHOT-bin.jar steering/HPSTestRunReconToLcio.lcsim -i $path/$f -DoutputFile=$outdir/$outfilelcio)
>> - run reconstruction and analysis drivers on that
>>
>> I've updated to the latest of all packages (Geom, lcsim, hps-java, hps-detectors) and all this was done with HPS-TestRun-v2 (I've checked and it's the same for v3, you'll see why later).
>>
>> I suspect that I'm not understanding some step in this simulation chain and I would be happy to once and for all understand what I'm doing wrong and why.
>>
>> Anyway, I started to dig into the error message and it turns out that the error message is in the lcsim stereohitmaker class in the function where it tries to pair two strips into a stereo hit. In that process there is a check if the two strips are parallel "enough" (cross product of the "w" unit vectors of the strips) and it throws this messages every time they don't satisfy this.
>>
>> I dug into the HPSHelicalTrackHitDriver that actually is the one calling this function and thus responsible for giving it the strips for pairing. If I understood the idea properly this driver takes the "StripClusterer_SiTrackerHitStrip1D" hits from the event, turns them into HelicalTrackStrips and then associates each of those strips with a stereo layer. These stereo layers are then looped over and the StereoHitMaker is called for each combination of hits on them, turning them into HelicalTrackCross if they make sense (the end result is what we call a stereo hits).
>>
>> In this process there are a couple of things I'm confused about:
>>
>> * What are the "StripClusterer_SiTrackerHitStrip1D" hits in the event?
>> I see e.g. 112 hits for a given event. Here is an example:
>> HPSHelicalTrackHitDriver: Hit 3 at [ 14.580, 28.032, 495.80]
>> HPSHelicalTrackHitDriver: Hit 4 at [ 14.509, 26.594, 495.77]
>> HPSHelicalTrackHitDriver: Hit 5 at [ 14.448, 25.376, 495.74]
>> HPSHelicalTrackHitDriver: Hit 6 at [ 14.418, 24.772, 495.73]
>> HPSHelicalTrackHitDriver: Hit 7 at [ 14.243, 21.262, 495.65]
>> which seems to be hits on the same sensor but space between 1-2mm in the vertical (~measurement direction). I would have suspected these would only be a few, like 1 per layer in one half (dominated by single track events)
>> I noticed also that when we create the HelicalTrackStrip from each of these hits we end up with many duplicates in terms of position. The 6 hits above all create 6 copies (same position but they do have different "times")
>> HPSHelicalTrackHitDriver: turned hit into HelicalTrackStrip at position [ 14.842, 33.181, 496.07].
>>
>> I guess I don't understand what these strip clusters are, it does seem strange that we would like to feed many duplicates into the track finding (haven't checked if duplicates are thrown out there but I suspect not?).
>>
>> * There are too many events with hits in the same layer in top and bottom?
>> Since we are dominated by 1 track events there should only be a few events in which there is a hit in e.g. layer 9 in top and L10 in bottom causing this problem of not being parallel. I suspect this is why we haven't seen it so much before? I confirmed this by running on a simulated file which I turned into EVIO some time ago (1 month?) and there I see very few "StripClusterer_SiTrackerHitStrip1D" per event (~1 per plane) and only very rarely see the error message, since there's simply no top bottom cases where it happens.
>>
>> I guess this also point to some inconsistency on how I run simulation/digi/reconstruction.
>>
>> * As I mentioned above, in the HPSHelicalTrackHitDriver the tracker hits are not separated between top and bottom, i.e. it will try to form stereo pairs for e.g. layer 9 and 10 include strips from the top and bottom. I think. This is fine as they shouldn't pass the "reasonable" checks that are performed when looking at the consistency of the stereo hit. But it should also throw this error message from now and then when it happens that there is a hit in both top and bottom and it needs to compare them. If what I'm saying is true, should we make sure that we only feed strips from the same half in there as the parallel check make a lot of sense and we don't want to get rid of it?
>>
>> Thanks for any input,
>>
>> Pelle
>>
>> PS. Long printout (probably not understandable) is at: http://www.slac.stanford.edu/~phansson/files/temp/tmp_v2
>>
>>
>


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