Best way to compile and debug standalone Eve/track.C tutorial example

[matevz]

Hi Pietro,

TApplication/TRint::Run() runs the main root event loop: waiting for gui events, timers, file-descriptors and, in case of trint, on the command-line. You have to create your scene before calling it – simply call track() on the line before calling Run.

However, for what you want to do, you can also do it all with root.exe as the main application:
gdb root.exe
(gdb) run
(root) .L track.C+g
— control c or z to get back to gdb
(gdb) b track.C:line-number
(gdb) cont
(root) track()

I can actually tell you most about what happens in track.C and in Eve / GL … but I don’t know what part you’re interested in In principle, there are 3 stages:

1. initialization in track.C, set track parameters and points track passes through (measurement points);
2. call MakeTrack() – this will actually call the propagator that will propagate the track in the given magnetic field towards each path-mark and then fix the trajectory when reaching point of closest approach to each of them;
3. Drawing is done through the ROOT GL system, class TEveTrackGL knows how to convert data in TEveTrack to appropriate GL calls, based on attributes set in the track and track propagator.

Good luck!
Matevz

[PBR]

Excellent, thank you! This is exactly what I was looking for. I now have the debug session running on Eclipse, much easier to follow…

The part I am interested in, to begin, is the trajectory generation, which is still not very clear to me (disclaimer: I am new to particle physics). Is track.C meant to be an example of path reconstruction? what are the fixed/measured quantities? and what are we adjusting to obtain the final trajectory?

[matevz]

No, it’s not an example of path reconstruction … it shows how to setup visualization of tracks:

• specification of magnetic field
• setup of TEveTrackPropagator
• specifying track starting parameters, position and momentum
• specifying known points where the particle passed through – PathMarks.

Now, the track can come from simulation or from reconstruction and there are different types of path-marks allowing you to specify “events” on the particle trajectory.

Eve propagator steps from one path mark (or initial position) to the next like this:

• propagate particle from current position to the closest point of approach to the path-mark (using RungeKutta integration);
• store intermediate points in an array;
• calculate distance vector (delta) between the path-mark and calculated extrapolated position;
• add this delta to stored points along the path so that nothing is added to the first point, full delta to the last one, and proportional amount to intermediate points – this makes the calculated trajectory smooth and pass through the given path-mark.

This is the best one can do from visualization perspective, adding minimal assumptions into what has actually happened to the track and why (energy loss, decay, or just wrong starting parameters).

If there are no path-marks, the track is just propagated with given momentum … this is an imaginary / ideal trajectory for a particle that does not interact with matter (lose energy) or decay.

[PBR]

qpbr_tracks.C (4.8 KB)
Hi Matevz,

Thanks again for the information, it has been very helpful and I have made some progress, but now I need another nudge to proceed further. I am assuming this is the appropriate forum for these types of questions, but let me know if that is not the case.

First let me describe the context of what I am trying to achieve, and then tell you where I could use some immediate help.

The ultimate task for me is to create a naïve no-frills…

1. …simulation of a collision with 2 opposite primary beam particles, …
2. …that generate 4 secondary product particles.
3. Evaluate the hit points of the secondary particles on a cylindrical detector surface where tracks terminate and all energy is absorbed.
4. Visualize the cumulative energy levels absorbed at the surface with a spatial grid resolution of my choosing.
5. Create a side-by-side track simulation view and the energy distribution view
6. Animate both views with a time resolution of my choosing.
   That is in summary what I would like to achieve at the end of this exercise.

So far (please see attached macro), I have been able to create the geometry and instantiate the “beam” tracks which decay at the collision point. I have also instantiated 4 independent tracks, but in the immediate it is not clear to me how to:

• create the appropriate mother/daughter dependencies for the particles/tracks
• detect the surface endpoints
• extract time information and ensure secondary particle generation is consistent with time of collision

If I can have some tips on these points, I should then be able to move on to tackle 4. through 6. above next.

Thanks!
Pietro

[matevz]

Hi Pietro,

First, I should warn you that you are stretching Eve well beyond its intended purpose as it is not a simulation tool and does not handle energy loss and does not really handle intersections with arbitrary geometry volumes – for this you could use TGeo.

