Hi Brad,
The DSTs appear to not have any of the trigger bits set in this MC. Does
anyone know if this is just a DST problem?
-Holly
On Wed, Aug 17, 2016 at 2:08 PM, Bradley T Yale <[log in to unmask]>
wrote:
> The 2.3 GeV wab, tritrig, and wab-beam-tri are done now, as well as 1.056,
> with working DSTs this time.
>
>
> So to reiterate, MC with all of the most recent fixes after the summit, at
> both energies, is in
>
>
> /mss/hallb/hps/production/postTriSummitFixes/
>
>
> The fixes include:
>
> Unweighted WAB events
>
> Suppressed WABs in egs beam background, which were handled incorrectly
>
> New v5 detector without erroneous material
>
> Updated target thickness
>
> Target offset by -5mm
> ------------------------------
> *From:* [log in to unmask] <[log in to unmask]>
> on behalf of Bradley T Yale <[log in to unmask]>
> *Sent:* Tuesday, August 16, 2016 8:11:52 PM
> *To:* Omar Moreno
> *Cc:* McCormick, Jeremy I.; Graham, Mathew Thomas; hps-software; Uemura,
> Sho
>
> *Subject:* Re: [Hps-analysis] New WABs
>
>
> The rerun 1pt05 DSTs are finished:
>
>
> /mss/hallb/hps/production/postTriSummitFixes/dst/
>
>
> They appear to be getting filled this time.
>
> While I deleted the ones using the 08/10/16 jar before Sho spotted a
> mistake in the geometry, some of them may still be on cache.
>
> So please be sure to use only the ones labelled '3.10-201608*13*'.
>
>
> The 2pt3 is at readout now, and seem to be completing that stage without
> any problems.
> ------------------------------
> *From:* [log in to unmask] <[log in to unmask]> on behalf of Omar
> Moreno <[log in to unmask]>
> *Sent:* Monday, August 15, 2016 5:33:16 PM
> *To:* Omar Moreno
> *Cc:* McCormick, Jeremy I.; Bradley T Yale; Graham, Mathew Thomas;
> hps-software; Uemura, Sho
> *Subject:* Re: [Hps-analysis] New WABs
>
> Alright, the DST maker seems to work now. I tested using the following
> file:
>
> /cache/mss/hallb/hps/production/postTriSummitFixes/recon/wab
> /1pt05/wabv2_10to1_HPS-EngRun2015-Nominal-v5-0-fieldmap
> _3.10-20160813_pairs1_1.slcio
>
> The DST maker processed 256 events and the root file was filled. If that's
> not one of the latest files, let me know. You will need to set the
> following environmental variables before running:
>
> setenv ROOTSYS /apps/root/5.34.13/root
> setenv PATH ${PATH}:${ROOTSYS}/bin
> setenv LD_LIBRARY_PATH ${ROOTSYS}/lib
>
> setenv LCIO /u/group/hps/hps_soft/lcio/v02-07
> setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:${LCIO}/lib
>
> setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:/apps/gcc/4.8.2/lib64
>
> If you run the script /group/hps/setup_dst.csh, it should set your
> environment up such that you can run the dst maker without issues. The
> executable is located in /group/hps/hps_soft/hps-dst/bin. Let me know if
> you have any questions or if it fails to run correctly.
>
> --Omar Moreno
>
>
> On Mon, Aug 15, 2016 at 2:14 PM, Omar Moreno <[log in to unmask]> wrote:
>
>> I'm testing now.
>>
>> On Mon, Aug 15, 2016 at 2:12 PM, McCormick, Jeremy I. <
>> [log in to unmask]> wrote:
>>
>>> Don't use the LCIO branch -- you should use trunk instead. I sent an
>>> email about this issue last week to the software list with all the
>>> details. At least, I'm assuming that this is a problem with new SLIC and
>>> using an LCIO that doesn't support one specific change to the MCParticle
>>> class. The LCIO C++ trunk should handle this fine, and lcsim should be
>>> able to read new and old files just fine.
>>>
>>> We basically just need to build a version of hps-dst using LCIO trunk,
>>> and then I think this problem should go away. I'm testing this locally
>>> now.
>>>
>>> Do you want me to build it at JLAB? (Or Omar can?)
>>>
>>> -----Original Message-----
>>> From: [log in to unmask] [mailto:[log in to unmask]
>>> ford.edu] On Behalf Of Bradley T Yale
>>> Sent: Monday, August 15, 2016 1:23 PM
>>> To: Omar Moreno
>>> Cc: Graham, Mathew Thomas; hps-software; Uemura, Sho
>>> Subject: Re: [Hps-analysis] New WABs
>>>
>>> It's probably related to this:
>>>
>>> https://jira.slac.stanford.edu/browse/HPSJAVA-674
>>>
>>>
>>>
>>> I notice the dst_maker is still being built using
>>> /home/hps/hps_soft/lcio/v02-06
>>>
>>>
>>> instead of the newer 'collection_type_fix' version (as Maurik mentioned).
>>>
>>>
>>>
>>>
>>>
>>> However, when trying to build the 'collection_type_fix' version at JLab,
>>> I get an error about using the correct JDK:
>>>
>>>
>>>
>>>
>>> [freehep.ant] BUILD FAILED
>>> [freehep.ant] /u/group/hps/hps_soft/lcio/col
>>> lection_type_fix/trunk/build.xml:283: Unable to find a javac compiler;
>>> [freehep.ant] com.sun.tools.javac.Main is not on the classpath.
>>> [freehep.ant] Perhaps JAVA_HOME does not point to the JDK
>>>
>>> Currently, JAVA_HOME is set to
>>> /apps/scicomp/java/jdk1.7
>>>
>>> This is probably simple enough to fix though.
>>>
>>>
>>> ________________________________
>>>
>>> From: [log in to unmask] <[log in to unmask]> on behalf of Omar
>>> Moreno <[log in to unmask]>
>>> Sent: Monday, August 15, 2016 2:16:15 PM
>>> To: Bradley T Yale
>>> Cc: Graham, Mathew Thomas; [log in to unmask]; Uemura, Sho
>>> Subject: Re: [Hps-analysis] New WABs
>>>
>>> The DST issue might have to do with the LCIO version that the DST maker
>>> is being linked against. After Jeremy's patch of LCIO, the trunk of C++
>>> LCIO is required to the newest recon files. I'll look into it in a bit.
>>>
>>> On Mon, Aug 15, 2016 at 10:58 AM, Bradley T Yale <[log in to unmask]>
>>> wrote:
>>>
>>>
>>> When looking at the recon events (.slcio), the file size looks
>>> normal, but when printing the collections from the events:
>>>
>>>
>>>
>>>
>>> java -jar /group/hps/hps_soft/lcio/jarfi
>>> les/lcio-2.4.4-SNAPSHOT-bin.jar print -H /cache/mss/hallb/hps/productio
>>> n/postTriSummitFixes/recon/wab/1pt05/wabv2_10to1_HPS-EngRun2
>>> 015-Nominal-v5-0-fieldmap_3.10-20160813_pairs1_338.slcio
>>>
>>>
>>> It prints one event, and then the error:
>>>
>>>
>>>
>>>
>>> Exception in thread "main" java.lang.OutOfMemoryError: Requested
>>> array size exceeds VM limit
>>> at java.util.Arrays.copyOf(Arrays.java:2245)
>>> at java.util.Arrays.copyOf(Arrays.java:2219)
>>> at java.util.Vector.grow(Vector.java:262)
>>> at java.util.Vector.ensureCapacit
>>> yHelper(Vector.java:242)
>>> at java.util.Vector.setSize(Vector.java:285)
>>> at hep.io.sio.SIOInputStream.read
>>> PTag(SIOInputStream.java:43)
>>> at hep.lcio.implementation.sio.SI
>>> OMCParticle.<init>(SIOMCParticle.java:30)
>>> at hep.lcio.implementation.sio.SI
>>> OEvent.readData(SIOEvent.java:122)
>>> at hep.lcio.implementation.sio.SI
>>> OLCReader.readNextEvent(SIOLCReader.java:120)
>>> at hep.lcio.implementation.sio.SI
>>> OLCReader.readNextEvent(SIOLCReader.java:148)
>>> at hep.lcio.util.Printer.print(Printer.java:110)
>>> at hep.lcio.util.PrintCommandHand
>>> ler.execute(PrintCommandHandler.java:89)
>>> at hep.lcio.util.CommandLineTool.
>>> parse(CommandLineTool.java:219)
>>> at hep.lcio.util.CommandLineTool.
>>> main(CommandLineTool.java:126)
>>>
>>>
>>>
>>>
>>> Does anyone else know about this problem? Being Java-related, I
>>> wouldn't think that it would affect the DST maker though.
>>>
>>>
>>>
>>>
>>> Also, did anyone work on the JLab DST maker recently?
>>>
>>>
>>> I see some new stuff in the source code dated July 28, which I
>>> think is more recent than the last batch of working DSTs...
>>>
>>>
>>> ________________________________
>>>
>>> From: Bradley T Yale
>>> Sent: Monday, August 15, 2016 12:49:06 PM
>>> To: Graham, Mathew Thomas
>>> Cc: Uemura, Sho
>>> Subject: Re: [Hps-analysis] New WABs
>>>
>>>
>>> The recon logs look ok, but then no events were written in the
>>> dst for some reason, with no errors reported.
>>>
>>> I'll check it out.
>>>
>>>
>>> ________________________________
>>>
>>> From: Graham, Mathew Thomas <[log in to unmask]>
>>> Sent: Monday, August 15, 2016 12:26:35 PM
>>> To: Bradley T Yale
>>> Cc: Uemura, Sho
>>> Subject: Re: [Hps-analysis] New WABs
>>>
>>> tritrig DSTs all look empty too...
>>>
>>>
>>> On Aug 15, 2016, at 9:13 AM, Graham, Mathew Thomas <
>>> [log in to unmask]> wrote:
>>>
>>>
>>> -rw-r--r-- 1 mgraham
>>>
>>>
>>>
>>> ________________________________
>>>
>>> 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-SOF
>>> TWARE&A=1 <https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SO
>>> FTWARE&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
>
> ------------------------------
>
> 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
