Allow tuning parameters to be modified after detector construction

[spradlin]

          ### Special place of tuning parameter macros

Despite my complaints in the previous comment, the addition of a dedicated command line argument for the tuning parameter macro is an improvement over the hard-coded filename for tuning parameters in WCSim/develop. It allows different collections of tuning parameters to be maintained and used.

However, i do not yet understand why they need special treatment. Why are they not executed from a top-level job macro, such as WCSim.mac?

First!

According to a comment in include/WCSimTuningParameters.hh, the WCSimTuningParameters class contains

  // The parameters that need to be set before WCSimDetectorConstruction
  // is created

Before the creation of the WCSimDetectorConstruction object. The usage in WCSim.cc reflects this statement:

    45    WCSimTuningParameters* tuningpars = new WCSimTuningParameters();
    :
    54    // Get the tuning parameters
    55    //hack B.Q
    56    G4cout << "B.Q: Read argv[2], which should contains the tuning parameters" << G4endl;
    57    G4String fileName2 = argv[2];
    58    file_exists(fileName2);
    59    if(fileName2 == "vis.mac"){
    60      G4cout << "ERROR: Execute without arg for interactive mode" << G4endl;
    61      //return -1;
    62    }
    63    G4String command2 = "/control/execute ";
    64    UI->ApplyCommand(command2+fileName2);
    :
    71    // UserInitialization classes (mandatory)
    72    enum DetConfiguration {wfm=1,fwm=2};
    73    G4int WCSimConfiguration = fwm;
    74
    75    WCSimDetectorConstruction* WCSimdetector = new
    76      WCSimDetectorConstruction(WCSimConfiguration,tuningpars);

Why are these parameters required at creation? The whole detector geometry can be revised and redefined after the creation of WCSimDetectorConstruction. Why are these parameters special?

WCSimDetectorConstruction usage of WCSimTuningParameters

What does the WCSimDetectorConstruction constructor do with its pointer to a WCSimTuningParameters?

• L41: It makes a copy of the pointer that is stored as the data member WCSimDetectorConstruction::WCSimTuningParams. This is good. It means that post-construction changes to the tuning parameters can be accessed, in principle.

The copied pointer WCSimDetectorConstruction::WCSimTuningParams has a corresponding accessor WCSimDetectorConstruction::GetParameters().

In the constructor, there are no direct calls to the original parameter, the copied pointer, nor the accessor to the copied pointer. If the final values for the WCSimTuningParameters are needed by the constructor, it must be indirectly.

All uses of the tuning parameters by WCSimDetectorConstruction appear to go through the WCSimDetectorConstruction::WCSimTuningParams copy of the pointer. Performing a grep for WCSimTuningParams finds the following instances

# grep WCSimTuningParams src/*.cc
src/WCSimConstructCylinder.cc:  const G4bool WCTopVeto = (WCSimTuningParams->GetTopVeto());
src/WCSimConstructCylinder.cc:  G4double WCTVPMTSpacing = (WCSimTuningParams->GetTVSpacing())*cm;
src/WCSimConstructMaterials.cc:  double WCODWLSCladdingReflectivity = WCSimTuningParams->GetWCODWLSCladdingReflectivity();
src/WCSimConstructMaterials.cc:    ABWFF = WCSimTuningParams->GetAbwff();
src/WCSimConstructMaterials.cc:   RAYFF = WCSimTuningParams->GetRayff();
src/WCSimConstructMaterials.cc:   G4double MIEFF = WCSimTuningParams->GetMieff();
src/WCSimConstructMaterials.cc:   BSRFF = WCSimTuningParams->GetBsrff();
src/WCSimConstructMaterials.cc:   RGCFF = WCSimTuningParams->GetRgcff();   //defaults in mac: 0.32 and flat
src/WCSimConstructMaterials.cc:  double WCODTyvekReflectivity = WCSimTuningParams->GetWCODTyvekReflectivity();
src/WCSimDetectorConstruction.cc:  WCSimTuningParams(WCSimTuningPars),
src/WCSimPMTQE.cc:  QEFF = WCSimTuningParams->GetQeff();   //defaults in mac: 1.

in addition to its ubiquitous usage in the WCSimTuningMessenger class. There appears to be exactly one call to the accessor, and that is from the WCSimWCDigitizerSKI::DigitizeHits() method. This function should be called by the run manager for each event---not needed in the construction of any objects.

Aside: with regards to WCSimWCDigitizerSKI::DigitizeHits() getting a digitizer saturation parameter through the detector object WCSimDetectorConstruction: Why? Why?

Both of the uses of the WCSimDetectorConstruction::WCSimTuningParams pointer in src/WCSimConstructCylinder.cc, L714 and L884, are called in the WCSimDetectorConstruction::ConstructCylinder() function. This function, in turn, i called in only one place in WCSimDetectorConstruction::Construct(). And in turn, this function seems to be called only by WCSimDetectorConstruction::UpdateGeometry(). And this is only called by the void WCSimDetectorMessenger::SetNewValue() macro message processor when the /WCSim/Construct macro command is invoked.

Aside: This trace seems incomplete. I know that the SuperK detector geometry is always constructed, and then, if the detector configuration is changed, then it is replaced by the desired geometry. I do not see that initial construction of the SuperK geometry in this trace.

Back to the uses of WCSimDetectorConstruction::WCSimTuningParams, the instances in src/WCSimConstructMaterials.cc are all in the function WCSimDetectorConstruction::ConstructMaterials(). This is called by the WCSimDetectorConstruction::WCSimDetectorConstruction() constructor.

Okay, this is why the tuning parameters need to be processed before the WCSimDetectorConstruction::WCSimDetectorConstruction() construtor is invoked. It is because the constructor defines the G4 materials table and there is no facility to update the materials after the constructor is invoked. I think that can be fixed.

Originally posted by @spradlin in https://github.com/spradlin/WCSim/issues/20#issuecomment-1403722009