Contact: | your_name_here |
Revision: | $Revision: 2801 $ |
Source: | $URL: http://subversion.ucar.edu/DAReS/DART/trunk/models/model_mod.html $ |
Change Date: | $Date: 2007-04-04 22:11:48 -0600 (Wed, 04 Apr 2007) $ |
Change history: | try "svn log" or "svn diff" |
Every model that is DART compliant must provide an interface as documented here. The file models/template/model_mod.f90 provides the fortran interfaces for a minimal implementation meeting these requirements. When adding a new model to DART you can either start by modifying a model_mod.f90 file from a similar model already in DART or start with the template file. Either way, the supplied interface must match these descriptions exactly; no details of the underlying model can impact the interface.
Several of the routines listed below are allowed to be a NULL INTERFACE. This means the subroutine or function name must exist in this file, but it is ok if it contains no executable code.
A few of the routines listed below are allowed to be a PASS-THROUGH INTERFACE. This means the subroutine or function name can be listed on the 'use' line from the location_mod, and no subroutine or function with that name is supplied in this file. Alternatively, this file can provide an implementation which calls the underlying routines from the location_mod and then alters or augments the results based on model-specific requirements.
The system comes with several types of location modules for computing
distances appropriately. Two of the
ones most commonly used are for data in a 1D system and for data in
a 3D spherical coordinate system. Make the selection by listing
the appropriate choice from location/*/location_mod.f90
in the corresponding path_names_* file at compilation time.
types_mod time_manager_mod location_mod (multiple choices here) utilities_mod POSSIBLY MANY OTHERS DEPENDING ON MODEL DETAILS
Optional namelist interface &model_nml may be read from file input.nml The details of the namelist are always model specific (there are no generic namelist values).
The following routines must be public and will be called by other parts of the DART framework.
integer :: get_model_size
Returns the size of the model as an integer. Required for all applications.
var | The size of the model state vector. |
real(r8), dimension(:), intent(inout) :: x type(time_type), intent(in) :: time
Does a single timestep advance of the model. The input value of the vector x is the starting condition and x must be updated to reflect the changed state after a timestep. The time argument is intent in and is used for models that need to know the date/time to compute a timestep, for instance for radiation computations. This interface is only called if the namelist parameter async is set to 0 in perfect_model_obs of filter or if the program integrate_model is to be used to advance the model state as a separate executable. If one of these options is not going to be used (the model will only be advanced as a separate model-specific executable), this can be a NULL INTERFACE. (The subroutine name must still exist, but it can contain no code and it will not be called.)
x | Input state vector that is returned at the next timestep. |
time | Initial time of the model state that is returned at the advanced time. |
integer, intent(in) :: index_in type(location_type), intent(out) :: location integer, optional, intent(out) :: var_type
Given an integer index into the state vector structure, returns the associated location. A second intent(out) optional argument kind can be returned if the model has more than one type of field (for instance temperature and zonal wind component). This routine could also be called get_state_location_plus() since it returns not the data value, but the location of that value, plus an optional variable type (e.g. U_WIND or V_WIND). This interface is required for all applications as it is used to compute the distance between observations and state variables.
index_in | Index of state vector element about which information is requested. |
location | The location of state variable element. |
var_type | The type of the state variable element. |
real(r8), dimension(:), intent(in) :: x type(location_type), intent(in) :: location integer, intent(in) :: itype real(r8), intent(out) :: obs_val integer, intent(out) :: istatus
Given a state vector, a location, and a model state variable type, interpolates the state variable field to that location and returns the value in obs_val. The istatus variable should be returned as 0 unless there is some problem in computing the interpolation in which case an alternate value should be returned. The itype variable is a model specific integer that specifies the type of field (for instance temperature, zonal wind component, etc.). In low order models that have no notion of types of variables, this argument can be ignored. For applications in which only perfect model experiments with identity observations (i.e. only the value of a particular state variable is observed), this can be a NULL INTERFACE. Otherwise it is required (which is the most common case).
x | A model state vector. |
location | Location to which to interpolate. |
itype | Type of state field to be interpolated. |
obs_val | The returned interpolated value. |
istatus | Integer value returning 0 for successful, other values can be defined for various failures. |
type(time_type) :: get_model_time_step
Returns the the time step of the model; the smallest increment in time that the model is capable of advancing the state in a given implementation. This interface is required for all applications.
var | Smallest time step of model. |
Does any shutdown and clean-up needed for model. Can be a NULL INTERFACE if the model has no need to clean up storage, etc.
Called to do one time initialization of the model. As examples, might define information about the model size or model timestep. In models that require pre-computed static data, for instance spherical harmonic weights, these would also be computed here. Can be a NULL INTERFACE for the simplest models.
type(time_type), intent(out) :: time
Companion interface to init_conditions. Returns a time that is somehow appropriate for starting up a long integration of the model. At present, this is only used if the namelist parameter start_from_restart is set to .false. in the program perfect_model_obs. If this option is not to be used in perfect_model_obs, or if no synthetic data experiments using perfect_model_obs are planned, this can be a NULL INTERFACE.
time | Initial model time. |
real(r8), dimension(:), intent(out) :: x
Returns a model state vector, x, that is some sort of appropriate initial condition for starting up a long integration of the model. At present, this is only used if the namelist parameter start_from_restart is set to .false. in the program perfect_model_obs. If this option is not to be used in perfect_model_obs, or if no synthetic data experiments using perfect_model_obs are planned, this can be a NULL INTERFACE.
x | Initial conditions for state vector. |
integer :: nc_write_model_atts integer, intent(in) :: ncFileID
This routine must write the model-specific attributes to a netCDF file. This includes coordinate variables and any metadata, but NOT the model state vector. We do have to allocate SPACE for the model state vector, but that variable gets filled as the model advances. models/template/model_mod.f90 contains code that can be used for any model as-is. The generic code prepares a file which will have the state vector written as a single 1-D array of data. This routine can be modified to save the data in form more closely related to the actual grid shape and variable type, and could also be extended to write additional attributes if desired. This routine is required for all models.
The typical sequence for adding new dimensions, variables, attributes:
NF90_OPEN ! open existing netCDF dataset NF90_redef ! put into define mode NF90_def_dim ! define additional dimensions (if any) NF90_def_var ! define variables: from name, type, and dims NF90_put_att ! assign attribute values NF90_ENDDEF ! end definitions: leave define mode NF90_put_var ! provide values for variable NF90_CLOSE ! close: save updated netCDF dataset
var | Returns a 0 for successful completion. |
ncFileID | netCDF file identifier. |
integer :: nc_write_model_vars integer, intent(in) :: ncFileID real(r8), dimension(:), intent(in) :: statevec integer, intent(in) :: copyindex integer, intent(in) :: timeindex
This routine must write the model-specific state vector (data) to a netCDF file. models/template/model_mod.f90 contains code that can be used for any model as-is. It writes the state vector as a single 1-D array of data. The code can be modified to write out the data in a form more closely resembling the computational grid and variable types if if desired. This routine is required for all models.
Typical sequence for adding new dimensions,variables,attributes:
NF90_OPEN ! open existing netCDF dataset NF90_redef ! put into define mode NF90_def_dim ! define additional dimensions (if any) NF90_def_var ! define variables: from name, type, and dims NF90_put_att ! assign attribute values NF90_ENDDEF ! end definitions: leave define mode NF90_put_var ! provide values for variable NF90_CLOSE ! close: save updated netCDF dataset
var | Returns 0 for normal completion. |
ncFileID | NetCDF file identifier. |
statevec | A model state vector. |
copyindex | Which copy of state in output file is being written |
timeindex | What time level of output is this. |
real(r8), dimension(:), intent(in) :: state real(r8), dimension(:), intent(out) :: pert_state logical, intent(out) :: interf_provided
Given a model state vector, perturbs this vector. Used to generate initial conditions for spinning up ensembles. If the model_mod does not want to do this, instead allowing the default algorithms in filter to take effect, interf_provided should be returned as false. Otherwise, it should be returned as true.
state | State vector to be perturbed. |
pert_state | Perturbed state vector |
interf_provided | Returned false if model_mod doesn't know how to do this, else true. |
real(r8), dimension(:), intent(in) :: ens_mean
A model-size vector with the means of the ensembles for each of the state vector items. The model should save a local copy of this data if it needs to use it later to compute distances or other values. This routine is called after each model advance and contains the updated means. If the model has no use for the means this should be a NULL INTERFACE. See the CAM model_mod for an example of how this routine can be used.
ens_mean | Ensemble mean state vector |
type(get_close_type), intent(inout) :: gc real(r8), intent(in) :: maxdist
In distance computations any two locations closer than the given maxdist will be considered close by the get_close_obs() routine. In general this is a PASS-THROUGH ROUTINE. It is listed on the use line for the locations_mod, and in the public list for this module, but has no subroutine declaration and no other code in this module:
use location_mod, only: get_close_maxdist_init public get_close_maxdist_initThe location module has code which stores maxdist in the gc derived type. However, if the model needs to alter the value or wants to supply an alternative implementation it can intercept the call like so:
use location_mod, only: & lm_get_close_maxdist_init => get_close_maxdist_init public get_close_maxdist_initIn this case a local get_close_maxdist_init() routine must be supplied. To call the original code in the location module use:
call lm_get_close_maxdist_init(gc, mymaxdist)This subroutine will be called before get_close_obs_init and get_close_obs.
In most cases the PASS-THROUGH ROUTINE will be used.
gc | The get_close_type which stores precomputed information about the locations to speed up searching |
maxdist | Anything closer than this will be considered close. |
type(get_close_type), intent(inout) :: gc integer, intent(in) :: num type(location_type), intent(in) :: obs(num)
In general this is a PASS-THROUGH ROUTINE. The default routine in the location module precomputes information to accelerate the distance computations done by get_close_obs(). Like the other PASS-THROUGH ROUTINES it is listed on the use line for the locations_mod, and in the public list for this module, but has no subroutine declaration and no other code in this module:
use location_mod, only: get_close_obs_init public get_close_obs_initThe location module code bins the list of locations and precomputes maximum possible distances between bins. However, if the model needs to alter the values or wants to supply an alternative implementation it can intercept the call like so:
use location_mod, only: & lm_get_close_obs_init => get_close_obs_init public get_close_obs_initIn this case a local get_close_obs_init() routine must be supplied. To call the original code in the location module use:
call lm_get_close_obs_init(gc, num, obs)This subroutine will be called after get_close_maxdist_init and before get_close_obs.
In most cases the PASS-THROUGH ROUTINE will be used.
gc | The get_close_type which stores precomputed information about the locations to speed up searching |
num | The number of items in the third argument |
obs | A list of locations which will be part of the subsequent distance computations |
type(get_close_type), intent(in) :: gc type(location_type), intent(in) :: base_obs_loc integer, intent(in) :: base_obs_kind type(location_type), intent(in) :: obs(:) integer, intent(in) :: obs_kind(:) integer, intent(out) :: num_close integer, intent(out) :: close_ind(:) real(r8), optional, intent(out) :: dist(:)
Given a location and kind, compute the distances to all other locations in the obs list. The return values are the number of items which are within maxdist of the base, the index numbers in the original obs list, and optionally the distances. The gc contains precomputed information to speed the computations.
In general this is a PASS-THROUGH ROUTINE. It is listed on the use line for the locations_mod, and in the public list for this module, but has no subroutine declaration and no other code in this module:use location_mod, only: get_close_obs public get_close_obsHowever, if the model needs to alter the values or wants to supply an alternative implementation it can intercept the call like so:
use location_mod, only: & lm_get_close_obs => get_close_obs public get_close_obsIn this case a local get_close_obs() routine must be supplied. To call the original code in the location module use:
call lm_get_close_obs(gc, base_obs_loc, ...)This subroutine will be called after get_close_maxdist_init and get_close_obs_init.
In most cases the PASS-THROUGH ROUTINE will be used, but some models need to alter the actual distances depending on the observation or state vector kind, or based on the observation or state vector location. It is reasonable in this case to leave get_close_maxdist_init() and get_close_obs_init() as pass-through routines and intercept only get_close_obs(). The local get_close_obs() can first call the location mod routine and let it return a list of values, and then inspect the list and alter or remove any entries as needed. See the CAM and WRF model_mod files for examples of this use.
gc | The get_close_type which stores precomputed information about the locations to speed up searching |
base_obs_loc | Reference location. The distances will be computed between this location and every other location in the obs list |
base_obs_kind | The kind of base_obs_loc |
obs | Compute the distance between the base_obs_loc and each of the locations in this list |
obs_kind | The corresponding kind of each item in the obs list |
num_close | The number of items from the obs list which are within maxdist of the base location |
close_ind | The list of index numbers from the obs list which are within maxdist of the base location |
dist | If present, return the distance between each entry in the close_ind list and the base location. If not present, all items in the obs list which are closer than maxdist will be added to the list but the overhead of computing the exact distances will be skipped. |
We adhere to the F90 standard of starting a namelist with an ampersand '&338;' and terminating with a slash '/'.
namelist / model_nml /
Models are free to include a model namelist which can be read when static_init_model is called. A good example can be found in the lorenz_96 model_mod.f90.
This namelist is read in a file called input.nml
It is likely that a number of additional optional interfaces will be added to the model_mod structure. For instance, hints about how to divide the state vector into regions for parallel assimilation will need to be obtained from the model. It is planned that the interf_provided mechanism used in pert_model_state will allow those who do not wish to support enhanced interfaces to add NULL interfaces by simply pasting in an interface block.