 |
 |
The tpass2.6 has 23 recon slcio files and 18 dsts., while tpass 21 has 39. Is this all jobs, or some of them failed. There are also tpass2.7 ans tpass2.8. They are for some personal tests or I should use them, newest? Rafo On 05/09/2015 21:22, Nathan Baltzell wrote: > FYI: > > 2 new test passes should be finished tomorrow midday: > > /work/hallb/hps/data/engrun2015/tpass2.5 > /work/hallb/hps/data/engrun2015/tpass2.6 > > tpass2.5 has a change that will likely fix errors #2 and #3 > tpass2.6 adds #4 w/ new jar: surveyed ecal geometry > > None have fixes to problems with full field extrapolation that Omar > mentioned. And fixing #1 relies on scipcomp at jlab, which will not > happen until Tuesday. > > -Nathan > > > > On Sep 5, 2015, at 8:17 PM, Sho Uemura <[log in to unmask]> wrote: > >> 3. The first one (DataQuality.lcsim) makes a small text file with average collection sizes - useful for quick debug The second one (DataQualityRecon.lcsim) makes the root histograms. >> >> 5. That's my fault. I'll change it back. >> >> On Sat, 5 Sep 2015, Omar Moreno wrote: >> >>> On Sat, Sep 5, 2015 at 9:53 AM, Nathan Baltzell <[log in to unmask]> wrote: >>> >>>> Hi Everyone, >>>> >>>> The latest test finished yesterday (this one has full-field track >>>> extrapolation to ecal): >>>> /work/hallb/hps/data/engrun2015/tpass2.3 >>>> >>> ?Just FYI, I checked the full field extrapolation yesterday using the 2.3 >>> files, and there seems to be an issue. I'm in the process of debugging it >>> ...? >>> >>> >>>> 1. >>>> Looks like some of the batch farm nodes don't have the links setup for the >>>> latest gcc, >>>> which the dst-maker needs. We hit this problem before pass1 too. I >>>> submitted a CCPR. >>>> >>>> 2. >>>> I noticed this error in every job's log files, but not clear which >>>> hps-java process generated >>>> it, nor when during the process, nor if it matters. Node memory limit is >>>> set to 4 GB (same >>>> as pass1), I will raise that too and see if this error goes away: >>>> >>>> java.lang.OutOfMemoryError: Java heap space >>>> at >>>> sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1248) >>>> at java.lang.Double.parseDouble(Double.java:540) >>>> at >>>> com.mysql.jdbc.ResultSetImpl.getDoubleInternal(ResultSetImpl.java:2517) >>>> at >>>> com.mysql.jdbc.ResultSetImpl.getDoubleInternal(ResultSetImpl.java:2489) >>>> at com.mysql.jdbc.ResultSetImpl.getDouble(ResultSetImpl.java:2450) >>>> at com.mysql.jdbc.ResultSetImpl.getObject(ResultSetImpl.java:4985) >>>> at >>>> org.hps.conditions.api.BaseConditionsObjectCollection.select(BaseConditionsObjectCollection.java:533) >>>> at >>>> org.hps.conditions.api.AbstractConditionsObjectConverter.getData(AbstractConditionsObjectConverter.java:126) >>>> at >>>> org.lcsim.conditions.CachedConditionsImplementation.getCachedData(CachedConditionsImplementation.java:20) >>>> at >>>> org.hps.conditions.svt.AbstractSvtConditionsConverter.getSvtGainCollection(AbstractSvtConditionsConverter.java:128) >>>> at >>>> org.hps.conditions.svt.AbstractSvtConditionsConverter.getData(AbstractSvtConditionsConverter.java:80) >>>> at >>>> org.hps.conditions.svt.SvtConditionsConverter.getData(SvtConditionsConverter.java:54) >>>> at >>>> org.hps.conditions.svt.SvtConditionsConverter.getData(SvtConditionsConverter.java:16) >>>> at >>>> org.lcsim.conditions.CachedConditionsImplementation.getCachedData(CachedConditionsImplementation.java:20) >>>> at >>>> org.hps.conditions.svt.SvtDetectorSetup.conditionsChanged(SvtDetectorSetup.java:82) >>>> 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) >>>> >>>> 3. >>>> We have two steering files being run for data quality (same as pass1): >>>> /org/hps/steering/production/DataQuality.lcsim >>>> /org/hps/steering/production/DataQualityRecon.lcsim >>>> Based on the outputs, looks like only one (the first one, I think) is >>>> producing >>>> something useful that is being saved to disk (root files). Is this >>>> expected? >>>> Probably a question for Matt. >>>> >>>> 4. >>>> I made new detectors for the latest ECal survey with the y-shifts for top >>>> and >>>> bottom from Raphael. I tested them with hps-java, and hits are shifted as >>>> expected, but did not make the lcdd files due to some error about gdml. >>>> Can >>>> someone generate them? HPS-EngRun2015-Nominal-v3* >>>> >>>> 5. >>>> While testing, I noticed the latest trunk is now going to print >>>> EventMarkerDriver >>>> on every event. This makes an extra 100 GB in log files for the full >>>> pass. But ok ? :) >>>> >>>> -Nathan >>>> >>>> ######################################################################## >>>> 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