You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Model names in HydPy 6.0 #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...
[ ] 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.
Support using GARTO as a submodel of HydPy-L #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...
[ ] HydPy-L-Land: improve variable names. #57 Partly done by factoring out evapotranspiration. Most of the rest will automatically happen when factoring out snow processes.
HydPy-Dam: evaporation and withdrawal. #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.)
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.
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.
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
andHydPy-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.HydPy-Meteo
models' usability.[ ] Verification of control files #119 Belongs to the potentially huge topic verification.HydPy-AET-Evap-AMBAV-1.0
. Also, we do not plan to improve HydPy-Evap-MORSIM "hydrologically" (but maybe "technically", see below).[ ] How to maintain (the latest) HydPy releases? #117 Requires only a few decisions and little documentation updates.[ ] Segfault due to inconsistent initialisation and simulation periods #116 Belongs to the potentially huge topic verification.[ ] netcdf files with 'UTC' in time unit throw error #114 Would require little work, but we still need to decide whether we want to support this violation of the NetCDF-CF standard.[ ] LSTM in HydPy? #113 No need to include LSTMs in HydPy 6.0, in my opinion.PY
...).[ ] We have no ideas for more descriptive names fordam_v001
todam_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.[ ] Add control directory name automatically to condition directory name #97 Still under discussion.[ ] Adding a hook mechanism #94 Would be nice to have, but there is no need to implement it soon.[ ] Emit more precise warnings when executing control files. #93 Not of central importance, in my opinion (and maybe hard to solve).[ ] directory in XML support #92 Nice to have and little effort.[ ] ...Extend the model-related consistency checks. Maybe, this belongs to the huge topic verification?[ ] Standardise using keyword arguments for setting parameter values. #86 Maybe not so crucial for HydPy 6.0.[ ] Timestamp in written conditions #83 Also a nice feature, likely with little implementation effort.[ ] Evap: Slight inconsistency between possible sunshine duration and extraterrestrial radiation #82 Not so urgent, in my opinion.[ ] Setting 1-dimensional SeasonalParameter by setattr #78 Likely also little work.[ ] Hbranch: xpoints have to be arranged strictly monotonous #77 Might need discussion, but it seems like little implementation effort.[ ] Extend HydPy's XML support. #73 Little work, nice to have.[ ] Additional mask-related functionalities #72 A special topic that is possibly not too urgent.[ ] How to generalise specifying spatial information? #66 A too big issue for HydPy 6.0, in my opinion.[ ] Time-dependecy of u and d of TranslationDiffusionEquation in CalibSpecs #64 Nice to have, likely little effort.[ ] Conv-model should show a matrix with the ratio of influence of stations #63 An excellent idea, but not very urgent.[ ] Faster simulation runs when handling time-series on disk. #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.[ ] Control and condition file compatibility. #58 An essential feature, in my opinion, but likely too much implementation effort to be considered for HydPy 6.0.[ ] HydPy-L-Land: improve variable names. #57 Partly done by factoring out evapotranspiration. Most of the rest will automatically happen when factoring out snow processes.[ ] Configurable initial condition default values. #56 Only a vague idea so far.[ ] Top-level verification methods. #55 The central part of the huge verification topic.[ ] Selection-specific metadata. #54 Important feature that requires some thought and work.[ ] Selection-specific (default) parameter values. #53 Needs discussion.[ ] Aggregated control and condition files. #49 No real need to start this before releasing HydPy 6.0.[ ] Save project settings. #47 Needs discussion.[ ] HydPy-L-Land: snow depth. #46 Needs discussion.[ ] Flexible default value configuration. #45 Not that urgent, in my opinion.[ ] String representations of parameters based on "keyword options". #44 I started implementing related features (still not mentioned in the issue) and will continue when encountering the next relevant use case.[ ] Geo-referencing. #43 Important feature but likely too much effort for HydPy 6.0.[ ] How-to page. #42 Not strongly related to a specific HydPy release.[ ] Simplify adjusting the test settings. #40 Not crucial for users, so we can postpone it to a later release.[ ] Explain how to calibrate modelarma_v1
based onIUH
subclasses. #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.[ ] Prepare the time series of input sequences only when necessary #38 This would significantly increase usability but requires some discussion.[ ] XML documentation annotations #34 Nice to have, but not that urgent, in my opinion.[ ] convenient funtion to copy new selection as new project #27 This is Gordon's last open issue. Closing it would be sad.ga_garto
andga_garto_submodel1
#141 Would be great to not introduce the submodel concept with an (unnecessary) exception.The text was updated successfully, but these errors were encountered: