This issue came up during adding the capillary rise to the available processes of HydPy-L-Land but addresses a more general problem. In the following, we restrict our discussion to control parameter files, but similar holds for initial condition files.

When we implement new processes into a base model like HydPy-L-Land, we tend to make them available in all derived application models, as long as this does not inevitably change the old functioning of the application models. For example, when we implemented the capillary rise for the new application model Version 3, we also added it to Version 1 and Version 2. However, both old application models can still calculate the same results as before if we set the parameter KapMax to zero, which disables the capillary rise completely.

The problem is that already existing control files do not set the value of KapMax to zero. Updating these control files comes with a certain amount of work, which depends on your scripting skills. The alternative is to activate the usedefaultvalue option. The default value of KapMax is zero, and we should always prefer such "neutral" default values when adding new processes to existing application models. However, permanently enabling the usedefaultvalue option is not recommended.

We see two ways for improvement.

First, we could implement a compatibility flag. If the user sets it, for example, to HydPy 3.1, all parameters added in HydPy 4.0 and later would always use their default value (except, the user explicitly specifies another value, of course).

Second, we could implement a general function for updating project data. In essence, this function would enable the usedefaultvalue option temporarily, read all control files, and then overwrite them with the new, complete set of control parameters. Implementing such a function would also allow us to solve more special compatibility problems, which most likely will come up at some point and with which we do not want to burden the user too much.