Multiple minimizations in one runtime

[nadrino]

As we are starting to use GUNDAM for oscillation fits, p-values generation need to be extended for performing Feldman-Cousin confidence levels.

For instance in 2D contours, we need to perform a minimization of the systematic parameters while considering a fixed set of oscillation parameters: \Delta m^2, \sin^2(2\theta).

This feature could be introduced by making the Minimizer class to run multiple minimizations in a loop. The conditions of each minimization should be set by the user in the config files (via a list), and the code needs to take care of storing the results.

[nadrino]

Here is a design proposal for performing a stage fit. The following config example would be put into the minimizerConfig:

minimizationSteps:
  - name: "Pre-minimization with SIMPLEX"
    isEnabled: true
    algorithm: "Simplex"
    maxIterations: 20000 # end algo after this amount regardless of EDM
    maxFcnCalls: 20000
    saveFitResults: false
    skipHesse: true

  - name: "Base minimizer"
    legacyConfig: true # will read parameters set at the same level as `minimizationSteps`
    skipFit: true # those parameter will kept for the next steps

  - name: "Fine minimization with MIGRAD"
    algorithm: "Migrad" # run MIGRAD

This generalises the fact that the minimizer can run multiple instances of MINUIT in a given fit. For the oscillation parameters, one could thing about defining an extra instance which would perform multiple fit on a given grid:

  - name: "Oscillation grid minimization"
    isEnabled: true
    algorithm: "Migrad" # run MIGRAD
    # example with 100 x 100 grid + 1
    gridValues:
      - name: "Null hypothesis"
        parameterValues:
          - name: "Delta m^{2}_{41} (eV^{2})"
            isFixed: true
            priorValue: 0
          - name: "sin^{2}(2#theta_{24})"
            isFixed: true
            priorValue: 0

      - name: "Alternative hypothesis"
        binning:
          binningDefinition:
            - { name: "Delta m^{2}_{41} (eV^{2})", nBins: 100, min: 1E-1, max: 1E2, logScale: true }
            - { name: "sin^{2}(2#theta_{24})", nBins: 100, min: 1E-2, max: 1, logScale: true }

Note: I need to think more about the requirements of Feldman-Cousins C.L. generation... (to be discussed during the next GUNDAM working session)

[ClarkMcGrew]

I realized I originally replied by email so I'm not sure it went through. Generically what we need is to

• Parse commandline and read configs
• Load the MC inputs
• Repeatably (i.e. "loop"):
  • Set/Fix/Unfix parameters
  • Fill a "toy" data histogram
  • Run a "fit"

There are probably other things we should/(will want to) allow inside the loop. I was toying with implementing the "loop" part by making some of the higher level operations available to scripts (it's simple with rootcling). I don't think yaml is the right tool though since it's a data language. We could make the loop an element of the yaml (similar to how we do formulas, but hand to ROOT::ProcessLine instead).

[ClarkMcGrew]

BTW: I never got around to filing an issue, but I'm as I start thinking about applying the MCMC in an actual analysis, I'm probably going to redo it to use a similar "sequencing" logic (i.e. provide higher level operations that can be accessed via "ProcessLine" and expose them to the yaml config with something like

     sequence: |
        "stepOne();
          stepTwo();
          for (int i=0; i<1E+100; ++i) AnotherStep();" 

[nadrino]

Thank you very much Clark, I guess I didn't catch the implied data-reload feature in there. Maybe such config should actually be placed within the fitterEngineConfig