Update Neyman threshold when changing runner_args

[hammannr]

For shape parameters such as the WIMP mass, we haven't implemented anything that would allow resetting its nominal value after initialization. However, this is done to obtain the poi_rate_multiplier for a given poi_expectation, which means that the poi_rate_multiplier values corresponding to a given threshold might be wrong in the end.
I did the following to fix this issue and prevent us from running into a similar issue in the future:

• Initialize a runner for each runner_arg in the NeymanConstructor. This takes a bit longer and may sometimes be overkill but it works.
• Introduce a derived boolean property for a parameter called static (see Dealing with static shape parameters #81 ), which is true if the parameter is
  • not fittable
  • neither a livetime nor rate (ptype)
  • has no blueice anchors
• If one tries to override the nominal value of a static parameter or call parameters with a value for it that is different to its nominal value, alea will throw an error.

[hammannr]

I think it would be really neat if the static flag would set itself though I found that this is not really practical for our simple examples and thus I went back to making it a hand-settable flag.

[github-actions]

Pull Request Test Coverage Report for Build 6689997230

• 14 of 16 (87.5%) changed or added relevant lines in 2 files are covered.
• 3 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-0.3%) to 91.468%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
alea/parameters.py	8	10	80.0%

Files with Coverage Reduction	New Missed Lines	%
alea/model.py	1	85.26%
alea/parameters.py	2	88.1%

Totals
Change from base Build 6652053859:	-0.3%
Covered Lines:	1340
Relevant Lines:	1465

---

💛 - Coveralls

[hammannr]

In principle one could also get around loading the runner explicitly by just obtaining the poi_expectation and poi_value from results[true_name], right? I didn't do that now because I wanted to change as little as possible but is there a reason why we should not do that @dachengx ?

[dachengx]

Is the nearby functionality different from simply using set_nominal_values? @hammannr

[hammannr]

I had to change it since otherwise the static parameters would complain if the nominal value were updated in this step

[hammannr]

So the outcome is the same. It only had to be changed to accommodate the static parameter functionality

[dachengx]

Then maybe set_nominal_values is not checked by pytest. Would you add a test to increase the coverage?

[hammannr]

Actually, now it's no longer in use so I would suggest to simply trash the function

[dachengx]

In principle one could also get around loading the runner explicitly by just obtaining the poi_expectation and poi_value from results[true_name], right? I didn't do that now because I wanted to change as little as possible but is there a reason why we should not do that @dachengx ?

Logically the thresholds json should be controlled by runner configuration yaml but not the files stored. But it is still beneficial to check the consistency between result and calculated rate multiplier?

Better put this in another PR, as an enhancement.

[hammannr]

For some reason, pre-commit complains about _uncertainty in parameters, which I didn't touch:

alea/parameters.py:78: error: Cannot determine type of "_uncertainty"  [has-type]
alea/parameters.py:79: error: Cannot determine type of "_uncertainty"  [has-type]
alea/parameters.py:81: error: Cannot determine type of "_uncertainty"  [has-type]

[dachengx]

For some reason, pre-commit complains about _uncertainty in parameters, which I didn't touch:

alea/parameters.py:78: error: Cannot determine type of "_uncertainty"  [has-type]
alea/parameters.py:79: error: Cannot determine type of "_uncertainty"  [has-type]
alea/parameters.py:81: error: Cannot determine type of "_uncertainty"  [has-type]

I will try to fix it.