Dear colleagues,
I am trying to use the TEve infrastructure to build a simple event viewer, used to display data from a FLUKA-based MC simulation. Specifically, for each track in FLUKA I was able to dump the complete list of steps. The attached file data.txt shows this for one specific event.
Since the FLUKA simulation already provides me all data regarding individual steps for the different tracks, I was trying to use these to draw the different tracks (TEveTrack objects), by adding different TEveTrackMarkD objects to these via the method TEveTrack::AddPathMark.
In other words, I’d like to steer the track propagater with the steps provided by FLUKA.
However, the tracks are not displayed properly when doing so - only the first step is displayed. I am wondering if this is an appropriate way to proceed. May I ask you for a guidance?
I attach below the data file, the gmdl file used to display the geometry, and finally the macro file (eve_test2.C) that I am using.
Thanks,
Bests,
Andrea
example116.gdml.txt (79.4 KB)
eve_test2.C (7.1 KB)
data.txt (96.6 KB)
ROOT Version: 6.26/04
Platform: AlmaLinux 9
Compiler: gcc 11.3.0
Maybe @matevz can take a look?
Hi Andrea,
In principle adding path-marks as you are already doing should do the trick. I’ll try running your code today and figuring out what is going on. There are options in TrackPropagator (and its GUI) to also draw the path-marks as points – anyway, will give it a go and then we see 
Oh, have you tried also supplying the momentum to the path-mark? I thought one needs both in case of kReference, but it’s been a while since I looked at that code. If you pass it 0 that would explain why the track stops there (though I’d expect some complaints from the propagator).
Cheers,
Matevz
1 Like
Hi Andrea,
Yes, I was right, surprisingly … the momentum of a kReference path mark is also used, not just the position:
https://github.com/root-project/root/blob/master/graf3d/eve/src/TEveTrack.cxx#L363
However, what happens at these points, is this coming directly from the stepper and can be ± anything? I assume this because there’s so many of them, some of them super close together.
What should I expect to be seeing? To the 0-th order this seems rather correct for the input (after I click the right arrow in your tab). If you open GUI for the tracklist (tab Eve/“Pythia Tracks”/ tab Refs) and check “Rnr Refs” (which stands for Render/Draw/Show kReferences) … there are quite a few that get drawn and I also expect a lot of them to overlap.
Other than adding momentum to the references, it might also make sense to reduce the number of pathmarks to only output them if, say, a volume boundary has been crossed or the distance from the previous point is larger than some epsilon, or accumulated energy loss is above some limit.
What I think happens, because of the 0 momentum, is that the path-marks are simply connected by line-segments … yup, seems to be written this way.
While looking at the code I noticed that the track-propagator has a maximum number of points it will allow on a track – it is rather large (4096) but it is also rather hard-coded, it seems.
Cheers,
Matevz
1 Like
Hi Matevz,
indeed these points come directly from the FLUKA stepper. I suppose that in some regions they’re very close in space since I have a fine-segmented detector, or because (in another region) there’s a magnetic field.
Concerning momentum, I can definitively add it, I’ll try and let you know.
I also agree that it would make sense to reduced the number of points by post-processing them.
Thanks,
Andrea
Hi Andrea,
OK, let us know how it goes. I’ll be a bit scattered / travelling for the next month so DM if I seem to be ignoring you
Cheers,
MatevĹľ
Dear Matevz,
the solution you proposed works - adding also the momentum to each path mark results to the track being displayed properly.
As “trick” to end the track drawing at the end vertex, I am seeting the last path mark as kDecay. In my simulation, indeed, the end vertex is either the decay point or the place where an interaction took place.
Thanks,
Bests,
Andrea