Rerunning simulation

Applications
1

If a Geant4 user application is to be bound using python, notebook etc… Rerunning a simulation within the same execution context is essential. So creating and the destroying the simulation with different settings. In my application (which I have written python bindings, not to be confused with generic geant4 python bindings) I notice I cannot the simulate in sequence. This can be recreated using exampleB1. So main_func is exactly the same as the exampleB1 main function and it is just called again. On the second call of main_func it fails with a segmentation fault.

#include "ActionInitialization.hh"
#include "DetectorConstruction.hh"
#include "QBBC.hh"

#include "G4RunManagerFactory.hh"
#include "G4SteppingVerbose.hh"
#include "G4UIExecutive.hh"
#include "G4UImanager.hh"
#include "G4VisExecutive.hh"
// #include "Randomize.hh"

using namespace B1;

//....oooOO0OOooo........oooOO0OOooo........oooOO0OOooo........oooOO0OOooo......

int main_func(int argc, char** argv)
{
  G4cout << "==============================================" << G4endl;
  G4cout << "==============================================" << G4endl;
  G4cout << "============================================== main_func " << G4endl;
  G4cout << "==============================================" << G4endl;
  G4cout << "==============================================" << G4endl;
  // Detect interactive mode (if no arguments) and define UI session
  //
  G4UIExecutive* ui = nullptr;
  if (argc == 1) {
    ui = new G4UIExecutive(argc, argv);
  }

  // Optionally: choose a different Random engine...
  // G4Random::setTheEngine(new CLHEP::MTwistEngine);

  // use G4SteppingVerboseWithUnits
  G4int precision = 4;
  G4SteppingVerbose::UseBestUnit(precision);

  // Construct the default run manager
  //
  auto runManager = G4RunManagerFactory::CreateRunManager(G4RunManagerType::Default);

  // Set mandatory initialization classes
  //
  // Detector construction
  runManager->SetUserInitialization(new DetectorConstruction());

  // Physics list
  auto physicsList = new QBBC;
  physicsList->SetVerboseLevel(1);
  runManager->SetUserInitialization(physicsList);

  // User action initialization
  runManager->SetUserInitialization(new ActionInitialization());

  // Initialize visualization with the default graphics system
  auto visManager = new G4VisExecutive(argc, argv);
  // Constructors can also take optional arguments:
  // - a graphics system of choice, eg. "OGL"
  // - and a verbosity argument - see /vis/verbose guidance.
  // auto visManager = new G4VisExecutive(argc, argv, "OGL", "Quiet");
  //  auto visManager = new G4VisExecutive("Quiet");
  visManager->Initialize();

  // Get the pointer to the User Interface manager
  auto UImanager = G4UImanager::GetUIpointer();

  // Process macro or start UI session
  //
  if (!ui) {
    // batch mode
    G4String command = "/control/execute ";
    G4String fileName = argv[1];
    UImanager->ApplyCommand(command + fileName);
  }
  else {
    // interactive mode
    UImanager->ApplyCommand("/control/execute init_vis.mac");
    ui->SessionStart();
    delete ui;
  }

  // Job termination
  // Free the store: user actions, physics_list and detector_description are
  // owned and deleted by the run manager, so they should not be deleted
  // in the main() program !

  delete visManager;
  delete runManager;

  return 0;
}

int main(int argc, char** argv) {
  main_func(argc, argv);

  main_func(argc, argv);

  return 0;
}

//....oooOO0OOooo........oooOO0OOooo........oooOO0OOooo........oooOO0OOooo.....

Thanks very much for any help/advice. Stewart

2

This is unfortunately something of a limit imposed by the current implementations of state such as the UI manager and materials tables. There’s a Issue tracking this on the internal GitLab, so is on the radar.

3

A workaround is to run each iteration in a different process, everything orchestrated by a single session in the notebook.