I have an application for which the UI and the OGL visualization stopped working when going from Geant4.10.05p01 to Geant4.10.06. No warnings, no messages, without visualization it runs fine and does what it is supposed to do (well, hopefully). Example B2a works fine, showing the GUI and the visualization.
I think I tracked it now down to the fact that in Geant4.10.06 the preprocessor macros G4UI_USE and G4VIS_USE are not set anymore. In my main()-program, all the calls to the visManager or the UImanager are protected by the mentioned preprocessor commands, as recommended in the G4 Book for Application Developers “Introduction to Visualization” (v.10.6). So neither visManager nor UImanager are invoked, the application runs, and exits. In fact, in the release notes to 4.10.6, it says under
- Items for migration of the user code
“The preprocessor macros G4UI_USE and G4VIS_USE are removed”
And in fact, example B2a does not use these macros (and therefore visualization works).
Now, to me, it seems there s a contradiction to what the “Book for Application Developers” suggests and what is actually implemented in Geant4.10.06. For me, the easiest would be to set the preprocessor variables somehow, but it is not clear to me how I can do this. I tried to pass them to the
cmake-command with the -D-flag, or set them as a environmental variable on the commandline, but that didn’t work (I use the -DG4UI_NONE=FALSE -DG4VIS_NONE=FALSE options with cmake, I don’t know if they did anything with 4.10.05, but in 4.10.06 cmake says
Manually-specified variables were not used by the project:
So how do I set these variables/macros?
Any help is welcome!
Sorry not got back to you. It looks like our documentation needs attention (but have not yet been able to check).
The reason we backed these flags out was to simplify things. There’s no harm in instantiating a vis manager apart from it occupying a bit of memory and, anyway, you can use it even in batch mode to generate an image with a file writing driver such as DAWNFILE, VRMLFILE or HepRepFile. Similarly the UIsession can be linked, but of course, must not be instantiated in batch mode.
I’m not sure I understand why you cannot simply remove the ‘#ifdef’s’ in your code.
Hope this helps.
removing all the #ifdef’s did the trick. I had that set up years ago, was happy that it was working and never wanted to look at that part again. But times change.
However you should revise your handbook, because as the setup of visualization is described now it will not work any more.
And this didn’t simplify things for me, it took me quite some time to figure out why the visualization wasn’t working any more.
Thank you @smuelller. By pointing this out you saved me a lot of time.
Has this been filed as a bug report for the documentation?
Yes, a correction has been submitted. It will be incorporated into the documentation soon.
Thanks for bringing this to our attention.
G4VIS_USE is also mentioned in a message I get in the output log:
Visualization Manager instantiating with verbosity “all (6)”…
Visualization Manager initialising…
You have instantiated your own Visualization Manager, inheriting
G4VisManager and implementing RegisterGraphicsSystems(), in which
you should, normally, instantiate drivers which do not need
external packages or libraries, and, optionally, drivers under
control of environment variables.
Also you should implement RegisterModelFactories().
See visualization/management/include/G4VisExecutive.hh/icc, for example.
In your main() you will have something like:
G4VisManager* visManager = new G4VisExecutive;
visManager -> SetVerboseLevel (Verbose);
visManager -> Initialize ();
(Don’t forget to delete visManager;)
This message should probably also removed/adjusted.
Absolutely. Thanks so much for catching these anomalies. I have submitted a correction for the next release.