Write histograms in the middle of the run

Recording, Visualizing and Persisting Data
1

Dear G4 users,

I have a Multi Threading application in which I create and fill histograms and tuples that are then written to a root file at the end of the run.
I am working in geant4 version 10.5.p1 and the implementation is done using the RootAnalysisManager.

To this point everything is working fine.
The question I have is if it is possible to write the histograms to a file in the middle of the run (lets say every x events), in order to access them and monitor the progress of the simulation.
To my understanding, the file (only one open file is supported at a time) has to be opened at the beginning of the run and kept always open for the tuples to get filled, but if I don’t close the file then I cannot access it from ROOT to read it!

Am I missing something, or it is not possible!
In the latter case what is the proposed method to monitor the progress of the simulation?

Thanks in advance!

2

So far as I know, ROOT does not allow you access files unless they have already been successfully closed with TFile->Close(). For example, if you have a job that crashes, leaving the ROOT file in an intermediate state, it’s effectively unrecoverable.

3

Hello,

There is indeed a limitation of handling only one file by G4AnalysisManager and so it is not possible to monitot the progress as you want.
We plan to remove this limitation in the next Geant4 version, which is planned for this December.

Best regards,

4

Thank you both for your answers!
So is there any other way to monitor the simulation?
What troubles me is that everything is thread local, so I can print statistics for each thread, but I am not sure how to merge information in the middle of the run.
Creating a singleton information class that gets filled by each thread could be a solution?

5

Here’s a way I use (not sure my colleagues will approve)…

Write what you want to a file (don’t forget to protect it with a mutex). For example

static G4Mutex myMutex = G4MUTEX_INITIALIZER;
static std::ofstream myFile("myFile.csv");
static G4bool first = true;
G4MUTEXLOCK(&myMutex);
if (first) {
  first = false;
  myFile << '#,a description of the contents" << std::endl;
}
myFile
<< ',' << whatever
<< ',' << etc
<< std::endl;
G4MUTEXUNLOCK(&myMutex);

Then you can inspect myFile.csv during the run. For example, with less or awk.

I have an app that can histogram the contents and see a plot with gnuplot during the run.

Does this help?

John

6

We have similar code in our CDMS simulation framework, so we can write out both text-based and ROOT-based data files, neither of which are thread-frienldly. It definitely works, and with the text-based file I can use something as simple as tail to see how it’s doing, or more complicated gnuplot-like processing.

The mutexes are essential, but they also incur a performance hit. Starting and stopping the mutex itself takes some CPU time, and any other threads that hit the mutex just stop what they’re doing and wait. So you end up with marginally lower performance even for one thread, and possibly noticeably lower overall performance with many threads.

For configurations where our events take minutes each, this isn’t a big deal, but for e.g., gamma backgrounds with no detector-response modelling (hundreds of events per second), it’s significantly better for us to run parallel sequential jobs than to use MT.

7

Thank you for your replies!
I will have a look on this approach. Though it isn’t nice, is seems the only viable solution!