Print

Print


Matt, did you check if the single (strip cluster) hit efficiency seem ok (maybe I missed that in the previous emails)?

If it’s any help we haven’t seen this problem in the test run as far as I know earlier. I think I also would have seen such a large problem in the GBL work I’ve done ( looked ad 

Omar has been looking at hit efficiency and I think he finds reasonable values in simulation before. He should comment but I think he also checked the 3D hit efficiency and not only strip cluster efficiencies? Not sure how easy it is but it might be worth to run your efficiency code Omar on some files that have this low number of 3D hits. 


/Pelle


On Apr 18, 2014, at 10:11 AM, Mathew Graham <[log in to unmask]> wrote:

> Done. 
> 
> https://jira.slac.stanford.edu/browse/HPSJAVA-99
> 
> 
> On Apr 18, 2014, at 9:58 AM, Graf, Norman A. <[log in to unmask]> wrote:
> 
>> Hello Matt, Sho,
>> It might be useful to open up some jira items so we can track (and document) some of these issues for future reference.
>> Enjoy the weekend,
>> Norman
>> 
>> ________________________________________
>> From: [log in to unmask] [[log in to unmask]] On Behalf Of Mathew Graham [[log in to unmask]]
>> Sent: Friday, April 18, 2014 9:48 AM
>> To: hps-software
>> Subject: Re: mock data testing sample
>> 
>> 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
> 
> ########################################################################
> 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