I am trying to generate a root file for my simulation, and I was not getting one generated. When I increased the verbosity for the G4AnalysisManager, I found that some sort of dummy root file was being created along with the root file I wanted to create. This dummy file would then be written and closed, and then immediately deleted. The root file I wanted to generate was never opened or closed. Also, whenever I generate a new event, a new dummy file would be created, for example, “Test2_t7.root.”
I am not sure where this is coming from, as I have tried to follow along example B4a’s root file construction and Physics Matters’ tutorial root file construction as close as possible. What could be the source of this error?
Here is my run.cc file where i generate the root file.
I added some data for the detector to collect, and it was able to save the test data, but it kept it in these dummy files, so for each run it makes a different file, for example, I have “Test2_t0.root”, “Test2_t1.root”, “Test2_t2.root”, etc. I want these all to be on the same file, so I still have the same problem as before with the generation of these files instead of “Test2.root”.
I saw this was used in the B4a example, so I included it right under the SetVerboseLevel line, and unlike the B4a example, I got this error message:
G4WT0 >
-------- WWWW ------- G4Exception-START -------- WWWW -------
*** G4Exception : Analysis_W001
issued by : G4RootNtupleFileManager::SetNtupleMergingMode
Merging ntuples requires G4AnalysisManager instance on master.
Setting was ignored.
*** This is just a warning message. ***
-------- WWWW -------- G4Exception-END --------- WWWW -------
I do not know how to remedy this new error. What else do I need to include in order to get the merge setting to work? I am still new to Geant4 so I may be missing something that is stated in the documentation.
hm. I also have it in the constructor of the user run action, and not so much else there…
do you issue the setUserAction command also for the master in the action initialization?
as in the example B4a? That should instantiate the analysis manager also for the master if I understand it correctly…
the “dummy” files are the ntuple storage files for each of the worker threads. since you seem to make runs with a single event for testing, there is only one worker active. Hence the “_tn” suffix, where n is the index of the worker the task was (randomly?) assigned to. you should see the files for all n workers when you have at least n events in the run.
It worked! Thank you for the explanation of the ntuple storage files as well. The index may not have been random, but I do not and would not know an explanation for the order of indexing on those worker threads.
The worker threads are indexed from 0 to N-1, depending on the value you set via /run/numberOfThreads N (the default in G4 is “all available cores”, so beware if you’re on an HPC cluster!).
If you run just a single event, the event will usually be dispatched to worker 0, but it’s possible on a multi-core machine that one of the other workers happens to get to the “ready for an event” state first. It’s effectively random, since it depends on the state of the whole node.
