Model checks

[Manangka]

In GitLab by @Huite on Jun 20, 2019, 18:05

After a short discussion with Martijn, we came up with a general checking "framework":

• Checks are enforced by the model containing the packages. A model can be initialized with checks={None, "eager", "defer"}. When None, no checks are done whatsoever. When eager, a check is done when attaching a package to a model. The model is checked once more when the model is being written, since the packages are not immutable and may have changed in the mean time. When defer, the model is checked only when writing.
• Every package contains a pkg_check method. This package check optionally accepts an ibound to check for alignment, whether there are no values set in inactive cells. This ibound might not be available for an eager check, but it will always be for a deferred check.
• "Global" checks are always initiated by the model, and the packages simply raise Errors.
• Some conceptual errors can be checked. For example, there may an isolated part of a model. This is not an issue as long as there is a head dependent boundary present in every part (so any incoming water can get out). scikit-image's morphology presents some very useful tools for these analyses. One way of checking the above is by labelling the areas, then going through the active package cells, and assigning "has_flux", "has_head" markers. A check is then a matter of doing a groupby label and making sure the count for has_head is > 1 for every group.

In general however, we can only spot conceptual errors after an initial (steady-state heads) run. We might be able to write a few functions to facilitate analysis of these outputs (e.g. plots of where the velocities are highest, distributions of velocities, etc.).

[Manangka]

In GitLab by @Huite on Jul 1, 2019, 11:14

I've made a start with these checks in a0f55e3f4717f3e626182e405d2db7106e147d61

I've tested them quickly with a model. Seems to be going okay.

TODO:

• [ ] add tests
• [ ] add geometry checks on stages and elevations, which raise warnings rather than errors

There's one part which I'm wondering about, whether to constrain input types. My feeling now is that we shouldn't, since it goes against Python's duck typing. The type hints (#65) should provide sufficient info. What's interesting is that you can, if you want to, directly provide (string) paths to the Packages. These will get written into the runfile without having to load the data. It's a bit risky, so it shouldn't be used in general, but I can think of cases where it's convenient. The package checks will fail on this now: you cannot compare a numpy array of type string with an integer to check if it's positive -- So maybe add an exception for specifically for strings?

Thinking a little further: we might use arrays of pathlib.Path instead. Currently, you'd have to do some figuring out how to set the paths properly, from the ultimate working directory. We could simplify this by resolving the relative paths. You'd have to introspect the arrays (check dtype = 'O' first), then check the first element, maybe. The benefit is that paths have to be provided as Pathlib.path, giving more specificity than just a basic string (which is a valid input for many parameters).

[Manangka]

In GitLab by @visr on Oct 28, 2019, 14:15

unassigned @visr