Event Viewer Development
Mihailo is interested in hearing what people would like to see from the event viewer, and in canvasing opinions on a few ideas he has of what direction to take it in.
Updated by Savic, Mihailo almost 6 years ago
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.
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.
Updated by Savic, Mihailo almost 6 years ago
- File MICEEvent_7441_0_0.png MICEEvent_7441_0_0.png added
- File MICEEvent_7441_0_0_zoomed.png MICEEvent_7441_0_0_zoomed.png added
- File MICEEvent_7513_33_0.png MICEEvent_7513_33_0.png added
- File MiceEvent_7513_33_0_zoomed.png MiceEvent_7513_33_0_zoomed.png added
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?
Updated by Savic, Mihailo almost 6 years ago
- File Tracker0_maus_v1.2.0.png Tracker0_maus_v1.2.0.png added
- File Tracker0_Tracker2Global.png Tracker0_Tracker2Global.png added
- File Tracker0_Global.png Tracker0_Global.png added
*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.
Updated by Dobbs, Adam almost 6 years ago
Sorry for the slow reply to this. First up I think your code schema from the first update is excellent, it looks like a good versatile system for the event viewer. I suggest making the input modules to the EVExporter inherit from a common base class, to make it easily extensible, and the same for subsequent exporters to the particular viewers themselves. I suspect we won't need the optional link from the old event viewer to the HepRep viewer (dotted red line). Possibly it would be good to add a director class too, which would coordinate pulling in the data from a ROOT file, or online or wherever, passing it to evexporter, passing the evevent to the particular event viewer interface, etc etc.
As for integrating with online, Chris Rogers can comment further, but believe the thing to do would be to wrap the code in a MAUS reducer, which would receive the spill, pass it to EVExporter, then call one of the event viewers as desired.
The tracker geometry issues are worrying, but still very much being worked on by the tracker group. I have added a few other tracker group people as watchers, who may be able to comment further. One thing I would suggest trying is using the new SciFiSpacePoint::get_global_position() method (part of release 1.3.0), and see if that helps.
I am very concerned about the straight track parameters seeming to have changed between 1.2.0 and 1.3.0. I will investigate this and let you know.
I the meantime I suggest leaving plotting track fits for now, and concentrate more on getting a stable spacepoint / trackpoint viewer into MAUS and ready to deploy to the control room.
Again, this is excellent progress Mihailo, thank you.