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 :

1. 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).

2. 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.

3. 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 required to adapt existing netCDF forcing files.

We propose to add to the netCDF files a scalar information on the height of the 2 types of atmospheric variables (scalar : T, Q and vector : wind). This can be done easily with the following type of script :

Creat a cdf file (levels.cdf) of the following type :

netcdf filename {
dimensions:
        lev = 1 ;
variables:
        float IFSHybSigA(lev) ;
              IFSHybSigA:long_name = "hybrid level at layer midpoints" ;
              IFSHybSigA:title="hyam (mlev=hyam+hybm*aps)";
        float IFSHybSigB(lev) ;
              IFSHybSigB:long_name = "hybrid level at layer midpoints" ;
              IFSHybSigB:title="hybm (mlev=hyam+hybm*aps)";
data:
 IFSHybSigA = 0.0 ;
 IFSHybSigB = 0.998815059661865 ;
}

Then have a small script when generates the netCDF file (levels.nc) and adds the variables to an existing forcing file :

ncgen -o levels.nc levels.cdf
ncks -A -v IFSHybSigA,IFSHybSigB levels.nc My_ORCHIDEE_Forcing_2012.n

This scalar information can either be of 3 types :

1. Sigma level height : This allows then to compute the actual height given the surface pressure.

2. Hybrid sigma levels (as in the example above) : Also given surface pressure we can compute the height.

3. height in meters : This is the usual way we get forcing data.

Following a convention readdim2.f90 will check for the presence of either one of the 3 above listed cases.

If one of the cases is found in the forcing file, forcing_just_read will compute the height directly after reading surface pressure.

If none of the above cases is found, the variables HEIGHT_LEV1 and HEIGHT_LEVW found in run.def will be used to fill the global fields.

Proposed modifications in the code

dim2_driver.f90

simplify the code by keeping only the following variables :

• zlev_vec(:,:)
• zlevuv_vec(:,:)

Their content will be provided by the call to forcing_read. This makes redundant variables lev and levuv and they can be deleted from the arguments of forcing_grid.

The vertical interpolation would be done in all cases. Should zlev_vec and zlevuv_vec have the same value the interpolation does not change the values of u and v. This simplifies the code and makes the variable lower_wind redundant.

readdim2.f90, forcing_grid