Now, you can trick TEvePropagator to do what you want … you set it MaxR MaxZ and the track will stop on that cylinder. You just get the last point from the track and you should be good to go.

There is no special daughter/mother relationship between tracks in eve … the pathmark type daughter creation simply tells eve propagator to subtract the momentum carried away by the daughter (this is meant for delta electrons, bremssthralung photons etc). But you can just assign “daughters” as eve children to their parent tracks and manually set the origin to the last point of the mother track. This will allow you to have a reasonable view in the side list-tree view and also to togglew RnrDaughters on/off for a given parent.

I’m not sure what you mean with time information for the secondary. You mean if time at which the seconday intersects the cylinder is within some trigger window? I forgot how exactly this is done but internally eve-track-propagator works with 4-vectors so it knows about the time on each point and I’m pretty sure this can be extracted somehow, I’d have to look.

Cheers,
Matevz

[PBR]

Hi Matevz,

Thanks for the comments, things are clearer regarding TEve and its relation to TGeo, and I have been able to make some progress, but I am at the point where need a few more nudges to move forward.

I have implemented your suggestions to detect the surface “hits” and utilized 4-vectors to include time values (completely arbitrary) for the generated tracks that will do for the purposes of trying to animate the scene). I have stored my “hits” in a tree object and, more or “less”, I have been able to implement points 3 through 5 (see Jan 17 message and current revised macro +qpbr_tracks.C (12.9 KB) ), that is the rendering of geometry and tracks, side-by-side with a 2D histogram for the distribution of the energy “hits” on the surface. I have parroted the tutorials/eve/calorimeters.C example to achieve this outcome, and I have more questions further below regarding refining the display of the elements, but in the immediate I could use some advice on how to implement the animation. As can be seen from running the macro, I have made 2 slots, the top slot renders the geometry and tracks, the one below has the histogram of the energy “hits” distribution. Ideally, I would like to start from a clean geometry with no tracks and clean histogram, and update the scenes by rendering the tracks and bars on the histogram as long as the time value associated to them is at or below the current time in the animation. Assuming a TTimer is what I need to use for this, how do I turn the rendering of the elements on and off (at least for the tracks)? Any recommendations on dealing with the histogram?

Regarding the refinements I alluded to before, as you can see by running the macro or in the picture below, the initial orientation and magnification of the objects in the two slots are not ideal:

and I need to manually intervene to obtain de-magnified isometric looking projections, such as below:

I have played with the Camera settings, as you can see in the macro, but no no avail. What steps do you take to implement this in the code?

Finally, in the upper slot of my “Composite Views” tab (see below)

I wanted to have an entire replica of the “GL” viewer tab I create in the early stages of my macro. Since I use a slotTop->ReplaceWindow(ev) command at line 284 of the macro to populate the scene, I lose the scene in “GL” and end up with an empty tab (see below). How do I make a full copy of the original viewer/scene and properly initialize the top slot in the “Composite Views” tab while retaining the same outcome for the “GL” tab?

Thanks!
Pietro

[PBR]

Hi @matevz,
An additional question to the above posting from earlier this week:
Given the end goal of having the animation of two side-by-side windows, the physical “detector” and the corresponding layout of the energy distribution of the “hits”, would an experienced ROOT user prefer the TEve route? like I set out to do here, or would they employ an alternative approach?

Thanks!
Pietro

[matevz]

Hi,

You want to do animation in sort of real time (as opposed to saving images and making a movie), I gather. Hmmh, you would need a way to set max-time for tracks … and store also the time information for each point, than use this in TEveTrackGL to render line just to that point. I sort of remember this has been done before … hmmh, let me look at the code … ah, nope, I did this in another framework, long time ago, sorry.

So, the best way forward would be to set for track a final path-mark (decay, probably) on the point where you want the particle to be at that time frame … and then re-propagate. I realize this is not ideal but the above option of storing time info and using it requires quite some development — would you like to try it on? I can try guiding you but it’s not going to be easy.

TTimer should work, you could also do

for (time t)
{
  // do what you need at this t, updade objects;
  gEve->Redraw3D();
  gSystem->ProcessEvents();
  gSystem->Sleep(10); // in milisec
}

