Revising the way the height of atmospheric variables are specified in the driver

Jan Polcher June 2012

Current situation

The driver reads the height of the atmospheric forcing variables (Temperature, humidity and wind) from the run.def. These are the variables HEIGHT_LEV1 (for T and Q) and HEIGHT_LEVW (for wind). This is done in routine forcing_grid from file readdim2.f90.

The scalar values obtained are then copied onto the global gird (i.e. iim x jjm in size).

When calling forcing_read these variables can be updated over the global grid. This is only the case when we are in a "WATCHOUT" situation. That is when when using output from an LMDZ_OR to drive ORCHIDEE off-line.

Later, in the temporal loop of dim2_driver, if the level of the wind and temperature are not the same, the wind is interpolated vertically to the level of T and Q.

Problems caused by this state of affairs

There are 3 problems with this approach :

• We impose the same value for the heigh of the atmospheric forcing variables to all points of the globe (except in the case of WATCHOUT).

• As the height of the forcing variable is in the run.def the user can change forcing data and forget to provide the changed height of the variables. This can only be solved if the height of the forcing data is in the file containing the data itself.

• The height of the variables cannot change over time. But this is the case if the atmospheric variable come from a model which uses some type of pressure coordinate.

As the fluxes computed are strongly dependent on the height of the atmospheric variable a small error here as a large impact.

Strategy for adapting the driver

The strategy to adapt the driver needs to ensure that what works today continues to work. It also needs to limit the work needed to adapt existing netCDF forcing files.

Proposed modifications in the code