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