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.
• Turn all Meteo models into "real" submodels #124 Would greatly increase the HydPy-Meteo models' usability.
• Allow coupling HydPy-PET-AMBAV-1.0 to HydPy-W #123 Should be finished in a few days anyhow.
• Support Python 3.12 and drop Python 3.8 #121 At most, a few hours of work.
• Bidirectional coupling of HydPy-W(ALRUS) and HydPy-Dam #120 Should be finished in a few days anyhow.
• [ ] Verification of control files #119 Belongs to the potentially huge topic verification.
• Improve HydPy-Evap-MORSIM or implement HydPy-Evap-AMBAV-1.0 #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).
• [ ] 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.
• Add plotting routines for submodels #115 Something that is missing in our implementation of the new submodel concept.
• [ ] 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.
• Extract a Penman-Monteith submodel from HydPy-L(ARSIM) #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...).
• 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...
• Factor out the runoff concentration process into new submodels #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.
• [ ] 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.
• 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...
• [ ] ...Extend the model-related consistency checks. Maybe, this belongs to the huge topic verification?
• ... Find ways to document possible main model-submodel combinations automatically.
• ...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)
• [ ] 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.
• Trimming WATS/STINZ #79 Nice to have, very little work.
• [ ] 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.
• Enable reading constant series #76 Needs discussions; belongs to the topic "simplified handling of meteorological input data".
• More flexibility when reading in time series. #75 The central part of the "simplified handling of meteorological input data" topic.
• [ ] 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.
• Error tolerance of HydPy-Dam #65 A better error estimate would increase the usability of HydPy-Dam a lot.
• [ ] 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.
• Read input time series in several time intervals #61 Nice to have, maybe easy to implement, but might need some discussions.
• [ ] 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.
• Improve NetCDF handling. #59 Partly connected to the "simplified handling of meteorological input data" topic.
• [ ] 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.
• 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.)
• [ ] 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 model arma_v1 based on IUH 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.
• Finish the implementation of GR4J and friends #134 (Feature/models/cngrxj #112 is on its way)
• Move HydPy-H-Branch to the HydPy-Exch model family #137 (child of the model name refactoring)
• Remove HydPy-L-Lake #138 (child of the model name refactoring)
• Move HydPy-L-Stream to another model family #139 (child of the model name refactoring)
• Channel profile submodels #140 This would increase the flexibility of many already implemented routing methods a lot.
• Merge ga_garto and ga_garto_submodel1 #141 Would be great to not introduce the submodel concept with an (unnecessary) exception.
• Improve the online documentation (case studies, tutorials, etc.)???
• Migrate to NumPy 2.0 #147 necessary
• Segmentation faults in curious Python consoles #148 If we do not find a good solution, we must at least mention this problem in the documentation.