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
|
