Print

Print




This brings up another point.  Why (seemingly) has the DST maker not been run and checked on our recon datasets in over 4 months?  Why don’t we simply inline the DST maker task in the recon production script that runs on the batch system when we convert from EVIO to LCIO?  (I assume it runs fast enough to include in the same job as the recon.)  This will have the immediate advantage that any catastrophic problems like this from generating the ROOT files will be immediately found out.

​I thought DST's were recently generated for the December data.  What this not the case?​
 


Not super-recently, but in February….



—Jeremy

On May 10, 2015, at 10:57 PM, Graf, Norman A. <[log in to unmask]> wrote:

> Hello Nathan, et al.,
> I've tracked down the problem to a mismatch in how we read and write the SIOCluster from within hps/lcsim and natively from lcio (both java and C++). I can read the files with a locally modified version of the lcio code, both with C++ and java, but I need to figure out how best to solve the problem before proceeding with a fix.
> Apologies for the delay,
> Norman
> ________________________________________
> From: [log in to unmask] <[log in to unmask]> on behalf of Nathan Baltzell <[log in to unmask]>
> Sent: Friday, May 8, 2015 7:37 AM
> To: hps-software
> Subject: problem reading latest slcio files
>
> Hi Everyone,
>
> Has anyone successfully used the C++ API to read the latest pass0 SLCIO files:
> /mss/hallb/hps/engrun2015/
>
> In my analysis code,  IO::LCReader->readNextEvent() is always returning zero.
> Rafayel has the same issue, and also says hps_dump_event from the DST doesn’t
> work (which presumably uses the same API).
>
> The lcio print command from here doesn’t work either:
> svn://svn.freehep.org/lcio/
>
> On some files I get an “Out of Memory” error after this:
> at hep.lcio.implementation.sio.SIOParticleID.<init>(SIOParticleID.java:26)
>
> On others I get:
> Exception in thread "main" java.lang.NegativeArraySizeException
>        at hep.lcio.implementation.sio.SIOParticleID.<init>(SIOParticleID.java:26)
>
>
> None of the above problems existed on 2014 data nor on data we reconstructed with
> ecal-only over the previous weeks.  And now we can’t analyze data.  Any ideas to fix this?
>
> -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




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