INTERFACE / PUBLIC COMPONENTS / NAMELIST / FILES / REFERENCES / ERRORS / BUGS / PLANS / PRIVATE COMPONENTS

MODULE model_mod

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"

OVERVIEW

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.



OTHER MODULES USED

types_mod
time_manager_mod
location_mod (multiple choices here)
utilities_mod
POSSIBLY MANY OTHERS DEPENDING ON MODEL DETAILS



PUBLIC INTERFACE

use ensemble_manager_mod, only : get_model_size
 adv_1step
 get_state_meta_data
 model_interpolate
 get_model_time_step
 end_model
 static_init_model
 init_time
 init_conditions
 nc_write_model_atts
 nc_write_model_vars
 pert_model_state
 get_close_maxdist_init
 get_close_obs_init
 get_close_obs
 ens_mean_for_model

NOTES

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




PUBLIC COMPONENTS

The following routines must be public and will be called by other parts of the DART framework.


var = get_model_size()
 integer :: get_model_size
 

Description

Returns the size of the model as an integer. Required for all applications.

var    The size of the model state vector.


call adv_1step(x,time)
 real(r8), dimension(:), intent(inout) :: x
 type(time_type), intent(in)           :: time
 

Description

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.


call get_state_meta_data(index_in,location,var_type)
 integer, intent(in)              :: index_in
 type(location_type), intent(out) :: location
 integer, optional, intent(out)   :: var_type
 

Description

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.


call model_interpolate(x,location,itype,obs_val,istatus)
 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
 

Description

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.


var = get_model_time_step()
 type(time_type) :: get_model_time_step
 

Description

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.


call end_model()
 

Description

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.



call static_init_model()
 

Description

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.



call init_time(time)
 type(time_type), intent(out) :: time
 

Description

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.


call init_conditions(x)
 real(r8), dimension(:), intent(out) :: x
 

Description

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.


var = nc_write_model_atts(ncFileID)
 integer             :: nc_write_model_atts
 integer, intent(in) :: ncFileID
 

Description

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.


var = nc_write_model_vars(ncFileID, statevec, copyindex, timeindex)
 integer                            :: nc_write_model_vars
 integer, intent(in)                :: ncFileID
 real(r8), dimension(:), intent(in) :: statevec
 integer, intent(in)                :: copyindex
 integer, intent(in)                :: timeindex
 

Description

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.


call pert_model_state(state, pert_state, interf_provided)
 real(r8), dimension(:), intent(in)  :: state
 real(r8), dimension(:), intent(out) :: pert_state
 logical, intent(out)                :: interf_provided
 

Description

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.


call ens_mean_for_model(ens_mean)
 real(r8), dimension(:), intent(in)  :: ens_mean
 

Description

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


call get_close_maxdist_init(gc, maxdist)
 type(get_close_type), intent(inout) :: gc
 real(r8),             intent(in)    :: maxdist
 

Description

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_init
The 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_init
In 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.


call get_close_obs_init(gc, num, obs)
 type(get_close_type), intent(inout) :: gc
 integer,              intent(in)    :: num
 type(location_type),  intent(in)    :: obs(num)
 

Description

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_init
The 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_init
In 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


call get_close_obs(gc, base_obs_loc, base_obs_kind, obs, obs_kind, num_close, close_ind [, dist])
 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(:)
 

Description

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_obs
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 => get_close_obs
         
public  get_close_obs
In 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.




NAMELIST

We adhere to the F90 standard of starting a namelist with an ampersand '&338;' and terminating with a slash '/'.

 namelist / model_nml / 
                                                                                
                                                               
 

Discussion

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





FILES




REFERENCES


ERROR CODES and CONDITIONS







KNOWN BUGS




FUTURE PLANS

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.