A brief overview of activities thus far:

I was assigned with further development of Victoria's Event viewer application.
During October collaboration meeting software workshop I showed a possible visual extension to Event viewer using HepRApp, which adds detector geometry to
physics data representation.

I understood then that main priority would be to get Event viewer up and running in the control room during data acquisition.
I also understood that along with data acquisition, online reconstruction is being done, where spill by spill is being reconstructed while output ROOT file remains open, only to be closed once the run has ended.
For this purpose I found Victoria's Event viewer to be unsuitable because it was designed to work on the level of reconstructed ROOT files (which I refer to as "offline mode") rather that on the level of spill (which would be more suitable for "online mode")

I designed a new set of structures that should work on the level of spill, having primarily HepRApp visualization in mind, but that would mean most probably dropping further development of Victoria's event viewer. However, then I learned that some users would prefer to have Victoria's visualization as well.

Rather than developing two different projects under the same name I wanted to try and figure out how to bring these two approaches together. I have worked out a solution which I hope will make sense. The relationship of structures is somewhat complicated so I have attached a schematic that should illustrate it.

Figure explanation:

Central part of the code is EVExporter class which takes a spill as an argument. Spill can be passed from some code that opens a reconstructed ROOT file and iterates through spills (in this figure ROOTFileReader or Victoria's Event viewer), or it can come from the reconstruction chain (which I imagined works as shown in the figure).

EVExporter can then iterate through all events of the spill (useful for online mode) or go to a particular event in the spill (more useful for offline mode). It extracts all information of interest from a particular event and fills an EVEvent container.

EVEvent then can be passed for visualization to:
- Event viewer to be directly plotted
- EVHeprepExporter which will create a Heprep file that can be displayed in HepRApp
- an arbitrary file format readable by some other event display application (here iSpy suggested)

We can also have an option to create Heprep files in Victoria's event viewer (shown as a dotted red line) if someone thinks it would be useful.

This whole concept has been tested and works in principle but before doing any further development I wanted to run it by some more experienced people to get some feedback. I would be grateful for any comments and suggestions, especially in case I got something wrong.

I am sorry if this entry is too long but I tried to present the situation well.

Thank you,
Mihailo

Here's an update on the recent progress.

Online mode for Event viewer (intended to run in the control room) is nearing completion and I need to start thinking about how to implement and test it, so I would be grateful on any pointers to what would be the best way to do this.
I imagined (without any knowledge on how reconstruction actually works) that a simple way would be to instantiate EVExporter in reconstruction chain passing the last reconstructed spill as an argument.

Also, I still have some issues with the detector geometry. Previously when I used run 7441, reconstructed with MAUS 1.1.0, for tests, neither tracker track points (yellow) nor space points (orange) were aligned with tracker planes, which caused also straight tracks (red line) to lie outside the tracker (see images MICEEvent_7441_*).
Latest tests with run 7513, reconstructed with MAUS 1.2.0, show good alignment of track points with tracker planes (images MICEEvent_7513_*). However, space points and straight track still have what seems to have an offset in z.

To calculate space point and straight track coordinates in global detector coordinate system I performed geometry transformations based on information found in gdml files. I tried converting coordinates directly from tracker coordinate system to global one, but also tried first converting from tracker to solenoid, and then from solenoid to global coordinate system. Both approaches gave similar results (within few millimetres) and both have the observed shift in z.

I downloaded geometry for both runs 7441 and 7513 but there was no difference in detector coordinates.

Am I missing some additional transformation or is there another reason for this (like maybe tracker coordinate system has different origin in gdml and in analysis or something like that)? Or am I simply doing something wrong?

*Another update on geometry issue

In the meantime MAUS 1.3.0 was released so I tried using it to build Event viewer to see if it changes anything.

First difference I noticed had to do with straight track parameters.
For the same upstream tracker straight track, parameters acquired using maus v1.2.0 were x0 = 25.6, mx = -0.00805, y0 = -102, my = 0.0107, whereas using maus v1.3.0 were x0 = -0.00805, mx = 17.2, y0 = 0.0107, my = 12.1. It looks as if the gradient and constant term are permuted. Notice also that if this is corrected, only constant terms are different from v1.2.0 values.

Image Tracker0_maus_v1.2.0 shows straight track (red) plotted along with space points (orange) and track points (yellow). Here maus v1.2.0 parameters were used. Apart for z offset I mentioned in the previous post, space points and straight track are reasonably well aligned, I think.
However, on image Tracker0_Tracker2Global we can see that if we use parameters provided by maus v1.3.0, alignment is off (shifts coming from different constant terms I imagine).
Another possibility was that maybe these new parameters are defined in global coordinate system. Image Tracker0_Global shows what it looks like if we use track points coordinates to plot the track. Again, alignment of track and points does not look good.

In case I am not doing something obviously wrong, should I contact someone from the tracker team (and who would you suggest) regarding this matter? I could also wait for first runs reconstructed with maus v1.3.0 and see if that will make some difference.
Also, until this is resolved should I drop attempts to plot straight tracks and just plot tracker points in the first version of online Event viewer?
In that case the main goal would still be integration of Event viewer in online reconstruction, as I mentioned in the previous update.

The event viewer has been included and documented in MAUS since few releases.
Do not think other development on it has been requested so far.