Hi all,
I am in examples/basic/B1 and running exampleB1 (after building). In geant4.10.04.p02 I can do:
./exampleB1
and then
/particle/select mu+
/particle/property/dump
and it shows me the properties of the mu+.
If I do the same (exactly the same) in geant4.10.07.p02 (with a consistent build), I get
Particle is not selected yet !! Command ignored.
Am I doing something wrong? What do I need to change in geant4.10.07.p02?
Many thanks.
Cheers,
–U.
Hi all,
apologies for coming back to my question (which is not about examples/basic/B1; I chose that only as a well-defined setup to replicate my question).
How do I view (or change) particle properties in the current GEANT4 production release (10.07.p02)?
Many thanks.
Cheers,
–U.
Hi Ursi
I’m not a particle category expert but when I do
in the latest version of Geant4 I get
/particle/select mu+
/particle/property/dump
--- G4ParticleDefinition ---
Particle Name : mu+
PDG particle code : -13 [PDG anti-particle code: 13]
Mass [GeV/c2] : 0.105658 Width : 2.99598e-19
Lifetime [nsec] : 2196.98
Charge [e]: 1
Spin : 1/2
Parity : 0
Charge conjugation : 0
Isospin : (I,Iz): (0/2 , 0/2 )
GParity : 0
MagneticMoment [MeV/T] : 2.80272e-13
Quark contents (d,u,s,c,b,t) : 0, 0, 0, 0, 0, 0
AntiQuark contents : 0, 0, 0, 0, 0, 0
Lepton number : -1 Baryon number : 0
Particle type : lepton [mu]
G4DecayTable: mu+
0: BR: 1 [Muon Decay] : e+ nu_e anti_nu_mu
I tried this with exampleB1.
So the question is, what is the problem with your application. Have you modified B1 at all? Is there something strange about geant4.10.07.p02? You say “with a consistent build”, but it might be worth trying again. Make sure you are not linking against any old copies of Geant4, etc., etc.
Good luck.
John
Hi John,
many thanks for your response! I don’t know what the issue with my executable should be. I see this behavior with completely unmodified files in a fresh build, both on macos and on RH linux. I describe what I do below.
I installed from scratch geant4.10.07.p02.tar (geant4.web.cern.ch) on two machines: (1) macos 10.15.7 and (2) Red Hat Enterprise Linux Server 7.9. In both cases I compiled minimally (w/o Qt or so) using
cmake -DCMAKE_INSTALL_PREFIX=../g4-install -DGEANT4_INSTALL_DATA=ON -DGEANT4_USE_OPENGL_X11=ON -DGEANT4_BUILD_MULTITHREADED=OFF -DCMAKE_BUILD_TYPE=Debug -DGEANT4_BUILD_CXXSTD=17 ../geant4.10.07.p02
followed by
make VERBOSE=1 -j9 > & make.log &
make install
Then
cd ../g4-install/bin
source geant4.csh
and
cd ../share/Geant4-10.7.2/examples/basic/B1/
mkdir _build && cd _build/
cmake ..
make -j8
./exampleB1
This dumps me into interactive mode (except on the linux machine, where I have to comment the call to /vis/open OGL 600x600-0+0 in vis.mac to avoid a fatal error), where I can do
/particle/select mu+
/particle/property/dump
I get
Particle is not selected yet !! Command ignored.
In the simplified builds on both architectures I get complaints from G4OpenGLXViewer, but I think the detector and the physicslist have been built. (The error message regarding the particle selection is the same in these simplified fresh builds as in my normal Qt5-based build where I have no errors from the viewer.) I also tried to use C++11 instead of C++17 (imposed by external constraints for my normal work), but this does not cure the issue.
Since I was at it, I also tried installing from scratch with geant4.10.06.p03.tar (Software Download Archive | geant4.web.cern.ch). With this release, I do NOT get the issue. I can select the particle and dump its properties.
From my perspective I can reproduce the issue I reported in June in fresh unmodified builds of geant4.10.07.p02 on two different architectures. The issue is not present in geant4.10.06.p03.
When you refer to the ‘latest version of Geant4’, are you building against the master branch or v11.0.0.beta?
Cheers,
–U.
Hi Urs
Your build procedure looks fine. Just as a check, find the date stamp on the executable:
ls -l exampleB1
I am building against the current master in the development repository. I will download geant4.10.07.p02 and try. Give me a little while to do that.
Out of curiosity, what are the warnings/errors with X11 viewers?
John
Hi John,
marwees>ls -l exampleB1
-rwxr-xr-x 1 ursl staff 578632 Aug 11 10:29 exampleB1
The warnings/errors with the viewers differ between macos and linux.
(1) macos: The initial error message is
/vis/viewer/create ! ! 600x600-0+0
G4OpenGLXViewer::G4OpenGLXViewer: unable to get a single buffer visual.
G4OpenGLXViewer::G4OpenGLXViewer: unable to get a double buffer visual.
G4OpenGLXViewer::G4OpenGLXViewer: unable to get required visuals.
G4OpenGLStoredX::CreateViewer: error flagged by negative view id in G4OpenGLStoredXViewer creation.
Destroying view and returning null pointer.
ERROR in G4VisManager::CreateViewer: null pointer during OpenGLStoredX viewer creation.
No action taken.
WARNING: No viewer created.
#
and then additional messages are triggered. I end up in
# Re-establish auto refreshing and verbosity:
/vis/viewer/set/autoRefresh true
ERROR: G4VisCommandsViewerSet::SetNewValue: no current viewer.
/vis/verbose warnings
Visualization verbosity changed to warnings (3)
#
# For file-based drivers, use this to create an empty detector view:
#/vis/viewer/flush
Idle>
(2) On RH Enterprise Linux Server 7.9 I get (when using the release vis.mac)
# Use this open statement to create an OpenGL view:
/vis/open OGL 600x600-0+0
/vis/sceneHandler/create OGL
/vis/viewer/create ! ! 600x600-0+0
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 149 (GLX)
Minor opcode of failed request: 3 (X_GLXCreateContext)
Value in failed request: 0x0
Serial number of failed request: 22
Current serial number in output stream: 23
(For my test above I had comment the viewer creation, as the above error is fatal.)
I should say that these errors do not affect me normally because my normal builds are with Qt5. I just tried to follow a minimal build path for the purpose of this discussion. Maybe these issues disappear completely when removing -DGEANT4_USE_OPENGL_X11=ON.
I’ll try to build from the master on my side.
Many thanks.
Cheers,
–U.
PS: I don’t know the XQuartz version I am running, and I am affected by the same issue that the display from the linux machine on my mbp shows an empty scene tree. But again, this is not an issue in real life.
Hi Urs
You are right. I get your
with geant4.10.07.p02. This is obviously a bug. Please report it to our bug report system and maybe we will get around to making a geant4.10.07.p03.
I’m guessing it’s OK in 11-beta.
John
Hi Urs
Re your X11 issues…
On MacOS, make sure you are linking a consistent set of X11 libraries. I have XQuartz 2.7.11 alone. Some installers - macport, brew, etc. - sometimes install their own version, and CMake has trouble sorting things out. Also, there have been issues reported with the latest version on XQuartz. I’m on an older MacBook Pro (MacOS 10.15.7) with XQuartz 2.7.11. Even so, I sometimes get problems when I build with X11 and Qt together. I suggest: revert to XQuartz 2.7.11 or stick with Qt alone.
On Linux Server 7.9: does this mean you are running remotely (on the server) and viewing locally? To make this work, the local X11 server has to have GLX activated.
But good you can work with Qt alone. Stick with that.
John
Hi John,
many thanks, in particular for the comments on the display subtleties.
This is problem 2413.
I am not sure. I tried this by (1) downloading 11-beta from here and building and by (2) building the master branch from source cloning from github. I see the same behavior as in geant4.10.07.p02.
Cheers,
–U.
Hi Urs
I think you a right. Looks like the problem was fixed. Here is a clip from the current source/particles/History:
- 24 June 2021
- Fixed retrieving selected particle in G4ParticlePropertyMessenger,
which was failing
so it did not make 11-beta.
Thanks for submitting the bug report. I can’t guarantee it will be thought urgent enough to make a new patch, but clearly it will be OK for the next release. And meantime, you can get on with your work,
Thanks again for bringing this to our attention.
John