feat: New flux systematic tools and configurations

[luketpickering]

Pull request description

Adds 40 new flux parameters, split into focussing, alignment, and target condition and hadron production uncertainties.

Not yet used by any samples in this PR, but examples of usage are given and it has been tested and used on a feature branch.

See Systematics/Flux/README.md for more info.

Changes or fixes

Examples

[dbarrow257]

Generally LGTM - Just a pedantic comment about how the wildcards work in the SampleNames YAML.

Just some random thoughts on the optimisation - taking:
double w = flux_helper->GetFluxHadProdWeight( i, *par, dunemcSamples[iSample].flux_syst_nu_config[iEvent], dunemcSamples[iSample].flux_hadprod_syst_bin[iEvent]);
As the example, my understanding is that the hadprod_syst_bin is fixed per event because the function takes:
GetHadProdBin( duneobj->flux_syst_nu_config.back(), enu_GeV, syst_xpos_m))
Which I think doesn't depend on the MCMC step (assuming these are true values).

Other than the parameter value, the other inputs to the 'GetFluxHadProdWeight' function look to be fixed on a MCMC step-by-step basis. So, presumably you could store the value of 'hadprod.FDuncerts.at(param_id).at(nucfg)->GetBinContent(bin)' on an event by event basis (or even just in an array where each event knows its own index in that array). The benefit being you don't have to do

if (nucfg == kUnhandled) {
    return 1;
  }

  if (bin == kInvalidBin) {
    return 1;
  }

  if (nucfg < kFD_numu_numode) {
    int bin_oa = bin / 1000;
    int bin_e = bin % 1000;

For every event at every step

And then we can do the HadProdWeight = (1 + ParVal * StoredVal) as a functional parameter in MaCh3.

I think it's certainly fine to add as is, but we might want to think about any speed ups we can do given this could become critical to the beam systematic implementation in M3.

[dbarrow257]

Being a little pedantic, I think this wildcard would apply to atmospheric events in the case of a joint beam+atm fit?

[luketpickering]

Good point. I pushed against systematics declaring which samples they apply to (and stand by it), but was overruled. This orientation necessarily requires a forward declaration/naming convention (rather than strict linking between samples to systematics) whereby we agree to name samples <X>D_Beam_... or whatever, I guess.

[dbarrow257]

Do we want to store the validation plots on the repo?

[luketpickering]

Definitely don't have to. Can remove and squish the commits to a single merge commit.

[luketpickering]

Other than the parameter value, the other inputs to the 'GetFluxHadProdWeight' function look to be fixed on a MCMC step-by-step basis. So, presumably you could store the value of 'hadprod.FDuncerts.at(param_id).at(nucfg)->GetBinContent(bin)' on an event by event basis (or even just in an array where each event knows its own index in that array). The benefit being you don't have to do.

Good point, naturally to me it is aesthetically better to store the bin than the value. But you're completely right thats just a default position I took, if we're storing a number we should store the most processed number possible.

Agree with this improvement.