With the recent release of Geant4 11.4.0, I noted the removal of the HepRepFile visualization driver. I fully appreciate the collaboration’s decision to streamline the toolkit, especially given that the HepRApp browser has been unmaintained and its original hosting at SLAC is no longer available.
However, I would like to open a discussion on a potential path forward for those who still rely on this workflow and explore if the collaboration would be open to restoring the driver in a future 11.4.x patch or subsequent releases.
Despite its age, the HepRep format offers specific advantages that remain highly relevant to the community:
Unique Feature Set: Features like the point-to-point 3D distance measurement tool in HepRApp are vital for geometry debugging and are not currently available in the Qt or OpenGL-based drivers.
Environment Flexibility: Because HepRApp does not require OpenGL, it is often the most reliable way to visualize geometry in “headless” environments, remote servers, or Docker containers where hardware acceleration is difficult to configure.
Offline Analysis: It remains one of the most robust ways to save simulation states for later inspection without re-running the application.
The primary barriers to using HepRApp (its dependency on Java 1.8 and the loss of its web home) have been resolved through containerization. I have developed and documented a solution that ensures HepRApp remains accessible on all major operating systems:
Given that the browser can now be easily run via a container, would the collaboration consider reverting the removal of the HepRepFile driver?
If maintaining the driver code within the main source tree is a concern, perhaps it could be kept in a “deprecated” or “unsupported” status for one more major release cycle. This would give the community time to either fully transition or help maintain the driver as an optional component.
I would be very interested to hear your thoughts or to learn if there are plans to incorporate features like the 3D ruler into the newer visualization drivers.
Thank you for your time and for the incredible work on Geant4 11.4.
In short, no, it won’t be reverted. We have been discussing solutions for longer term deprecation and removal of drivers (and features more generally) here: 30th Geant4 Collaboration Meeting (20-24 October 2025): Integration/Deprecation of features in the Geant4 Toolkit · Indico. The code for the driver is of course available in older releases and people are welcome to take it as-is and use/support it. Equally, if there are sufficient people willing to take on maintenance, development and support, and sufficient community interest then we could discuss hosting it under the Geant4 GitHub org as described in that link.
Note also that HepRApp itself is no longer maintained and there was a call here: Installing and/or running HepRApp - #7 by jiperl five years ago which as far as I know no one took up (I’m happy to be corrected!). Containerisation helps of course, but if there’s no actual work going on to update or maintain the code itself I’m not sure that’s a long term sustainable solution (in terms of why the driver should be provided in the toolkit itself).
thanks a lot for the context. Lean code base is great for both developers and users.
Is there any replacement of the distance measurement function provided in HepRApp in other vis drivers, or any plan to develop that?
Are you aware of any effort of trying OpenGL based visualization using containerized Geant4?
Could you recommend other vis drivers that offer something similar to that HepRApp offers (offline interactive geometry debugging)?
Finally, I’d like to emphasize that containerized HepRApp solves completely the problem mentioned in Installing and/or running HepRApp - #7 by jiperl. It brings the browser back to any modern OS without worrying about mixed java versions. The image should be usable for many years from now (a long-enough-term solution).
In your main program, add #include "G4HepRepFile.hh"
and after instantiating the vis manager, but before initialising it, add visManager->RegisterGraphicsSystem(new G4HepRepFile);
Now you should be able to /vis/open HepRepFile. (See /vis/list to see all registered drivers.)
your post reminds me a third possible solution, that is, to provide a CMake option to toggle the compilation of HepRepFile driver and default it to OFF. This way, it won’t increase the compilation time for people who don’t know about it. The file size is not a problem in any modern server or laptop (and the source code is in the git history anyway).
The point of not doing that is Presence implies support. If you go through past posts on HepRep/HepRApp, most (and there aren’t actually that many overall) are “how do I run HepRApp”.
As noted above, we (that is, Geant4) can’t really do much about this without presumably taking on responsibility for maintaining HepRApp. We could link to other efforts, but experience shows these can be fragile over the long term, and thus we’re back to square one again. This is the point about what might be termed the “modularisation/extension” discussion I linked to above - bringing together community efforts where there is sufficiently broad interest, but there are good technical/support/licensing reasons to not include the code in the Geant4 toolkit directly.
I agree on everything you said in your presentation and posts.
What if I monitor all questions on the forum about HepRepFile and HepRApp (you can also direct them to me)? There aren’t many anyway My YouTube tutorial about the HepRApp container should answer most the questions.
Searching “heprep” and “heprapp” in the forum reveals that most resulting questions are not actually about HepRepFile or HepRApp. They simply contains these strings in quoted Geant4 output messages. If we default the CMake switch to OFF, Geant4 output won’t contain those strings anymore. I don’t think we will get a lot of questions containing these strings in the future, and I can focus on questions really about HepRApp.
In short, I cannot take on the responsibility of maintaining HepRApp, but I can take on the responsibility of answering questions about HepRApp. The Geant4 collaboration doesn’t have to do it.
A modern alternative might be to use our VTK driver. You can export to ParaView. I’ve never done this myself, but I believe ParaView is highly endowed with features.
