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