 |
 |
Hi Alessandra, So the problem is that while ECal3 was modified a ~year ago to allow separate parameters for top and bottom beam gaps instead of just one, the reconstruction code later broke backward compatibility by assuming the separate parameters were used. If you want you can try this jar which I believe may fix it, although I didn't test it (would be easier if you point me to a lcsim file in question): /home/baltzell/hps-distribution-3.9-SNAPSHOT-bin.jar If you try that jar, let me know what happens. I cannot commit it at the moment due to checkstyle violations ... -Nathan On Jun 1, 2016, at 6:57 AM, Alessandra Filippi <[log in to unmask]> wrote: > ok, right. I'm using the hps-java version from the trunk (3.9). lcsim updated as well to the trunk, and re-compiled. > This is the sequence of commands I give, for a v1 nominal geometry for instance: > > - slic > slic -i $DATA/ap2.2gev075mev.stdhep -o "slic_EngRun2015-Nominal-v1" -g > $HPS/hps_trunk_3.9/detector-data/detectors/HPS-EngRun2015-Nominal-v1/HPS-EngRun2015-Nominal-v1 > -x -d0 -r 100000 > > - readout without pileup (no filtering, right?) > java -DdisableSvtAlignmentConstants -XX:+UseSerialGC -Xmx500m -jar hps-distribution.jar HPS2014ReadoutNoPileup.lcsim -i slic_EngRun2015-Nominal-v1.slcio -DoutputFile=out_readout_v1_noPileup -Ddetector=HPS-EngRun2015-Nominal-v1 -Drun=0 > > - recon without pileup > java -DdisableSvtAlignmentConstants -XX:+UseSerialGC -Xmx500m -jar > hps-distribution.jar HPS2014OfflineNoPileupRecon.lcsim -i out_readout_v1_noPileup.slcio > -DoutputFile=out_recon_v1 -Ddetector=HPS-EngRun2015-Nominal-v1 -Drun=0 > > (this lcsim's used to work some time ago), and the traceback is the following: > > --------------------------------------------------------- > > INFO: Event 0 with sequence 0 > ***************************************************************** > ** You Requested a Running Pedestal, but it is NOT available. ** > ** Reverting to the database. Only printing this ONCE. ** > ***************************************************************** > java.lang.NullPointerException > at org.hps.recon.ecal.cluster.ClusterEnergyCorrection.computeCorrectedEnergy(ClusterEnergyCorrection.java:122) > at org.hps.recon.ecal.cluster.ClusterEnergyCorrection.calculateCorrectedEnergy(ClusterEnergyCorrection.java:53) > at org.hps.recon.ecal.cluster.ClusterEnergyCorrection.setCorrectedEnergy(ClusterEnergyCorrection.java:79) > at org.hps.recon.ecal.cluster.ClusterUtilities.applyCorrections(ClusterUtilities.java:369) > at org.hps.recon.particle.ReconParticleDriver.makeReconstructedParticles(ReconParticleDriver.java:368) > at org.hps.recon.particle.ReconParticleDriver.process(ReconParticleDriver.java:470) > at org.hps.recon.particle.HpsReconParticleDriver.process(HpsReconParticleDriver.java:132) > at org.lcsim.util.Driver.doProcess(Driver.java:261) > at org.lcsim.util.Driver.processChildren(Driver.java:271) > at org.lcsim.util.Driver.process(Driver.java:187) > 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:151) > at org.lcsim.job.JobControlManager.run(JobControlManager.java:962) > at org.hps.job.JobManager.main(JobManager.java:32) > > > ------------------------------------ > > which is similar (I think) to the issue reported by Kyle in this thread > https://listserv.slac.stanford.edu/cgi-bin/wa?A2=ind1602&L=HPS-SOFTWARE&P=R2982&1=HPS-SOFTWARE&9=A&J=on&d=No+Match%3BMatch%3BMatches&z=4 > > The final suggestion in the thread is to use HPS-PhysicsRun2015-Nominal-v4-4. > But I am not user about SVT - I believe that this version already contains the best aligned geometry, am I wrong? I just need a plain SVT geometry. > > For the moment, I'll try as suggested by Nathan to perform just the tracking through SVT as actually I am only interested in this. > Or, maybe the lcsim file I'm using is too out of date. > Is there any raccommended .lcsim file to reconstruct data more suitable to be used with the most updated hps-java version? > Thanks, cheers > Alessandra > > > > > > > > > On Tue, 31 May 2016, McCormick, Jeremy I. wrote: > >> Need more specifics to help... >> >> What command are you running and what's the traceback? What is the hps-java version? (trunk?) >> >> Since the new ECal detector model is not used in any of the existing detectors, I'm pretty sure that's not the problem here. :) >> >> -----Original Message----- >> From: [log in to unmask] [mailto:[log in to unmask]] On Behalf Of Nathan Baltzell >> Sent: Tuesday, May 31, 2016 11:19 AM >> To: Alessandra Filippi >> Cc: hps-software >> Subject: Re: which version of hps-java to run with nominal geometry >> >> Hi Alessandra, >> >> If the problem you have is only with ecal reconstruction but you only need tracking, one immediate temporary fix could be to turn off ecal reconstruction. >> >> Comparing HPS-Engrun2015-v0/1 with the more recent detectors, looks like the ecal model is the same, just different y-offsets. Can you post the full error messages? Does Kyle remember what he did to work around this problem previously? >> >> -Nathan >> >> >> On May 31, 2016, at 12:25, Alessandra Filippi <[log in to unmask]> wrote: >> >>> Hi all, >>> I have a potentially stupid issue which is blocking me since a few days. >>> I want to make some simple tests on geometry and simple millepede >>> behavior (to understands systematics in a starting situation) and need >>> to run the reconstruction on some mc data using a plain nominal >>> geometry, say >>> HPS-EngRun2015-v1 (or v0). >>> I have updated the hps-java code but I am not able to run the reconstruction with any lcsim file as I always get an error on Ecal.ClusterEnergy, that was an issue already noted by Kyle once ago and was related to a different geometry version expected for Ecal by the newest code, if I understood correctly. Right? >>> So... since with the updates I lost track of the hps-java version I >>> used when running the tracking with nominal geometry, does anyone recall which is the latest hps-java version that must be run in this case? >>> >>> Or, to be backward (or forward) compatible, would it be very wrong to create a new hybrid "v0" (say 2016) with nominal svt geometry parameters and the newest ones for the Ecal? Of course I can always disable SvtAlignmentConstants and reconstruct with a nominal SVT geometry, but I need to run slic also, so I need to produce the proper lcdd file as well. >>> Any suggestion is welcome. >>> Thanks, 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