New BoundsChecker implementation

[davidorme]

Description

This PR replaces core.utilities.bounds_checker with a user-modifiable and extendable BoundsChecker class. This does add one more argument to some class signatures but we plan to reorganise signatures (#394).

The main advantages are that:

• It removes hard-coded bounds and allows users to modify them
• It can be simply extended to add bounds checking to new optional in e.g. PModelEnvironment

The implementation:

• Defines a Bounds dataclass used to define bounds for a particular variable.
• Defines a BoundChecker class with default bounds for core variables that acts like a library for bounds checking.
• The main use case is e.g. BoundsChecker().check("tc", np.array([10, 1000]), which will check that these alleged temperature data fall within the configured bounds.

Fixes #408

Type of change

• New feature (non-breaking change which adds functionality)
• Optimization (back-end change that speeds up the code)
• Bug fix (non-breaking change which fixes an issue)

Key checklist

• Make sure you've run the pre-commit checks: $ pre-commit run -a
• All tests pass: $ poetry run pytest

Further checks

• Code is commented, particularly in hard-to-understand areas
• Tests added that prove fix is effective or that feature works

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.50%. Comparing base (56ccf57) to head (41f308e).
Report is 47 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop     #409      +/-   ##
===========================================
+ Coverage    96.27%   96.50%   +0.22%     
===========================================
  Files           34       36       +2     
  Lines         2659     2748      +89     
===========================================
+ Hits          2560     2652      +92     
+ Misses          99       96       -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[MarionBWeinzierl]

This looks, in principle, good. I am just starting to wonder, if everything is made a class, won't there, at some point, be a significant runtime penalty? But maybe it's an outdated clichee (or was never true in the first place for sequential codes) that OOP makes things slower, runtime-wise.

[davidorme]

I worry about that a bit. This PR is a small class that is basically just used to apply some numpy functions to potentially large arrays. I doubt it is significantly slower than the original, if at all. I think there is a minor cost to accessing by attribute, but it's a relatively small number of attributes that are accessed once per variable in the whole of an analysis.

[MarionBWeinzierl]

I agree that this one instance will will not make a bit difference, it was more a general observation about the way the code develops.

[j-emberton]

What plan do you have for renaming these vars?

[davidorme]

Good question - I think once the API structural changes have been pushed through, then review the function signatures for variable name and synchronise them across the code base. So a polishing step once we've put it all back together.

[j-emberton]

Looks good