I ran the G4 example B1 with the Qt GUI and disabled the graphics with the commands /vis/disable and /tracking/storeTrajectory 0.
If I manually enter the command /run/beamOn 100000 five times all works fine: each run takes about 1.6 s of real time and the RAM usage is around 700 MB (stable over the runs).
If I execute the macro file with /control/execute macro.mac, the application executes the five runs but the simulations take more time as the runs are executed (the last one requires 13 s of real time) and there is a huge usage of RAM: more than 4 GB at the end of the execution of the fifth run, then the memory is freed up to 2 GB (instead of 700 MB).
If I execute the macro file in batch mode it is executed correctly and very fast (about 0.4 s for each run and without the huge usage of RAM).
Do you know what the problem is? Why the behaviour is different if the commands are executed by the macro file?
A curiosity: why does a run with the GUI opened but the graphics disabled still require much more time than the batch mode? (0.4s vs 1.6 s)
The Qt UI struggles if there is a lot of output. I’m guessing it could cope with one run of 100000 events, but not with the accumulation of 5 such runs.
Keep the output to a minimum for runs with large numbers of events. Also, disable visualisation: /vis/disable.
You are right, I tried setting the run verbosity to 0 (/run/verbose 0) and the speed is comparable to the batch mode without the memory issue (the visualization was already disabled).
I still don’t understand what is the difference, from the GUI point of view, between the execution of five separate runs and the execution of a macro file with five runs. Why isn’t run verbosity a big deal in the first case?
I think it is simply because the GUI could cope with one run but not with five. When you type a command into the session box control is not returned to the session box until the command is completed, i.e., until after one run (/run/beamOn 100000) or after 5 runs (/control/execute your-very-simple-macro-file.mac).
Meanwhile, the GUI is saving the output. I’m not sure why it cannot send it to the output box during the run (after all, trajectories are drawn during a run) but, either way, the GUI saves all output somewhere in memory. You can see that, because when it finally gets round to sending it to the output box, you may scroll back indefinitely. This simply uses a lot of memory, and when this gets out of hand it can cause severe slow down or even a crash. The GUI is not intended to cope with mountains of normal (G4cout) output.
There’s nothing to stop you defining your own output file stream so your output goes to file instead of main memory - but be careful to protect output from worker threads with a mutex lock. I’m not aware of any way of redirecting the output from, say, /run/verbose, which uses G4cout, to a file stream.
Incidentally, since 10.7 (I think), the output is anyway also sent to standard output into the terminal from which you launched your job. (The GUI often obscures this terminal window, but if you can bring it to the front during the run you will see output scrolling up the screen.) Terminals also save output, of course, but only up to some limit. You cannot scroll back indefinitely, so there is no memory problem for terminals.