Hi, Maurik.  

It seems to me that there are the following issues to solve here:

1) EVIO memory mapping fails on clondaq5.  

Do we know why?  Have you or anyone else contacted Carl Timmer about this issue?  He is the appropriate go to person for all Java EVIO issues, and he is quite responsive when issues arise, in my experience.  If there is a per-process memory limit on this machine (maybe from a ulimit setting?), can this be increased so that the ~2.0 GB files are mappable?  Is copying data files to /work or /volatile where they are accessible from less-restricted nodes a viable work around?  Is running memory intensive GUI applications on the "daq" machine even something we should be doing?  (I don't know for sure.  It just strikes me as not a great idea to run a process on part of the DAQ system that potentially takes up 2+ GB of RAM.)

2) The SVT monitoring steering config you are trying to use is not working.  

Having no specific traceback information about this, it is difficult to say anything much.  Do you see a full error traceback printed to the console?  Most log messages that show up as WARNING or SEVERE should have a corresponding traceback message that is printed to the console.  I spoke with Omar who told me that the SVT steering configs are all working for him.  Perhaps you just need to pull the latest from trunk to get this working?

3) We should use a new JEVIO version that supports sequential reading.

I can work on getting this going but first I would like to tag what we have working right now by making an HPS Java release (planned for this evening).  Then I'd like to work from the 4.4.6-SNAPSHOT that Carl Timmer is developing on right now in the new CODA Maven repo (yay!).  Any/all changes for supporting sequential reading of EVIO files should go into the official JEVIO distribution.  It wasn't clear to me if you were working from an official JEVIO release jar downloaded from the CODA website or had hacked up JEVIO yourself, so perhaps you can clarify this for me.  

4) Only the last file in a run is readable with the EvioReader.

This was not mentioned in your email, but Omar reported this to me this morning.  But I have never seen this problem.  Apparently, only the last file in a run can be read into our framework.  Can someone confirm?  How can I reproduce this issue?

Anything else that is in urgent need of attention right now?


> On Apr 20, 2015, at 4:46 AM, Maurik Holtrop <[log in to unmask]> wrote:
> Hello Jeremy,
> We have a bit of a productivity killer in the following dilemma:  
> clondaq5 cannot run the monitoring app and read from a file. It dies on the "Map Failed", which I think is opening the EVIO file and memory mapping it. 
> clondaq5 is the only machine in the counting house that can directly "see" the /data/hps drive where all our data is stored.
> There is no other drive or space available to use (/volatile or /work) where we can copy a data file to be analyzed on another machine.
> The result is that it is nearly impossible to do a quick replay of a data file using the monitoring app.
> When you are in the counting house and need to quickly get something looked at, this is a real issue.
> From a quick look, It *appears* that the sequential read works. However, when trying the SVT timing in monitoring, I then get a new error: "Error setting up LCSim", after "adding coditions listener". 
> Result: I have no plots to show of all the really hard work that was done tonight to time in the SVT and get some tracks. This is a real shame!
> Best,
>    Maurik
> CONFIG: added EvioDetectorConditionsProcessor to job with detector 
> HPS-EngRun2015-Nominal-v0 Opening reader for file /data/hps/hps_004870.evio.0 ...
> Mon Apr 20 07:16:49 EDT 2015 MonitoringApplication log
> SEVERE: Map failed
> java.lang.RuntimeException: Map failed
>    at org.hps.record.evio.EvioFileSource.openReader(
>    at org.hps.record.evio.EvioFileSource.<init>(
>    at org.hps.record.composite.CompositeLoop.setCompositeLoopConfiguration(
>    at org.hps.record.composite.CompositeLoop.<init>(
>    at org.hps.monitoring.application.EventProcessing.setupLoop(
>    at org.hps.monitoring.application.EventProcessing.setup(
>    at org.hps.monitoring.application.MonitoringApplication.startSession(
>    at org.hps.monitoring.application.MonitoringApplication.actionPerformed(
>    at javax.swing.AbstractButton.fireActionPerformed(
>    at javax.swing.AbstractButton$Handler.actionPerformed(
>    at javax.swing.DefaultButtonModel.fireActionPerformed(
>    at javax.swing.DefaultButtonModel.setPressed(
>    at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(
>    at java.awt.Component.processMouseEvent(
>    at javax.swing.JComponent.processMouseEvent(
>    at java.awt.Component.processEvent(
>    at java.awt.Container.processEvent(
>    at java.awt.Component.dispatchEventImpl(
>    at java.awt.Container.dispatchEventImpl(
>    at java.awt.Component.dispatchEvent(
>    at java.awt.LightweightDispatcher.retargetMouseEvent(
>    at java.awt.LightweightDispatcher.processMouseEvent(
>    at java.awt.LightweightDispatcher.dispatchEvent(
>    at java.awt.Container.dispatchEventImpl(
>    at java.awt.Window.dispatchEventImpl(
>    at java.awt.Component.dispatchEvent(
>    at java.awt.EventQueue.dispatchEventImpl(
>    at java.awt.EventQueue.access$200(
>    at java.awt.EventQueue$

Use REPLY-ALL to reply to list

To unsubscribe from the HPS-SOFTWARE list, click the following link: