Print

Print


It looks like the findable track efficiency (findable=mc particle left energy in at least the first 10 sensors) is only ~20%.  Iíve gone so far as to see that there are missing helicaltrackhits (3d hits); still donít know why they donít show up.  Could be an issue with the timing cutÖmaybe something funny with the stereo hit making.  Still trying to corner it. 

Sho probably figured this out last night.  

On Apr 16, 2014, at 4:19 PM, Graf, Norman A. <[log in to unmask]> wrote:

> Hello Sho,
> Thanks for sending around the test file. Here are my first 
> impressions.
> 
> "Analysis" based on browsing the file.
> I wanted to know what sort of events I was looking at,
> so I started with the trigger information.
> 
> TriggerBank:
> All zeros. Either not being set by the trigger simulator
> or not being written out.
> 
> Since not every event is being written out there must
> have been some selection criterion. Since we only trigger 
> on clusters, that's next.
> 
> EcalClusters:
> Always more than one of them, always one positive and
> one negative y value for the cluster position, so I
> assume the standard two-cluster trigger is being run.
> Mostly composed of a few crystals, although some 
> have as many as seven.
> 
> EcalHits:
> Times in some events range from 4 to over 500 ns.
> About 100 crystals are being hit in each event.
> 
> EcalReadoutHits:
> About a factor of five fewer than EcalHits
> 
> The following have no information in them:
> ConfirmedMCParticles
> SeededMCParticles
> 
> AprimeBeamspotConstrained:
> AprimeTargetConstrained:
> AprimeUnconstrained:
> all either empty or filled with zero values
> 
> FPGAData:
> 12 entries, always 2 ints, 0 floats, 12 doubles, all 23.
> 
> FinalStateParticles:
> either empty or filled with zero values
> 
> HelicalTrackHitRelations:
> seem OK, weights=0
> 
> HelicalTrackHits:
> Lots of events with very few hits. This seems odd to 
> me considering there are at least two clusters in 
> every event.
> 
> HelicalTrackMCRelations:
> seem OK
> 
> MCParticle:
> seems OK, every event begins with pdgid=622 decaying into e+e-e-
> 
> MatchedTracks:
> Very few of these.
> momentum not being calculated.
> 
> ReadoutTimestamps:
> always size three.double values look more like ints
> 
> RotatedHelicalTrackHitRelations:
> seem OK, weights=0
> 
> RotatedHelicalTrackHits:
> seem OK, just very few of them
> 
> RotatedHelicalTrackMCRelations:
> seems OK, weights=0
> 
> SVTFittedRawTrackerHits:
> SVTRawTrackerHits:
> There are a lot more of these than trackerhits
> 
> SVTShapeFitParameters:
> always 7 doubles, one of which is always 33.600, the other NaN
> 
> SVTTrueHitRelations
> Many-to-one, weights=0
> 
> StripClusterer_SiTrackerHitStrip1D:
> seems OK
> 
> TrackerHits:
> seems OK
> 
> Bottom line, no bumps found.
> 
> Perhaps we can discuss some of these issues tomorrow.
> Norman
> 
> ________________________________________
> From: [log in to unmask] [[log in to unmask]] On Behalf Of Sho Uemura [[log in to unmask]]
> Sent: Tuesday, April 08, 2014 9:34 PM
> To: hps-software
> Subject: mock data testing sample
> 
> http://www.slac.stanford.edu/~meeg/hps2/meeg/mock_data/
> 
> This is one file with 13348 tridents (no A' signal) with all backgrounds,
> after readout simulation (HPS2014ReadoutToLcio.lcsim) and reconstruction
> (HPS2014TruthOfflineRecon.lcsim). The full mock data sets will be roughly
> 2500x this size, each.
> 
> All readout and recon LCIO collections have been kept in this file,
> including truth information; actual mock data will have only raw data (ADC
> counts in ECal and SVT) and reconstruction output (clusters, tracks,
> reconstructed particles) - just like real reconstructed data.
> 
> For analysis, the AprimeUnconstrained, AprimeBeamspotConstrained and
> AprimeTargetConstrained collections are what you want.
> 
> No GBL track refit yet. No DST yet (coming soon).
> 
> This is meant to give people a chance to start working on analysis; it's
> also meant to get some eyes on the readout simulation and the
> reconstruction, both of which are still works in progress and need to be
> tested before they're used for the MDC. I'm sure people will need some
> help working with these files, and I'm sure there are still bugs; e-mail
> the list about either.
> 
> ########################################################################
> 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