To populate a view / tab with the same content you just call the same functions as are called there. I’m pretty sure you can also reorder tabs … see docs of TGTab in gui/gui.

For how to manipulate camera, take a look at class TGLAutoRotator, in graf3d/gl. If you want to reset camera after you load the scene, I think you just need true argument to FullRedraw()

  gEve->FullRedraw3D(kTRUE);
 // And this is how you can reset it after changing camera on some viewer
  gl_viewer->ResetCurrentCamera();
  gl_viewer->RequestDraw(TGLRnrCtx::kLODHigh);

I don’t understand your question about what people experienced with ROOT would expect / prefer. You see, I don’t really know for what purpose you are doing this

Cheers,
Matevz

[PBR]

Hi @matevz ,

Thanks for the alice_esd tip, as I digest the materials I hope you don’t mind if I keep this thread alive, by asking additional related, but separate, questions.

I have made some progress with my script qpbr_tracks.C (14.8 KB) and was able to implement the time “loop” we discussed earlier with a TPad window, e.g.,

in an “animated” fashion.

My current question is: is there a quick way to embed something like this TPad itself in a TEve tabbed window? Similar to what I have done for the other views/scenes in my script?

Thanks!
Pietro

[matevz]

Hi Pietro,

Yes, it’s possible, you just embed TCanvas in the eve window slot … look at tutorials/eve window_manager.C and histobrowser.C

Cheers,
Matevz

[PBR]

Hi @matevz,

Awesome!! Now I have run into a resulting issue after implementing it in the latest version qpbr_tracks.C (15.3 KB) of the macro.

While in the animation loop, the animation window (bottom right) looks zoomed in:

then it fully fits all the windows at the end of the loop, which is the outcome I ultimately want:

Question: how do I force it to render the window(s) with full fit during the loop?

Thanks!
Pietro

[matevz]

Hi Pietro!

Hmmh, I’m guessing a bit here … but as both eve and tcanvas are partially shown I’d assume the system window resize has not completed. You can let ROOT GUI handle outstanding events (including window resize messages from the windowing system) by calling gSystem->ProcessEvents().

Cheers,
Matevz

[PBR]

Perfect. Worked like a charm, thank you! -Pietro

[PBR]

Hi @matevz,

I have entered the final stretch but have some issues I have not been able to resolve on my own and need a little nudge.

I want to replicate the “animation effect” I achieved earlier for the TCanvas lego plot also for the top slot in my main window (the one supposed to show the tracks that hit the “calorimeter”). I have the corresponding track labels stored in a TTree and would like to add the tracks one by one in the correct temporal order to the scene (the scene labeled “Track-Hits”).

To extract the relevant tracks I have tried using the FindTrackByLabel method (see line line 410 of the qpbr_tracks.C (17.5 KB) macro), but even though the method is able to “see” the matches, it generates a “segmentation violation”. My first question is: am I missing anything in setting up the Viewer/Scenes/TEve Lists that is causing the error? Or using the method inappropriately in some other way?

The other question is the following. I have hacked the method and performed the matching manually (lines 412-416) and in this way I have been able to add the tracks I want to the scene. However the added tracks are not displayed during the animation loop, despite using gSystem->ProcessEvents(). Only when I hover with the mouse on top of the “Scenes” folder in the Eve Browser, do the tracks appear. Is there a way to make Eve display each added track as the animation loop executes?

Or is there another approach that achieves the same goal?

Thanks!
Pietro

[PBR]

PS: a little update…

I have added the following two lines for (my hope at least) displaying the chosen product track to my scene:

//_end FindTrack

     if(track){
        track->SetRnrSelf(kTRUE);
        cout<< "++ itrk="<<itrk<<endl;
        sb->AddElement(track);          // update scene top track plot
1.         sb->Changed();
2.         sb->Repaint(kTRUE);
        //gEve->GetScenes()->RepaintChangedScenes(kFALSE);
        //gEve->GetScenes()->RepaintAllScenes(kTRUE);
        //gSystem->ProcessEvents();
     }

And it partially works for my first track in the list (small blue track lower middle):

