We strive for a higher modularisation of our application models. Meaning we want to make many application models smaller, focussing on fewer processes. Such a modularisation would make individual models easier to understand and maintain and offer new possibilities in model coupling. One good example is the evap_v001 model, which calculates the FAO reference evaporation. Models like wland_v001 or lland_v2 get this reference evaporation (or another kind of potential evaporation) as their input and do not need to calculate the many intermediate terms of reference evaporation on their own.

The next thing we try to factor out is the calculation of global radiation from sunshine duration and the inverse case, sunshine duration from global radiation. The current reason to address this problem is as follows. lland_v3 gets the sunshine duration as input and derives the global radiation from it. This direction fits for simulating historical periods with measured data, which includes much more often sunshine duration than global radiation. However, when using the output data from meteorological models as input, we get global radiation as input data. Then, we need to calculate sunshine duration from it (or use other equations for the longwave energy balance). Principally, we could create another application model deviating from lland_v3 just in this aspect but being identical in all others. But factoring out the related process equations seem preferable, especially when taking the enormous number of process equations of lland_v3 into account.

When factoring out global radiation from lland_v3, we probably should do the same for evap_v001, which also calculates global radiation from sunshine duration. I would even suggest starting with evap_v001, as it comes with simpler equations with less need for discussion.

First, I propose to introduce a new model family. For example, we could name it Meteo if we think it should later target also other meteorological factors than sunshine duration and global radiation. Alternatively, if we want to keep the field of application more limited, we could name it something like Radiotion.

The following graph shows how evap_v001 calculates the NetRadiation (input sequences in blue, all others in black). The red line is my suggestion on how to split the old evap_001 model into the new meteo_v001 and evap_v001 models.

The reason for the chosen position of the line is that all factors left from it are mainly associated with the atmosphere, while net radiation more directly depends on the current state of the earth's surface (e.g., is there a snow cover or not?).

What surprised me when looking at the graph was that the new evap_v001 model would require two inputs, GlobalRadiation and ClearSkySolarRadiation. Using more theoretical factors like ClearSkySolarRadiation as the input to a model seems a little bit strange. Still, maybe that is the price to pay when striving for more modularity.

I have not yet thought it through thoroughly, but meteo_v001 should work in combination with a refactored version of lland_v3, too. Then, one would need to select PossibleSunshineDuration as the output of meteo_v001, because LARSIM uses the ratio between actual and possible sunshine duration instead of the ratio between actual and potential global radiation for guessing cloudiness.

The required flexibility in defining the relevant output sequences of meteo_v001 is technically already supported. However, we still could improve the usability of the related features, but we should discuss this in another issue.

The graph does not separate the "normal" radiation terms and their logged equivalents. To clarify: I think, the new evap_v001 model should be responsible to calculate LoggedGlobalRadiation and LoggedClearSkySolarRadiation, because different evaporation approaches favour different ways of guessing cloudiness during nighttime.