 |
 |
This is looking much better now. Thanks! > On May 7, 2014, at 6:54 PM, "Sho Uemura" <[log in to unmask]> wrote: > > The steering file I'm using for MDC recon is > HPS2014OfflineTruthRecon.lcsim. HPS2014OfflineRecon.lcsim probably won't > give you good tracks, either. > > (The difference is in how hit times are referenced in ECal and SVT.) > >> On Wed, 7 May 2014, Omar Moreno wrote: >> >> Oops, yeah, you're right. I was looking at a recon file I generated when >> running the reconstruction not the readout file. >> >> Either way, when I run the reconstruction using the steering file >> HPS2014OfflineRecon, I'm not seeing clusters in the recon file that is >> generated. Is anybody else having this issue?? >> >> >>> On Wed, May 7, 2014 at 5:56 PM, Sho Uemura <[log in to unmask]> wrote: >>> >>> That's the readout file, not the recon file. The readout file will >>> naturally not contain clusters. >>> >>> >>> On Wed, 7 May 2014, Omar Moreno wrote: >>> >>> Hi Sho and Jeremy, >>>> >>>> I just noticed that the readout file found here: >>>> >>>> http://www.slac.stanford.edu/~meeg/hps2/meeg/mock_data/tritrig-beam-tri >>>> _1-10_readout.slcio >>>> >>>> the collection of Ecal clusters is absent from most events. Looking at >>>> the >>>> clustering driver used in HPS2014OfflineRecon, EcalClusterICBasic, it >>>> looks >>>> like an empty collection is added to every event. Maybe the readout file >>>> was generated before this was put in? >>>> >>>> This is also another reason why ReconstructedParticles were not being >>>> written to every event since I require that the event have a collection >>>> of >>>> Ecal clusters before I run the driver (I was trying to save time). With >>>> the fix I applied it will write an empty collection regardless but it >>>> still >>>> won't run the ReconstructedParticle maker without clusters. I'm just >>>> going >>>> to remove this condition and run the ReconstructedParticle maker >>>> regardless. >>>> >>>> --Omar Moreno >>>> >>>> >>>> On Wed, May 7, 2014 at 4:53 PM, Omar Moreno <[log in to unmask]> wrote: >>>> >>>> >>>>> >>>>> On Wed, May 7, 2014 at 4:32 PM, McCormick, Jeremy I. <[log in to unmask] >>>>> stanford.edu> wrote: >>>>> >>>>> Hi, Omar. >>>>>> >>>>>> I'm just going to CC this thread to the software list from now. >>>>>> >>>>>> I can run the reconstruction now over all the events in this file after >>>>>> your fix: >>>>>> >>>>>> >>>>>> http://www.slac.stanford.edu/~meeg/hps2/meeg/mock_data/ >>>>>> tritrig-beam-tri_1-10_readout.slcio >>>>>> >>>>>> I am using the steering file HPS2014OfflineRecon.lcsim which you >>>>>> recommended. >>>>>> >>>>>> But I am still seeing a lot of problems with the ReconstructedParticle >>>>>> output... >>>>>> >>>>>> 1) Most of the events have no ReconstructedParticle collections in them >>>>>> at all. >>>>>> >>>>>> Every event should have these collections in them, even if they are >>>>>> empty: >>>>>> >>>>>> BeamspotConstrainedV0Candidates >>>>>> FinalStateParticles >>>>>> UnconstrainedV0Candidates >>>>>> TargetConstrainedV0Candidates >>>>> ?I'm aware of this. I have already fixed this locally and will commit it >>>>> later.? >>>>> >>>>> >>>>> >>>>>> If the same set of collections are not present in every event, it >>>>>> becomes >>>>>> clunky to access the data, requiring a lot of unnecessary checks in the >>>>>> Driver code to see if the collection exists. (EventHeader throws fatal >>>>>> exceptions if you try to access a collection that is not there!) >>>>> ?yup ...? >>>>> >>>>> >>>>> >>>>>> 2) For the events that do have ReconstructedParticle collections in >>>>>> them, >>>>>> mostly they are empty, from what I can tell. I just stepped through >>>>>> maybe >>>>>> the first 100 events in the sample, so I would need to confirm that >>>>>> this is >>>>>> true for the 12k events. I only found one collection that had objects >>>>>> in >>>>>> it, and.... >>>>> ?I'll check, but I have seen otherwise.? >>>>> >>>>> >>>>> >>>>>> 3) For the few events that I did find with ReconstructedParticles in >>>>>> them, the data is still all zeros. >>>>> ?I'm filling the momentum, energy and charge so the only things that >>>>> should be empty are mass, particle ID, type and reference point. For the >>>>> vertexed particles, I'm probably going to add the mass as well but it's >>>>> not in there yet. I've checked a few events and they are being filled >>>>> accordingly. ? >>>>> >>>>> >>>>> >>>>>> Can you confirm these problems on your end? Or did I do something wrong >>>>>> here in my configuration? >>>>>> >>>>>> BTW, when running the recon, you might put this Driver into your job >>>>> along >>>>> >>>>>> with the AidaSaveDriver to save the plots: >>>>>> >>>>>> >>>>>> /hps-users/src/main/java/org/hps/users/jeremym/ >>>>>> MockDataChallengeDiagnosticDriver.java >>>>> >>>>> >>>>> It plots basically all of the data in all the collections, so it can be >>>>>> used for diagnostics. >>>>>> >>>>>> Or run its TestCase on your output data (just hand hack the TestCase for >>>>>> now): >>>>>> >>>>>> >>>>>> /hps-users/src/test/java/org/hps/users/jeremym/ >>>>>> MockDataChallengeDiagnosticDriverTest.java >>>>>> >>>>>> Though right now it doesn't plot the ReconstructedParticle collections >>>>>> at >>>>>> all due to issue #1 (I set everything up automatically based on the >>>>>> collections in the first event but for this data set those collections >>>>>> aren't present in the first event!). >>>>>> >>>>>> We can cover these issues in more detail at the software meeting. >>>>>> >>>>>> --Jeremy >>>>>> >>>>>> -----Original Message----- >>>>>> From: Omar Moreno [mailto:[log in to unmask]] >>>>>> Sent: Wednesday, May 07, 2014 2:59 PM >>>>>> To: Uemura, Sho >>>>>> Cc: Graham, Mathew Thomas; McCormick, Jeremy I.; Moreno, Omar >>>>>> Subject: Re: problem running recon on MDC data >>>>>> >>>>>> Ah, OK. Thanks Sho. ? >>>>>> >>>>>> >>>>>> >>>>>> On Wed, May 7, 2014 at 2:58 PM, Sho Uemura <[log in to unmask]> >>>>>> wrote: >>>>>> >>>>>> >>>>>> It's slow because the time cuts are very loose, i.e. right now >>>>>> there is a trade-off between speed and recon efficiency, and we've >>>>>> chosen >>>>>> to maximize efficiency. It's still fast enough for the MDC. >>>>>> >>>>>> >>>>>> On Wed, 7 May 2014, Omar Moreno wrote: >>>>>> >>>>>> >>>>>> >>>>>> My recon is running unusually slow. I thought this >>>>>> issue >>>>>> was fixed but >>>>>> >>>>>> maybe I'm mistaken. Is anyone else having this >>>>>> problem?? >>>>>> >>>>>> >>>>>> >>>>>> On Wed, May 7, 2014 at 2:50 PM, Omar Moreno < >>>>>> [log in to unmask]> wrote: >>>>>> >>>>>> >>>>>> >>>>>> The recon works now. >>>>>> >>>>>> >>>>>> On Tue, May 6, 2014 at 4:04 PM, Mathew Graham < >>>>>> [log in to unmask]>wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Right?that?s pretty unlikely. >>>>>> >>>>>> >>>>>> On May 6, 2014, at 3:10 PM, McCormick, >>>>>> Jeremy I. < >>>>>> >>>>>> [log in to unmask]> wrote: >>>>>> >>>>>> >>>>>> >>>>>> But I'm not sure that >>>>>> explanation >>>>>> makes sense, anyways, because it does >>>>>> >>>>>> >>>>>> get through 173 events before crashing, >>>>>> unless all those events had no >>>>>> tracks and Billoir was not activated >>>>>> until the crash... >>>>>> >>>>>> >>>>>> --Jeremy >>>>>> >>>>>> -----Original Message----- >>>>>> From: Graham, Mathew Thomas >>>>>> Sent: Tuesday, May 06, 2014 2:44 >>>>>> PM >>>>>> To: McCormick, Jeremy I.; >>>>>> Moreno, >>>>>> Omar >>>>>> Cc: Uemura, Sho >>>>>> Subject: Re: problem running >>>>>> recon on MDC data >>>>>> >>>>>> >>>>>> Yes...so I have no answers. >>>>>> >>>>>> On 5/6/2014 2:43 PM, McCormick, >>>>>> Jeremy I. wrote: >>>>>> >>>>>> >>>>>> Okay, I see what you >>>>>> mean. But I'm running the entire reconstruction >>>>>> >>>>>> >>>>>> chain from HPS2014OfflineRecon.lcsim on >>>>>> the simulated readout data. So >>>>>> shouldn't those classes be available? >>>>>> >>>>>> >>>>>> >>>>>> -----Original >>>>>> Message----- >>>>>> From: Graham, Mathew >>>>>> Thomas >>>>>> Sent: Tuesday, May 06, >>>>>> 2014 2:41 PM >>>>>> To: McCormick, Jeremy >>>>>> I.; >>>>>> Moreno, Omar >>>>>> Cc: Uemura, Sho >>>>>> Subject: Re: problem >>>>>> running recon on MDC data >>>>>> >>>>>> >>>>>> That line is casting the >>>>>> track as a SeedTrack and then getting a >>>>>> >>>>>> >>>>>> SeedCandidate...however, you can only do >>>>>> this if you run reconstructions >>>>>> reconstruction since SeedCandidate isn't >>>>>> persisted and isn't even known in >>>>>> lcio. >>>>>> >>>>>> >>>>>> >>>>>> On 5/6/2014 2:01 PM, >>>>>> McCormick, Jeremy I. wrote: >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> I'm attempting >>>>>> to >>>>>> run the current version of the recon on this data >>>>>> >>>>>> >>>>>> from Sho. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> http://www.slac.stanford.edu/~meeg/hps2/meeg/mock_data/tritrig-beam-tr< >>>>>> http://www.slac.stanford.edu/~meeg/hps2/meeg/mock_data/tritrig-beam-tr> >>>>>> >>>>>> >>>>>> >>>>>> i_1-10_readout.slcio >>>>>> >>>>>> However, I get a >>>>>> fatal exception some events into the job. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Event 174 >>>>>> >>>>>> >>>>>> >>>>>> java.lang.NullPointerException >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>> org.hps.recon.particle.HpsReconParticleDriver.toBilliorTrack( >>>>>> HpsReconParticleDriver.java:100) >>>>>> >>>>>> >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>> org.hps.recon.particle.HpsReconParticleDriver.vertexParticles( >>>>>> HpsReconParticleDriver.java:62) >>>>>> >>>>>> >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>> org.hps.recon.particle.ReconParticleDriver.process( >>>>>> ReconParticleDriver.java:142) >>>>>> >>>>>> >>>>>> at >>>>>> org.lcsim.util.Driver.doProcess(Driver.java:273) >>>>>> at >>>>>> org.lcsim.util.Driver.processChildren(Driver.java:284) >>>>>> at >>>>>> org.lcsim.util.Driver.process(Driver.java:198) >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>> org.lcsim.util.DriverAdapter.recordSupplied(DriverAdapter.java:74) >>>>>> >>>>>> >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>> org.freehep.record.loop.DefaultRecordLoop.consumeRecord( >>>>>> DefaultRecordLoop.java:832) >>>>>> >>>>>> >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>> org.freehep.record.loop.DefaultRecordLoop.loop( >>>>>> DefaultRecordLoop.java:668) >>>>>> >>>>>> >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>> org.freehep.record.loop.DefaultRecordLoop.execute( >>>>>> DefaultRecordLoop.java:566) >>>>>> >>>>>> >>>>>> at >>>>>> org.lcsim.util.loop.LCSimLoop.loop(LCSimLoop.java:152) >>>>>> at >>>>>> >>>>>> org.lcsim.job.JobControlManager.run(JobControlManager.java:416) >>>>>> >>>>>> Any idea on what >>>>>> the problem could be and if it can be easily fixed? >>>>>> >>>>>> --Jeremy >>>> ######################################################################## >>>> 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