General support for running masses, couplings and K factors that change event by event

[Juergen Reuter]

Taken over from gitlab issue #51:

The SM_tt_threshold-parameter M1S is used by whizard to compute the top mass at sqrts, which is used for example to perform the on-shell projection. However, the model is linked to whizard via C-Interfaces, so that the value of M1S set there is not saved inside Whizard.

A workaround has been implemented in ed9beb0d and 59e1878d.

A more generic solution would approach the problem also from the point of view of running masses and widths. So far, they are constant in Whizard, but the threshold approach (Issue #43 (closed) ) and multiple other applications make up a requirement for this feature. It could work in a similar way as alpha_s and the qcd_t object. However, this would require the switch from some masses and widths from model parameters to Whizard options.

BACN suggested to combine this with a more general container for runtime-dependent variables for different models in general.

[Juergen Reuter]

Milestone renamed

[Juergen Reuter]

For the qcd_t / alpha_s object should support sufficient handling of flavor-dependent runnung (4f/5f schemes), e.g. needed for POWHEG matching. More general handling of NLO running should be enabled.

[Juergen Reuter]

n_f might be part of the MD5 sum of the qcd_t object.

[Juergen Reuter]

Milestone renamed

[Juergen Reuter]

Mirrored back to Gitlab issue 51.