Changes between Version 2 and Version 3 of Branches/Driver_Atm_Lev

Timestamp:

2012-06-01T13:00:43+02:00 (12 years ago)

Author:

jpolcher

Comment:

--

Branches/Driver_Atm_Lev

@@ -18 +18 @@
 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).
+  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).
 
-* 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.
+  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.
 
-* 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.
+  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.
@@ -28 +28 @@
 == 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.
+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 ==