showing event in time


A new feature of 2.x is the "insh anim" that permits to show an event happening in time.

With neard, fard, fgd setups, the default event files have timing info for the MCTrack, WCDetectorPoint and FgdDetectorPoint event model classes. When having an event, from the main menu, activate the "insh anim" menu item. It leads to a panel as the below (here for the first event of the neard setup):

neard_anim_event_0.png

The two first input items show the event time min and max, in nsecs, got from MCTrack/t and [WC,Fgd]DetectorPoint/time fields of the current event. You can change these values. The third input "sys delay (sec)" permits to enter the elapsed time (in secs) that you want that the animation lasts. The fourth input "end->begin" permits, if true, to repeat the animation at end. If you click "Ok", you pass in scene mode and the animation starts.

In general the events in the default files contain muon decays and the animation shows two bursts of hits ([WC,Fgd]DetectorPoints in green in the default setups). As each burst lasts around 50 nsecs max, but the muon decay is of the order of microsecs, for an anim of 10 user elapsed secs, each burst happens rather quickly. If you want to appreciate the evolution of one burst you have to tune the first two inputs. For example setting the second "event time max (nsec)" to 50 nsecs and setting the third "sys delay (sec)" to 20 or 30 seconds permit to see the nice deployement of the cherenkov rings of the first burst.

If you turn a bit the camera and zoom, you can arrange to focus on the red MCTrack points. By launching again the anim, you will see first the evolution of the MCTrack points in a bunch of nsecs, and then the green points happening behind a little bit later. If you arrange the event time min to be 50 nsecs before the time max, you will see the evolution of the second MCTracks and DetectorPoints in the second burst.

With the fgd setup, you can see also the evolution of FgdDetectorPoints.

The anim.insh contains what is done during an animation. For example for the fgd setup, it is:

    mc_cut_time="(${insh_anim_time_begin}<=t)&&(t<${insh_anim_time_end})"
    event_vis MCTrack -cut=${mc_cut_time} -color=red
    point_cut_time="(${insh_anim_time_begin}<=time)&&(time<${insh_anim_time_end})"
    event_vis WCDetectorPoint -cut=${point_cut_time} -color=green
    event_vis FgdDetectorPoint -cut=${point_cut_time} -color=skyblue

As you can see, time is sliced and a slice is defined by the insh variables insh_anim_time_begin, and insh_anim_time_end. The animation is driven by a inlib::sg::insh_anim node deposited in the dynamic scene graph that executes the anim.insh periodically according the input "sys delay" and the "event time min/max". The insh_anim node deposits the interval of a slice in the two variables insh_anim_time_begin and insh_anim_time_end and source the anim.insh script. In your anim.insh script, then you use these variables in some event_vis commands to pass a "-cut" on the event model class you want to display in the animation.

NOTE: some events show a time max of... a lot of nsecs, for example 10e11 or 10e12 (then a lot of minutes!). With these, the two bursts of a muon decay happen very quickly and then no more things up the end, except some late points (we noticed that it is some sole electron or proton). Not so clear if this is physical, but for the moment we did not introduced some logic to not take into account these sole late hits, then on these event you will have to tune by hand an adequate time max. (Note that here the event_stats, event_print commands on the t or time fields can help to find the right time max).

WARNING, IMPORTANT, ACHTUNG, ATTENZIONE : in an anim.insh script, you must NOT do a scene_clear_dynamic. It would be as sawing the branch you are sitted on!

You can see videos in the gallery section.

You can have a demo video on YouTube here. (It is also deposited in the 2.0.0 release area on github).