Currently, all base models use different names for the same input data. One example is the air temperature, named TemL by L-Land, T by H-Land, T by W-Land, and AirTemperature by Evap. This inconsistency is due to our attempt to preserve the names of the original model implementations.

This inconsistency than be confusing when combining different model types requiring identical input data in the same project. So far, we have encountered two unfavourable situations:

1. Assume we want to connect evap_v001 with wland_v001. evap_v001 calculates the potential evapotranspiration required by wland_v001. Instances of both application models need the air temperature of the same catchment as input data. There are currently two options to accomplish this. Either we provide the same data in separate files (one for each model type) or define an additional "input node" and connect it to both model instances. The latter avoids duplicate data but increases the project's complexity.
2. Assume we want to use both hland_v1 and lland_v1, each one for different areas of a large river basin. If we want to supply data via NetCDF-Files, we need to prepare (at least) one file for all hland_v1 instances and (at least) one file for all lland_v1 instances.

Standardising all input sequence names would solve the first problem (when not using NetCDF files) and be a significant step towards solving the second problem. However, we would give up consistency with the original models' names and need to adjust huge documentation sections. Also, this change would break all existing projects.

A compromise could be defining standard types and using them to augment the existing input sequence types.

First idea:

# general, likely in sequencetools.py
class Temperature(InputSequence):
    ...

# model-specific, e.g. in hland_inputs.py
class T(sequencetools.Temperature):
    ...

Then, a type T sequence would search for input data supplied under the name temperature only (problem: backwards compatibility) or search for input data supplied under any of these names (problem: ambiguity).

The subclass approach would also offer chances to define additional information. One relevant point we still need to discuss is the standardisation of units. So far, units are defined via docstrings and taken for documentation related features like plotting but do not affect the reading or writing of data.