Visualization fails silently on macOS (Apple Silicon M4) - Runs in Batch Mode

[YG01110]

Description
I am testing Geant4.jl on a MacBook Air M4 (macOS Sequoia). I successfully instantiated the project and ran examples/basic/B1/B1.jl.

Expected Behavior
A visualization window (Qt/OpenGL) should appear showing the detector geometry after the physics initialization.

Actual Behavior
The simulation executes the physics steps correctly (logs attached below), indicating the kernel is functioning on aarch64. However, no visualization window appears. The process exits cleanly as if running in batch mode. No crash or specific Qt/GL error is printed to stdout.

System Info

• Architecture: Apple Silicon (M4) / aarch64-apple-darwin
• OS: macOS 15.x (Sequoia)
• Julia Version: 1.12.1
• Geant4.jl Version: Latest main (cloned G4Examples.jl)

Logs (Physics Verification)

Geant4 version Name: geant4-11-03-patch-02 [MT]   (25-April-2025)
                       Copyright : Geant4 Collaboration
                      References : NIM A 506 (2003), 250-303
                                 : IEEE-TNS 53 (2006), 270-278
                                 : NIM A 835 (2016), 186-225
                             WWW : [http://geant4.org/](http://geant4.org/)

Checking overlaps for volume Envelope:0 (G4Box) ... OK! 
Checking overlaps for volume Shape1:0 (G4Cons) ... OK! 
Checking overlaps for volume Shape2:0 (G4Trd) ... OK! 

... [Physics Lists Initialized] ...

*********************************************************************************************************
* G4Track Information:   Particle = gamma,   Track ID = 1,   Parent ID = 0
*********************************************************************************************************

Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
    0        0        0     -160        6        0        0        0       World initStep
    1        0        0     -150        6        0       10       10    Envelope Transportation
    2        0        0     -100        6        0       50       60      Shape1 Transportation
    3        0        0      -40        6        0       60      120    Envelope Transportation
    4        0        0       40        6        0       80      200      Shape2 Transportation
    5        0        0      100        6        0       60      260    Envelope Transportation
    6        0        0      120        0        0     19.7      280    Envelope conv

[YG01110]

Update: Potential Root Cause

I investigated whether the failure was a runtime configuration issue or a missing dependency. I performed a namespace check to verify if the G4VisManager symbol is actually present in the loaded Geant4 module.

Verification Command:

julia --project=. -e 'using Geant4; println("G4VisManager defined? ", isdefined(Geant4, :G4VisManager))'

Output

G4VisManager defined? false

[YG01110]

Historical Context & Path Forward

I dug into the repository history and noticed this limitation was briefly discussed in Issue #4 ("Native G4 vis") back in 2023. At the time, priority was correctly placed on stabilizing the simulation engine first.

Since the physics engine is now functioning correctly on Apple Silicon (as shown in the logs above), enabling the native visualization drivers seems to be the logical next step to close the loop.

Proposal:
I have been studying the Yggdrasil build system and would be very interested in tackling this implementation (patching the build recipe to include Qt/OpenGL for macOS) as a primary objective for a GSoC 2026 proposal.

[peremato]

I did not enable the G4 visualization when I build the binaries. See https://github.com/JuliaPackaging/Yggdrasil/blob/master/G/Geant4/build_tarballs.jl
The idea was not to use the native G4 visualization. It would be complicated to provide binary packages for all dependencies (Qt/OpenGL). I know by experience that to provide installations of Qt is not trivial.
Alternatively, the strategy has been to use the Julia native visualization, in particular [GL]Makie. I have done some work on this and we can visualize detectors and trajectories. See for example, https://juliahep.github.io/Geant4.jl/dev/examples/B2aVis/ or something a bit for complicated: https://juliahep.github.io/Geant4.jl/dev/examples/TPCSim/

For the future, I think a better approach would be to use the G4 graphic reps but implement a new driver based on the Julia native package Makie. This could be a project that we could try out.

[YG01110]

Hi @peremato, thank you for the detailed explanation! That context regarding the complexity of packaging Qt/OpenGL binaries for aarch64 makes perfect sense.

I completely agree that a native Makie.jl driver might be the superior long-term solution. It would solve the Apple Silicon headless issue and align the visualization stack with the modern Julia ecosystem.

I would love to take on "Implementing a Julia-native Geant4 Visualization Driver using Makie" as my project proposal for GSoC 2026.

I will start by studying the B2aVis and TPCSim examples you linked. I'll leave this issue open for now as a reference for M4 users, or I can close it if you prefer to track the new driver elsewhere?

[YG01110]

Update: Feasibility Test (GLMakie on Apple Silicon)

Following the suggestion to explore a native Makie driver, I successfully patched the B2aVis.jl example to use GLMakie instead of CairoMakie on my M4 Apple Silicon machine.

Results:
The interactive visualization works perfectly (60FPS, fully rotatable) without any Qt dependencies. This confirms that a Makie-based driver is a viable and high-performance solution for aarch64 users who currently face the batch-mode fallback.

Screenshot on macOS Sequoia (M4):