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
|