But unless I hover on the Browser list or click on the partially displayed tracks in the frame which forces a “ProcessSceneChanges”, I can’t seem to make it display the rest of the tracks in the list:

Any recommendations on the correct thought process, or proper sequence required to control these rendering behaviors?

Thanks.
Pietro

[matevz]

Hey,

Sorry, I’m in a bit of a mess here, probably the easiest way to go on is for me to actually run your code … and I propose we go step by step, one issue at a time

1. does your qpbr_tracks.C run as is … or I need some input data files
2. does it run with master
3. can you create a github repo so I can checkout and make you PRs
4. does it run in compiled mode, as in root.exe qpbr_tracks.C+ – this would help when running a debugger

Cheers,
Matevz

[PBR]

Hi @matevz,

No rush, I am not under a tight deadline.

I was originally given the following task:

but my end goal at this juncture is to develop a better general understanding and a more systematic methodology for using the package, so I can try doing these tasks independently or at least in a semi-autonomous way.

Having said that:

1. qpbr_tracks.C (17.7 KB) runs as is, no external files or input are required.
2. don’t have a working knowledge of the git system, but it runs with the same outcomes in both ROOT 6.22/02 (conda package) and in ROOT 6.22/07 (manual source build).
3. same as above, but I will look into it and provide you with the information as soon as I am done.
   4.yes it does. I have it on gdb - Eclipse/CDT running with the sources of the 6.22/07 manual build.

Thanks again!
Pietro

[PBR]

Quick update: here is the repository.

[matevz]

Hi Pietro,

Got the code and am able to run it (welcome to the world of git). You really shouldn’t be imposing ontological structure onto Eve representation of beams and particles … Eve is a drawing toolkit … so just decide what you want to show and and have it once in the hierarchy of the Event scene. Maybe like this:

1. Beam
   1.1 b1
   1.2 b2
2. Products
   2.1 p1
   2.2 …

Or just have a flat list of all the tracks. You also don’t need all those ProcessEvent calls everywhere … if you do need it, it would be in an animation loop (and even there one would be better of using TTimer which will allow the rest of ROOT event loop to run). Maybe what you really need is gEve->Redraw3D() – which will setup a timer to do redraw of all eve scenes once the control is passed back to the root event loop.

[ If you go looking into real collision simulation, or hard process simulation, or event generation (what happens “in the interaction point”, before outgoing particles enter the detector) – you will see that on that level proper (multi-)parent - daughter relationship is maintained … but it’s because all the intermediate products are also there and the theory used there always imposes such a structure through either theoretical or computational concepts that somehow boil down to 3-point and 4-point functions. Pythia is one of the most widely-use packages for this, if you want to google it. ]

You probably know of the TEveCalo3D (see calorimeters.C tutorial).

Now, I think you’ve done a lot in the direction your proto-supervisor asked you to do … maybe even went a bit too far He might not be aware of EVE and was thinking you will implement everything using the “traditional” root graphics. Maybe you can add an “Event Control” tab to the bottom right, where “Command” tab is now and put a “next event” button there and maybe some gui to control energy / theta spread.

He’s asking you to animate unfolding of the 3D detector barrel cylinder into a plane. So he wants you to think about a smooth coordinate transform between the 3D and 2D space. Interesting If you want to draw this in Eve, you could start by just drawing a bunch of lines (or use TEveStraightLineSet) or, if you are adventurous, develop your own Eve element – but this likely an overkill.

Now, don’t invest too much time into TEve and its details, it’s almost 15 years old and we are working on the next-generation web-gui based REve … along with all of ROOT GUI transitioning to web / javascript. This is probably true for any HEP computing technology – those of us who choose this path sooner or later stop doing physics (not saying this is good or bad in itself). You have been warned

After all this, and now that I have your code, what do you want me to look into? Just one or two things, please

Cheers,
Matevz

[PBR]

Hi Matevz,

ROOT is an evolving 25+ year old tool with many layers, it’s hard to see the forest for the trees sometimes. These are exactly the nudges I was looking for! Thanks.

I’ll digest the information and you will hear from me (or, not… ).

Have a great weekend! -Pietro