Most likely the process takes up too much memory when it maps the file. That is why you can only use the last file of a run, because that file usually is much smaller than the 2GB for all the other files. Carl Timmer has nothing to do with this, it is not a bug in Jevio, and we already solved the sequential read issue that would overcome this problem.

We can now copy the files to /w/stage3/BUFFERED and access them from other machines. I verified this works on file hps_004892.evio.0 using the svt_timing_in_monitoring I was trying to run this morning. So this is one good option.

I think that the SVT Monitoring steering files had code in them that was not checked in, so I could not run these from my own jar file that can do the sequential read. I don’t know how I can get some methods from one Jar and combine these with methods from another Jar. In other words, I don’t know how to “link” Omar’s jar with my Jevio.jar the way I could for compiled code with LD_PRELOAD. Is there a Java equivalent?

From the clondaq5 machine, it is a tall order to get the huge crash dump from the screen into an email message. You cannot pipe it into “mail -c [log in to unmask]”, because sendmail is not setup. I would need to somehow get it into a file, transfer the file to the outside, then import it into my laptop and send it to you. It can be done, but when you are under real time pressure to get things done, that is too many steps and too many passwords. I was able to do this now while we are waiting for beam restoration.
Attached files: crash1.txt is when running from clondaq5 and opening an EVIO file. crash2.txt shows the crash when I run the svt_monitoring from my own hps-distribution-bin.jar. The error messages are not very clear, but I think in the latter case there are resources missing in the jar. I think Omar just checked in all the code required, so I will try again with a “latest”.

I do not have the tools to upload the new jevio jar so that we can have that in our distribution instead of the old one. I don’t understand why you are taking so long doing this, since this is a 100% solved issue, as I told you before. The new jar is a drop in for the old one.
There is no issue on a normal machine, or when running sequential mode, to open any of the evio.x files. IF you are running on clondaq5, then only the smaller files seem to work (I haven’t tried this)

It used to be the opposite, where the last file would not open if the DAQ had crashed, and we have had a lot of DAQ crashes. That issue was successfully fixed already.