Conda geant4 installation and OGL visualization

I’m having a problem with conda-installed geant4 versions and visualization. Note that recompiling G4 is not an option here; I have to able to tell my collaborators something like “type conda install geant4” since they’re not going to re-compile G4 on their laptops.

A few years ago, I created a conda environment with commands like the following:

 conda config --add channels conda-forge
 conda config --set channel_priority strict
 conda create -y --name myenv compilers cmake root geant4 hepmc3 cfitsio healpix_cxx

This set up a conda environment that I could tell my fellow collaborators on my experiment to use. The relevant stats are:

Geant4 Version: 11.0.3
Operating System: AlmaLinux 9.3
Compiler/Version: gcc 13.3.0
CMake Version: 3.27.5

This worked well enough at the time. I could run OpenGL visualization in my application. The relevant visualization commands in the macro file are:

/vis/open OGL 600x600-0+0
/vis/viewer/set/autoRefresh false
/vis/viewer/zoom .4

So far so good, as far as visualization was concerned. I could see that OGL was supported:

Registered graphics systems are:
  ASCIITree (ATree)
  DAWNFILE (DAWNFILE)
  G4HepRepFile (HepRepFile)
  RayTracer (RayTracer)
  VRML2FILE (VRML2FILE)
  gMocrenFile (gMocrenFile)
  OpenGLImmediateQt (OGLIQt, OGLI)
  OpenGLStoredQt (OGLSQt, OGL, OGLS)
  OpenGLImmediateX (OGLIX, OGLIQt_FALLBACK)
  OpenGLStoredX (OGLSX, OGLSQt_FALLBACK)
  RayTracerX (RayTracerX)
  Qt3D (Qt3D)

That was then; this is now. Geant4 has improved considerably since then. I’d like to use a later version. The latest available on conda is 11.3.2. So I issued a similar conda create command, most recently last week:

conda create -y --name newg4 compilers cmake root geant4 hepmc3 cfitsio healpix_cxx

The relevant stats are:

Geant4 Version: 11.3.2
Operating System: AlmaLinux 9,3
Compiler/Version: gcc 13.3.0
CMake Version: 4.0.3

The recompiled application still works (better than before; thanks G4 team!), except for the visualization. The macro lines are unchanged from above, OGL is still supported in the updated conda version:

Registered graphics systems are:
  ASCIITree (ATree)
  DAWNFILE (DAWNFILE)
  G4HepRepFile (HepRepFile)
  RayTracer (RayTracer)
  VRML2FILE (VRML2FILE)
  gMocrenFile (gMocrenFile)
  TOOLSSG_OFFSCREEN (TSG_OFFSCREEN, TSG_FILE)
  OpenGLImmediateQt (OGLIQt, OGLI)
  OpenGLStoredQt (OGLSQt, OGL, OGLS)
  OpenGLImmediateX (OGLIX, OGLIQt_FALLBACK)
  OpenGLStoredX (OGLSX, OGLSQt_FALLBACK)
  RayTracerX (RayTracerX)
  Qt3D (Qt3D)
  TOOLSSG_X11_GLES (TSG_X11_GLES, TSGX11, TSG_QT_GLES_FALLBACK)
  TOOLSSG_X11_ZB (TSG_X11_ZB, TSGX11ZB)
  TOOLSSG_QT_GLES (TSG_QT_GLES, TSGQt, TSG)
  TOOLSSG_QT_ZB (TSG_QT_ZB, TSGQtZB)

As I said, visualization no longer works. Instead I get the error:

qt.glx: qglx_findConfig: Failed to finding matching FBConfig for QSurfaceFormat(version 2.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 0, redBufferSize 1, greenBufferSize 1, blueBufferSize 1, alphaBufferSize -1, stencilBufferSize 0, samples -1, swapBehavior QSurfaceFormat::SingleBuffer, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::NoProfile)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig for QSurfaceFormat(version 2.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 0, redBufferSize 1, greenBufferSize 1, blueBufferSize 1, alphaBufferSize -1, stencilBufferSize 0, samples -1, swapBehavior QSurfaceFormat::SingleBuffer, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::NoProfile)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig for QSurfaceFormat(version 2.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 0, redBufferSize 1, greenBufferSize 1, blueBufferSize 1, alphaBufferSize -1, stencilBufferSize 0, samples -1, swapBehavior QSurfaceFormat::SingleBuffer, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::NoProfile)
Could not initialize GLX
Aborted (core dumped)

