In a restRoot -m 1 session, I run REST_Geant4_ViewGeometry("box.gdml") to visualise the geometry.
Everything works fine, I get the output output1.txt (1.3 KB)
But, in the same restRoot session, if I want to run this REST_Geant4_ViewGeometry command again, I get an error: output2.txt (2.7 KB)
I would say it is something that I don’t get concerning the way to use restRoot or even Root.
But the problem is more annoying than that: now, I’m trying to create my own geometry file, based on the box.gdml template, let’s say Mybox.gdml. And when I try to visualise the geometry in a new restRoot session, sometimes I get the error in output2.txt, even at first launch of the REST_Geant4_ViewGeometry command.
I don’t understand this error. I tried to look at the file
Thank you if you have an idea of what is happening.
If necessary, I could post Mybox.gdml.
I’m using
Root 6.24/06 (and Geant4 11.0.3) in a Conda environment.
REST v2.3.15
Linux Debian
The last output of git log in $REST_PATH: GitLog.txt (352 Bytes)
Ok, I can reproduce the problem with the box.rml example.
The problem is that the second time when the macro tries to create an instance using geo->GetMasterVolume(), the returned value is a null pointer (a non-valid memory address), and thus the line geo->GetMasterVolume()->Draw(); crashes.
I added a PR just to avoid reaching the seg.fault and output a more human error message.
If you got an account on GitHub you might approve yourself.
====
However, if you try your new geometry in a fresh ROOT session it should work. Perhaps there is something missing in the geometry file. Could you share your geometry files?
So I confirm: the first time I launch REST_Geant4_ViewGeometry("MyGeometry.gdml") in a restRoot -m 1 session, I get the output2.txt
I run the REST_Geant4_ViewGeometry("MyGeometry.gdml") command a second time in the same restRoot session, and this time it works.
I also attached the full process here, I may have missed something. error.txt (5.1 KB)
Thanks for the advice for materials.xml. I’ll do that.
I wanted to use ROOT 6.26/10, but for whatever reason, Conda is not happy to contain Root 6.24/06 and Geant4 11.0.3 in the same environment. I may force it and see if it solves my problem. I will update about the result here.
Concerning the second crash with box.gdml:
[Let’s imagine this is solved on your side] if I want to work on the geometry file, can I just modify the box.gdml and run REST_Geant4_ViewGeometry("box.gdml") in the same restRoot session several times?
You may also try to use the instalROOT.sh script at
I think that in order to fix it we need to redesign that macro. Because I believe the problem is that we are re-using the pointer names for different objects. Thus, ROOT gets confused because it stores the keys in memory, but this I am not sure 100%.
It is true that it would be nice that the geometry would be updated as one modifies the file, perhaps @obis knows about.
But I usually work the calculations in the file then check that the geometry is what I expected, so I just relaunch the restRoot session again.
I don’t use the macro, just these lines that can be recovered from previous session with top-arrow.
TRestGDMLParser *g1 = new TRestGDMLParser();
TGeoManager *geo1 = g->GetGeoManager("box.gdml")
geo1->GetTopVolume()->Draw()
If you wish to draw a modified box.gdml file in the same session you could recover the previous commands taking care to replace the pointer names by new ones.
TRestGDMLParser *g2 = new TRestGDMLParser();
TGeoManager *geo2 = g->GetGeoManager("box.gdml")
geo2->GetTopVolume()->Draw()
Concerning the REST_Geant4_ViewGeometry macro: I may have found something.
It turns out that when I run this macro in Root, I have in the output: TRestGDMLParser: Creating temporary file at: "Mypath/.rest/gdml/PID58614_MyGeometry.gdml" for example.
I listed what is in this directory, and it turns out that it was full of previous PID<number>_<filename>.gdml created since I’m working on this geometry.
I erased everything, and now I don’t get the error anymore.
Could it be related to that?
That’s a temporary file that it is actually the final one that is given to the ROOT TGeoManager::Import method. The one we use in REST is translated to that temporary file, replacing env variables, or including a remote materials file, for example.
Thus, this file, the one at .rest/gdml/PID58614_MyGeometry.gdml can be open without REST libraries, just doing:
Concerning the fact that the REST_Geant4_ViewGeometry macro crashes even at first try, some update: I have now a Conda environment with Root 6.26/10 (and Geant4 11.0.3).
I still have the same problem. Sometimes, I would have this crash (always with the same error message), and sometimes not, with no modification of the .gdml file between the 2 attempts.