 |
 |
Hi, My suggestion for fixing this would be to immediately revert the last change to lcsim’s SIOCluster class which broke this (e.g. undo r3842). That makes us compatible going forward. I am already working on this on an lcsim branch. I suggest we not get into making special patches to the C++ code to fix this, as I don’t think it is necessary or desirable to do this and it will quickly become very confusing as to whether a patched or un-patched C++ library is being used. The LCIO data files generated from January to now will still not be readable with C++, though I think they should still be readable into lcsim even after reverting. So we should regenerate them OR we can come up with some kind of patch script. Basically, all that would need to be done for a patch (I think) is to read in these files and then rewrite them. Specifically, the problem here is that there is an integer in the SIOCluster block which should be set to 0 (it is read as an array length) but it is not. Reading and then writing the LCIO events should fix this by overwriting this value with zero again. So I think patching the existing files generated over the last ~4 months is doable if this is actually needed. 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. —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