Hi Graham,
no, actually there is no reason why I needed this run number. Actually,
since I run montecarlo data, I would prefer it to be zero, so to be
consistent with the expected behavour described by Jeremy yesterday.
Maybe the fact that with I cannot reconstruct tracks correctly with run
number 0 is that also the readout used 4888 as run number - I try to
freeze everything using zero everywhere now, let's see if I can improve
the situation.
> Jeremy, one thing we really really need is a way to specify a run number for conditions but still use the geometry from the given compact.xml...
I agree (at least in the present development stage)
thanks, cheers
Alessandra
>
> +-----------+---------+---------------+---------------------------------------------------------+
> | run_start | run_end | collection_id | notes
> +-----------+---------+---------------+---------------------------------------------------------+
> | 0 | 0 | 1012 | nominal alignment settings
> | 5259 | 5376 | 1010 | 1.5 mm SVT opening angle for runs 5259 to 5376
> | 5037 | 5063 | 1011 | 3 mm SVT opening angle for runs 5037 to 5063
> | 5066 | 5070 | 1013 | 2 mm SVT angle for runs 5066 to 5070
> | 5222 | 5229 | 1015 | SVT open for runs 5222 to 5229
> | 4847 | 5036 | 1014 | 4mm opening angle for runs 4847 to 5036 (needs confirm)
> | 5632 | 5706 | 1012 | 0.5 mm opening angle for runs 5632 to 5706
> +-----------+---------+---------------+---------------------------------------------------------+
>
>
>> On May 28, 2015, at 3:38 AM, Alessandra Filippi <[log in to unmask]> wrote:
>>
>> at the end of the reconstruction with run=4888 this is what I get:
>>
>> GBLOutputDriver: Total Number of Events = 20000
>> GBLOutputDriver: Total Number of Tracks = 1421
>> GBLOutputDriver: Total Number of Tracks Processed = 1421
>>
>> so, I really do not know the answer: which geometry is it taking?
>> (it should have found some 30000 tracks).
>> How can I tell the reconstruction to pick my compact.xml?
>>
>>
>>
>>
>>
>>
>> On Thu, 28 May 2015, McCormick, Jeremy I. wrote:
>>
>>> "Please don't ask me to update my trunk."
>>>
>>> Please update the hps-java trunk and rebuild it.
>>>
>>> You must do this or everything is likely to be broken in your working copy due to some changes that I made to lcsim and hps-java.
>>>
>>> If that doesn't fix things let us know.
>>>
>>> See yesterday's detailed email about branching. I think it would be a good idea to do this once you get everything working again, and that will protect you from getting unwanted changes in your development copy of the code.
>>> ________________________________________
>>> From: [log in to unmask] <[log in to unmask]> on behalf of Alessandra Filippi <[log in to unmask]>
>>> Sent: Thursday, May 28, 2015 1:53 AM
>>> To: hps-software
>>> Subject: hps-java reconstruction crash
>>>
>>> Hi all,
>>> this morning I am not able to run reconstruction on mc data anymore, there
>>> is a condition error - yesterday evening everything was ok. Here my
>>> command and the traceback:
>>>
>>>> java -jar hps_distribution.jar HPS2014OfflineNoPileupRecon.lcsim
>>> -i nopileup_readout_EngRun2015-Nominal-v1.slcio
>>> -DoutputFile=nopileup_rec_EngRun2015-Nominal-v1_rot0_20000 -n 20000
>>>
>>> Thu May 28 10:30:53 CEST 2015 org.hps.conditions.svt.SvtDetectorSetup
>>> loadDefault
>>> INFO: loading SVT conditions onto subdetector Tracker
>>> Exception in thread "main" java.lang.NullPointerException
>>> at
>>> org.hps.conditions.svt.SvtDetectorSetup.loadDefault(SvtDetectorSetup.java:135)
>>> at
>>> org.hps.conditions.svt.SvtDetectorSetup.conditionsChanged(SvtDetectorSetup.java:113)
>>> at
>>> org.lcsim.conditions.ConditionsManagerImplementation.fireConditionsChanged(ConditionsManagerImplementation.java:122)
>>> at
>>> org.lcsim.conditions.ConditionsManagerImplementation.setConditionsReader(ConditionsManagerImplementation.java:69)
>>> at
>>> org.lcsim.conditions.ConditionsManagerImplementation.setDetector(ConditionsManagerImplementation.java:53)
>>> at
>>> org.hps.conditions.database.DatabaseConditionsManager.initialize(DatabaseConditionsManager.java:666)
>>> at
>>> org.hps.conditions.database.DatabaseConditionsManager.setDetector(DatabaseConditionsManager.java:1036)
>>> at
>>> org.hps.conditions.ConditionsDriver.initialize(ConditionsDriver.java:136)
>>> at org.hps.job.JobManager.setupConditions(JobManager.java:77)
>>> at org.hps.job.JobManager.run(JobManager.java:52)
>>> at org.lcsim.job.JobControlManager.run(JobControlManager.java:189)
>>> at org.hps.job.JobManager.main(JobManager.java:23)
>>>
>>>
>>> In the .lcsim file I set run number 4888, and then freezeze it. If I set it
>>> to zero, I get the same error. If I eliminate the call to
>>> ConditionDrivers, I get the following traceback:
>>>
>>> INFO: loading SVT conditions onto subdetector Tracker
>>> java.lang.NullPointerException
>>> at
>>> org.hps.conditions.svt.SvtDetectorSetup.loadDefault(SvtDetectorSetup.java:135)
>>> at
>>> org.hps.conditions.svt.SvtDetectorSetup.conditionsChanged(SvtDetectorSetup.java:113)
>>> at
>>> org.lcsim.conditions.ConditionsManagerImplementation.fireConditionsChanged(ConditionsManagerImplementation.java:122)
>>> at
>>> org.lcsim.conditions.ConditionsManagerImplementation.setConditionsReader(ConditionsManagerImplementation.java:69)
>>> at
>>> org.lcsim.conditions.ConditionsManagerImplementation.setDetector(ConditionsManagerImplementation.java:53)
>>> at
>>> org.hps.conditions.database.DatabaseConditionsManager.initialize(DatabaseConditionsManager.java:666)
>>> at
>>> org.hps.conditions.database.DatabaseConditionsManager.setDetector(DatabaseConditionsManager.java:1036)
>>> at
>>> org.lcsim.event.base.BaseLCSimEvent.<init>(BaseLCSimEvent.java:48)
>>> at org.lcsim.lcio.LCIOEvent.<init>(LCIOEvent.java:62)
>>> at org.lcsim.lcio.LCIOEvent.<init>(LCIOEvent.java:25)
>>> at org.lcsim.lcio.LCIOReader.read(LCIOReader.java:59)
>>> at
>>> org.lcsim.util.loop.LCIOEventSource.next(LCIOEventSource.java:129)
>>> at
>>> org.freehep.record.loop.DefaultRecordLoop.fetchRecord(DefaultRecordLoop.java:809)
>>> at
>>> org.freehep.record.loop.DefaultRecordLoop.loop(DefaultRecordLoop.java:648)
>>> at
>>> org.freehep.record.loop.DefaultRecordLoop.execute(DefaultRecordLoop.java:566)
>>> at org.lcsim.util.loop.LCSimLoop.loop(LCSimLoop.java:153)
>>> at org.lcsim.job.JobControlManager.run(JobControlManager.java:431)
>>> at org.hps.job.JobManager.run(JobManager.java:55)
>>> at org.lcsim.job.JobControlManager.run(JobControlManager.java:189)
>>> at org.hps.job.JobManager.main(JobManager.java:23)
>>>
>>>
>>> Please don't ask me to update my trunk. I wouldn't (have) like(d) to
>>> update it to the newest changes as long as I am not sure that everything
>>> is backward compatible with what I have been doing until yesterday on
>>> alignment studies and tests with mc data (which does not seem to be the
>>> case, just as a start).
>>> Actually, I was going to ask you too freeze a branch to version 3030, the
>>> last one prior to last Jeremy's changes, but you were too fast... :-(
>>> cheers
>>> Alessandra
>>>
>>> ########################################################################
>>> 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
