Starting with issue #90, we introduced a new submodel concept for improving the modularisation level of the models implemented in HydPy. The first concrete realisation is the GARTO submodel, which can be added to HydPy-L (and, in the future, to other main models as well) to simulate the effects of infiltration excess on runoff generation. This realisation of the submodel concept works, but we still need to work out many details to improve its usability. However, before doing so, we prefer to start another realisation to gain more experience on possible use cases.

The second possible use case is a potential evapotranspiration interface. So far, our only effort to factor out evapotranspiration was to implement evap_v001(which we now name evap_fao). evap_fao calculates the FAO grass reference evapotranspiration, and main models like lland_v2 and wland_v001 can take this data as input. However, evap_fao is not really a submodel but is implemented as a stand-alone model which must be connected to other models via the input/output node mechanism. This mechanism (currently) limits us to the exchange of scalar potential evapotranspiration values and requires more configuration effort than desired.

The reason for selecting potential evapotranspiration (pet) as the second use case is that we currently try to extract the Turc-Wendling equation implemented in lland_v1 into the new model evap_tw (or evap_turcwendling?) and the “norm-temperature” approach implemented in all application models of base model hland into the new model evap_hbv (or something like evap_normed or evap_climate?). However, we cannot do so based on the input/output node mechanism. Both approaches do not calculate one scalar pet value per subbasin but individual values for different hydrological response units. We consider this an important feature when working with large subbasins, especially in mountainous regions with steep gradients of temperature and other meteorological factors. (Accordingly, evap_fao currently would not be a good choice in such situations.)

So, this opens the question if we should turn evap_fao into a submodel and design evap_tw and evap_hvb right from the start as submodels. If we decide so, this would likely mean we eliminate the input/output node mechanism sooner or later, which is still marked as an experimental feature in the documentation. The submodel concept has the potential to become superior in most (or all?) regards, and handling two modularisation strategies in parallel seems like an unnecessary effort. Going this way, we would also need to turn all meteo models into submodels.

What would we need to do?

• Increase the dimensionality of the already available parameter and sequence classes of evap from zero to one and adjust all equations accordingly.
• Decide if we still need evap_fao as a stand-alone model. This is not required for usual HydPy projects (where we model the complete water balance of river catchments) but would help if we want to calculate pet time series for other purposes.
• Decide if the evap submodels read their input data or receive (possibly adjusted) input data from the main model.
• Eventually, support letting submodels read input time series on their own (related to More flexibility when reading in time series. #75).

To clarify the "who reads the input data" issue: Most evaporation methods require air temperature input. Snow-related methods do so as well. hland_v1, for example, currently adjusts the average basin temperature to the elevation of individual zones. If we still let hland_v1 do the job, it must do so only once for at least two purposes. Additionally, the evaporation and the snow module would receive consistent temperature estimates. These points speak for letting the main model preprocess the input time series. However, I tend to favour letting the submodels read and process the input data in this case, as it allows for more flexibility. More importantly, this would keep the input data requirements of the involved models transparent. Consider, for example, air pressure, which is required by very few evaporation methods (e.g. evap_fao). If hland_v1 were to supply all input data to the evaporation submodel and evap_fao, it would have to specify air pressure as required but actually use it only under specific configurations. (Regarding consistency: we could also factor out the height adjustment of air temperature so that users could use it as a sub-submodel and be free to select the same approach for different purposes. However, we have not decided if we will support that submodels can reference other submodels. So far, it is not forbidden.)