Dear All,
An input event(pythia) contains two back-to-back e+ and e- particles generated from pp collision. While visualizing the tracks/showers in OpenGl, I have noticed that in the final step(step 3 in the image) only one trajectory is visible even though in the inter-mediate (in step 2) level both of the showers are formed.
Can anyone please suggest what can be the possible reason for this?
Thanks in advance.
Tapasi
Well…It’s very unlikely to be a flaw in the visualisation system. But is it a possibility that the electron or positron simply escapes along the the axis or through some gaps in the detectors and materials?
What energy pp? p or anti-p?
Where is the interaction point? I don’t see the source on your images. In fact, I don’t see e+ nor e- tracks - have you suppressed charged tracks?
Not sure I understand your Step 1 2 and 3.
Hi,
Here is the Pythia event for the geant4 run
Event_no pdf 1_d 2_d px py pz mass
1 11 0 0 25.59431558 35.64574001 21.63881411 0.00051000
1 -11 0 0 -24.74875255 -34.15875325 -8.55927064 0.00051000
The images I sent earlier are the sequence in which I can see them on the screen but could not capture in a movie(having issues to install mpeg_encode). So, the 2nd step I created by changing px value of e- of the above event for illustration purpose only:
Event_no pdf 1_d 2_d px py pz mass
1 11 0 0 25.59431558 35.64574001 21.63881411 0.00051000
1 -11 0 0 -4.74875255 -34.15875325 -8.55927064 0.00051000
The error is most probably due to some issues in my coding(not able to figure out) but any flaw of the visualization system. Attached is a zoomed version of the images where two particles(in blue and red color) are visible. I can assure you that this is how I can see them formed.
Thank you
Hi Tapasi
I’ve been thinking about this. I think you may have hit the “display list limit”. Is there a message to this effect in your output?
********************* WARNING! **********************
*** Display list limit reached in OpenGL.**
*** Continuing drawing WITHOUT STORING. Scene only partially refreshable.**
*** Current limit: 50000 primitives. Change with "/vis/ogl/set/displayListLimit".**
*******************************************************
Increase the limit to, say, 1000000, or even 10x this if you have plenty of memory. (Perhaps we ought to increase the default value nowadays.)
/vis/ogl/set/displayListLimit 1000000
How this works is: the vis system draws all the trajectories, so you see the full event. But, if you are using OpenGL (OGLSX or equivalent) it only stores them in its internal graphics database (display lists) up to the limit. At the end of event or run, the vis system redraws the event to take account of depth information, transparency, etc., but it can only draw what’s in the display lists. Using display lists gives maximum graphics performance (rotation, zoom, etc.).
Another workaround is to use “immediate mode”, whereby it goes back into the G4 event to do the redrawing:
/vis/open OGLI
Another parameter can be tweaked with /vis/ogl/flushAt - see guidance help /vis/ogl/flushAt. OpenGL buffers its graphics primitives for performance.
Hope this helps
John
Hi John,
Thank you very much. I can see the following
Total energy deposition in this Event : 91.9681 (GeV)
********************* WARNING! ********************
* Display list limit reached in OpenGL.
* Continuing drawing WITHOUT STORING. Scene only partially refreshable.
* Current limit: 50000. Change with "/vis/ogl/set/displayListLimit".
***************************************************
I have been trying to solve this for many days… Will confirm the outcome after changing the limit.
Regards,
Tapasi