I did some web searches on that error message. qglx_findConfig: Failed to finding matching FBConfig. One page suggested that the following might improve things:

export QT_XCB_GL_INTEGRATION=none

It kept the application from crashing, but the detector view was just a blank screen.

At this point I should say that I’m running Geant4 on a remote AlmaLinux 9 server and viewing the visualization on my desktop Mac with XQuartz 2.8.5. As I said, with that configuration, the myenv conda environment worked just fine. It’s newg4 environment that has the problem.

I can install conda on my desktop Mac, and visualization works with the latest G4 version:

Geant4 Version: 11.3.2
Operating System: MacOS 15.5
Compiler/Version: clang 18.1.8
CMake Version: 4.0.3

The question becomes why does the latest conda version of Geant4 visualization over X11 not work for me when installed on AlmaLinux?

If it would help, I can post the results of

conda env export > environment.yml

for the various environments in question. It may simplify things to say that the original working myenv environment has some OpenGL graphics libraries:

  - mesa-dri-drivers-cos6-x86_64=11.0.7=4
  - mesa-dri1-drivers-cos6-x86_64=7.11=4
  - mesa-libgl-cos6-x86_64=11.0.7=4
  - mesa-libgl-devel-cos6-x86_64=11.0.7=4

The newer newg4 environment did not originally have any mesa libraries. I tried installing additional dri and mesa libraries, but that did not change anything:

  - mesa-dri-drivers-cos6-x86_64=11.0.7=4
  - mesa-dri1-drivers-cos6-x86_64=7.11=4
  - mesa-libgl-cos6-x86_64=11.0.7=4
  - mesa-libgl-devel-cos6-x86_64=11.0.7=4
  - mesalib=25.0.5=h79990ae_1

On the Mac, no MESA libraries were installedl… and yet it still works.

Any thoughts?

I’m still having this problem. Did I post this question in the wrong topic?

Hi Bill

When I saw your post, I guess I put this down to an installation issue - so not my expertise. I’ve never used Conda. Moreover, Conda apart, I have never successfully built a G4 app with graphics on a remote machine and communicated with a local machine over X11. In fact, never when the local machine is a Mac - just doesn’t seem to work. Mac OS’s seem to make this difficult, more so as time progresses.

However, I think others have succeeded. But whether your issue is to do with remote graphics via X11 or with the Conda installation, I do not know. One option would be to build the remote app conventionally.

My approach is to develop the app on my local machine, then, if needed, build the app without graphics on a remote high power server, or some such, for production, if required.

Sorry not to be more helpful. Hopefully, there will be someone out there with more relevant experience.

John

Thank you for the response. I appreciate it!

Unfortunately, rebuilding G4 is not an option. If it were just me, that would be fine. But I’m working with a collaboration with many institutions. If I expect them to use my application, I have to give them simple installation instructions for the dependencies like “type conda create -n g4 geant4 root python". Otherwise they simply won’t be inclined to use the application.

Not sure what the issue is either but for debugging purposes this seems like a clear case for testing your server/client paradigm with docker instances. That can at least create minimum test case using Alpine Linux and Mac on your machine to isolate possible underlying hardware driver conflicts since they will be using the same hardware. That will also allow you to remove a lot of possible confounding pathways with network traffic layers and remote displays.

This expands the scope of a debugging effort far beyond what I can handle now (I’m having problems with ROOT in the application that dwarf this visualization issue). Since the problem seems related to which G4 version I install using conda, I have to “toss the blame” (however unfairly) on the maintainers of the G4 package within the conda repository.

I’ll just suggest to the users that either run this application on their laptops, or set aside visualization if they’re running it on a remote server.