 |
 |
Hi Norman, Some of the SIOReader methods seem to work e.g. getNumberOfEvents(), however, as Nathan said, readNextEvent() always returns zero so the DST maker will always exit without processing the file. I'll dig into this a bit more ... On Wed, May 13, 2015 at 9:44 AM, Graf, Norman A. <[log in to unmask]> wrote: > Thanks for the feedback Omar. I only checked some of the lcio utility > executables, and didn’t build the > > DST maker myself. I’ll try that now. > > Norman > > > > *From:* [log in to unmask] [mailto:[log in to unmask]] *On Behalf Of *Omar > Moreno > *Sent:* Wednesday, May 13, 2015 9:43 AM > *To:* Graf, Norman A. > *Cc:* Nathan Baltzell; hps-software > > *Subject:* Re: problem reading latest slcio files > > > > Hi, > > > > I checked out the LCIO branch and rebuilt the DST maker and I'm still > seeing the same issue that Nathan reported. Anybody else have any luck > running over the new recon files with this branch? > > > > --Omar Moreno > > > > On Tue, May 12, 2015 at 1:37 PM, Graf, Norman A. <[log in to unmask]> > wrote: > > Hello All, > For those of you who want/need to analyze the latest reconstruction output > right away (and I encourage everyone to do so!) I have created a branch of > lcio > which addresses the SIOCluster problem. > > svn co svn://svn.freehep.org/lcio/branches/hps-2015-branch > > This should allow you to use both the C++ and java native lcio classes to > access > the latest reconstruction file. > > ***THIS BRANCH SHOULD ONLY BE USED WITH THE LATEST RECONSTRUCTION > OUTPUT!*** > > We only have a few more days of data taking, so please don't wait until > it's over to find any problems with the data. > > Please let me know right away if you encounter any difficulties. > Norman > > -----Original Message----- > From: Nathan Baltzell [mailto:[log in to unmask]] > Sent: Tuesday, May 12, 2015 1:18 PM > To: Omar Moreno > Cc: McCormick, Jeremy I.; Graf, Norman A.; hps-software > > Subject: Re: problem reading latest slcio files > > > > Why (seemingly) has the DST maker not been run and checked on our recon > datasets in over 4 months? > > People have been using the C++ API successfully (presumably the same one > the DST maker uses) on lcio files created many different times and ways > over the previous months up to a couple weeks ago, even on April data, but > only on ECal-Only recon. > > -Nathan > > > > On May 12, 2015, at 4:03 PM, Omar Moreno <[log in to unmask]> wrote: > > > > > > > On Tue, May 12, 2015 at 12:59 PM, McCormick, Jeremy I. < > [log in to unmask]> wrote: > > 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. > > > > I thought DST's were recently generated for the December data. What > > this not the case? > > > > —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 > > > ######################################################################## 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