Task list HydPy 6.0

[tyralla]

The current master branch contains many new features, and we think it is time to plan the release of HydPy 6.0. However, some require polishment beforehand, and there are also many ideas we have not started implementing yet. So, to bring order into the process, we try to list all possible features.

The first draft lists all currently open issues and a few related points which are not explicitly addressed. Given the number of open issues, we clearly must focus on the most relevant or urgent ones.

A tick in the box means "implemented"; a crossed-out entry means "postponed".

• ~[ ] Extract the snow modules of (at least) HydPy-L and HydPy-H into submodels. This would complete our submodularisation efforts to a great extent, but is likely too much effort to be included in HydPy 6.0.~
• [x] #124 Would greatly increase the HydPy-Meteo models' usability.
• [x] #123 Should be finished in a few days anyhow.
• [x] #121 At most, a few hours of work.
• [x] #120 Should be finished in a few days anyhow.
• ~[ ] #119 Belongs to the potentially huge topic verification.~
• [x] #118 We are happy with HydPy-PET-Evap-AMBAV-1.0 and currently do not plan to implement HydPy-AET-Evap-AMBAV-1.0. Also, we do not plan to improve HydPy-Evap-MORSIM "hydrologically" (but maybe "technically", see below).
• ~[ ] #117 Requires only a few decisions and little documentation updates.~
• ~[ ] #116 Belongs to the potentially huge topic verification.~
• [x] #115 Something that is missing in our implementation of the new submodel concept.
• ~[ ] #114 Would require little work, but we still need to decide whether we want to support this violation of the NetCDF-CF standard.~
• ~[ ] #113 No need to include LSTMs in HydPy 6.0, in my opinion.~
• [x] #111 HydPy-Evap-MORSIM is ready, and we currently do not plan to improve it "hydrologically" (see above). However, there is a short task list, of which we should at least consider the adjustment of some misleading variable names (PY...).
• [x] #99 It looks pretty favourable to change all model names in one step so that we do not need to bother about this topic in later HydPy releases. However, the subsequent entries point out some problematic cases...
• [x] #130
• ~[ ] We have no ideas for more descriptive names for dam_v001 to dam_v005. So, we now tend to condense these models into, at best, one model by factoring out their peculiarities into submodels. This would significantly improve maintainability and usability, but we are still unsure if such an approach would be successful.~
• ~[ ] #97 Still under discussion.~
• ~[ ] #94 Would be nice to have, but there is no need to implement it soon.~
• ~[ ] #93 Not of central importance, in my opinion (and maybe hard to solve).~
• ~[ ] #92 Nice to have and little effort.~
• [x] #91 Submodel modularisation is definitely the big new thing in HydPy 6.0. We have already achieved a lot, but a few more things could or should be done before releasing HydPy 6.0. I better split them into separate points...
• ~[ ] ...Extend the model-related consistency checks. Maybe, this belongs to the huge topic verification?~
• [x] ... Find ways to document possible main model-submodel combinations automatically.
• [x] ...Improve the related documentation sections.
• [ ] ...There are some unnecessary inconsistencies in the handling of "scalar" and "vectorial" submodels.
• [ ] ...There are still some limitations for working with multiple submodels of the same type handled by one main model (see this comment)
• ~[ ] #86 Maybe not so crucial for HydPy 6.0.~
• ~[ ] #83 Also a nice feature, likely with little implementation effort.~
• ~[ ] #82 Not so urgent, in my opinion.~
• [x] #79 Nice to have, very little work.
• ~[ ] #78 Likely also little work.~
• ~[ ] #77 Might need discussion, but it seems like little implementation effort.~
• [x] #76 Needs discussions; belongs to the topic "simplified handling of meteorological input data".
• [x] #75 The central part of the "simplified handling of meteorological input data" topic.
• ~[ ] #73 Little work, nice to have.~
• ~[ ] #72 A special topic that is possibly not too urgent.~
• ~[ ] #66 A too big issue for HydPy 6.0, in my opinion.~
• [x] #65 A better error estimate would increase the usability of HydPy-Dam a lot.
• ~[ ] #64 Nice to have, likely little effort.~
• ~[ ] #63 An excellent idea, but not very urgent.~
• [x] #61 Nice to have, maybe easy to implement, but might need some discussions.
• ~[ ] #60 There is a performance issue, but it is relevant only for special applications (e.g. data assimilation), so we can postpone this to HydPy 6.0, in my opinion.~
• [x] #59 Partly connected to the "simplified handling of meteorological input data" topic.
• ~[ ] #58 An essential feature, in my opinion, but likely too much implementation effort to be considered for HydPy 6.0.~
• ~[ ] #57 Partly done by factoring out evapotranspiration. Most of the rest will automatically happen when factoring out snow processes.~
• ~[ ] #56 Only a vague idea so far.~
• ~[ ] #55 The central part of the huge verification topic.~
• ~[ ] #54 Important feature that requires some thought and work.~
• ~[ ] #53 Needs discussion.~
• [x] #51 If I am not mistaken, HydPy-Dam cannot use HydPy-Evap instances as "real" submodels. (The withdrawal part is possibly less critical. We can add a corresponding submodel later without breaking backward compatibility.)
• ~[ ] #49 No real need to start this before releasing HydPy 6.0.~
• ~[ ] #47 Needs discussion.~
• ~[ ] #46 Needs discussion.~
• ~[ ] #45 Not that urgent, in my opinion.~
• ~[ ] #44 I started implementing related features (still not mentioned in the issue) and will continue when encountering the next relevant use case.~
• ~[ ] #43 Important feature but likely too much effort for HydPy 6.0.~
• ~[ ] #42 Not strongly related to a specific HydPy release.~
• ~[ ] #40 Not crucial for users, so we can postpone it to a later release.~
• ~[ ] #39 This is a special topic but important for those who configure ARMA-like routing models. Still, it is more a documentation than a release issue.~
• ~[ ] #38 This would significantly increase usability but requires some discussion.~
• ~[ ] #34 Nice to have, but not that urgent, in my opinion.~
• ~[ ] #27 This is Gordon's last open issue. Closing it would be sad.~
• [ ] #134 (#112 is on its way)
• [x] #137 (child of the model name refactoring)
• [x] #138 (child of the model name refactoring)
• [x] #139 (child of the model name refactoring)
• [x] #140 This would increase the flexibility of many already implemented routing methods a lot.
• [ ] #141 Would be great to not introduce the submodel concept with an (unnecessary) exception.
• [x] Improve the online documentation (case studies, tutorials, etc.)???
• [x] #147 necessary
• [x] #148 If we do not find a good solution, we must at least mention this problem in the documentation.

[tyralla]

We crossed out many tasks from our list to keep the focus on the new submodel concept and the related models. We will postpone the "huge verification topic" to a later HydPy release. However, we hope to make at least some progress in handling meteorological input time series.

[tyralla]

I added a few tasks that mainly deal with submodularisation and model renaming.

We also aim to improve some aspects of the online documentation soon but still need to clarify whether we consider this a release blocker. Hence, I ended the corresponding item with a question mark. Maybe we do not need to decide this now and can wait a while to see how things evolve.

[tyralla]

We agreed that HydPy 6.0 is now mature enough, and to postpone the (more important) remaining tasks to 6.1.