Formalize checking Pastas models and reporting results #658
dbrakenhoff
started this conversation in
Polls
Replies: 3 comments 1 reply
-
I think this is related to what I proposed here: #625 Should we discuss this idea in the Issue? I think we al want this right? |
Beta Was this translation helpful? Give feedback.
1 reply
-
Option 2 but perhaps with static methods (checks) that can be called also without initiating the CheckModel class. |
Beta Was this translation helpful? Give feedback.
0 replies
-
PR open: #829 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I want to create a more formal structure for checking Pastas models. These checks are performed to determine whether a model meets certain criteria, for example, to select models for further analysis.
Pastas already includes diagnostic checks in the stats module, but this new functionality should be more broad in its scope. This could include the results from these diagnostic checks in its results, but also custom user-defined functions that check some aspect of a time series model.
Now there are several options for implementing this functionality:
Option 1
Create a separate
CheckModel
class. This class can be instantiated empty, and subsequently checks can be added to this object.Or the checks can be provided to the class directly with a dictionary of check functions.
Applying these checks to any model:
This should return a DataFrame with results, including checks per row (some checks will output multiple rows, e.g. response t95 for each stressmodel in the model). These results should include pass/fail, the test statistic (e.g. R^2) and the threshold it is compared to.
Advantage is that the checks are kept separate from the model class, and can easily be applied to multiple models. The downside is maybe that this is slightly less intuitive (we have a lot of model related functionality stored under the model object (plots, stats, etc.) so it might be more logical to include this there as well).
Option 2
The second option is more similar to current functionality in Pastas, by adding checks submodule to the Model class. We can include some frequently performed checks by default that can be called directly from the checks submodule. But custom functions can also be applied given they follow some defined pattern (model as first argument, and returns DataFrame with a preferably formally defined structure).
Advantages of this approach are that it is maybe more intuitive for users, given how the rest of pastas is designed. The downside is that it is slightly more difficult to apply the same checks to multiple models, though the last example in the snippet above addresses that somewhat.
So which option do you prefer? And should this be a core functionality or is this a good candidate for a plugin or custom extension? Let met know!
4 votes ·
Beta Was this translation helpful? Give feedback.
All reactions