MODULE model_mod

DART project logo

Jump to DART Documentation Main Index
version information for this file:
$Id: model_mod.html 6382 2013-08-07 20:45:16Z nancy $

NAMELIST / INTERFACES / FILES / REFERENCES / ERRORS / PLANS / PRIVATE COMPONENTS / TERMS OF USE

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.

[top]

NAMELIST

This namelist is read from the file input.nml. Namelists start with an ampersand '&' and terminate with a slash '/'. Character strings that contain a '/' must be enclosed in quotes to prevent them from prematurely terminating the 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.



[top]

OTHER MODULES USED

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

PUBLIC INTERFACES

use model_mod, only : get_model_size
 adv_1step
 get_state_meta_data
 model_interpolate
 get_model_time_step
 static_init_model
 end_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

A namelist interface &model_nml may be defined by the module, in which case it will be read from file input.nml. The details of the namelist are always model-specific (there are no generic namelist values).

A note about documentation style. Optional arguments are enclosed in brackets [like this].


model_size = get_model_size( )
integer :: get_model_size

Returns the length of the model state vector. Required.

model_size The length of the model state vector.


call adv_1step(x, time)
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 or 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 State vector of length model_size.
time    Specifies time of the initial model state.


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 

Given an integer index into the state vector structure, returns the associated location. A second intent(out) optional argument returns the generic kind of this item, e.g. KIND_TEMPERATURE, KIND_DENSITY, KIND_SALINITY, KIND_U_WIND_COMPONENT. This interface is required to be functional for all applications.

index_in    Index of state vector element about which information is requested.
location The location of state variable element.
var_type The generic kind 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

Given a state vector, a location, and a model state variable kind 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 a positive value should be returned. The itype variable is one of the KIND parameters defined in the obs_kind_mod.f90 file and defines which generic kind of item is being interpolated. In low order models that have no notion of kinds of variables this argument may 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 Kind of state field to be interpolated.
obs_val The interpolated value from the model.
istatus Integer value returning 0 for success. Other values can be defined for various failures.


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

Returns the time step (forecast length) of the model; the smallest increment in time that the model is capable of advancing the state in a given implementation. The actual value may be set by the model_mod namelist (depends on the model). This interface is required for all applications.

var    Smallest time step of model.


call static_init_model()

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



call init_time(time)
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.


call init_conditions(x)
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.


ierr = nc_write_model_atts(ncFileID)
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 kind, 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, kind, 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        
ncFileID    Integer file descriptor to previously-opened netCDF file.
ierr Returns a 0 for successful completion.


ierr = 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

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 kind 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, kind, 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         
ncFileID file descriptor to previously-opened netCDF file.
statevec A model state vector.
copyindex    Integer index of copy to be written.
timeindex The timestep counter for the given state.
ierr Returns 0 for normal completion.


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

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    Returns false if model_mod cannot do this, else true.


call get_close_maxdist_init(gc, maxdist)
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_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)

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(:)

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.


call ens_mean_for_model(ens_mean)
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    State vector containing the ensemble mean.

[top]

FILES

[top]

REFERENCES

  1. none
[top]

ERROR CODES and CONDITIONS

KNOWN BUGS

none at this time

[top]

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.

[top]

PRIVATE COMPONENTS

N/A

[top]

Terms of Use

DART software - Copyright 2004 - 2013 UCAR.
This open source software is provided by UCAR, "as is",
without charge, subject to all terms of use at
http://www.image.ucar.edu/DAReS/DART/DART_download

Contact: your_name_here
Revision: $Revision: 6382 $
Source: $URL: https://svn-dares-dart.cgd.ucar.edu/DART/releases/classic/models/model_mod.html $
Change Date: $Date: 2013-08-07 14:45:16 -0600 (Wed, 07 Aug 2013) $
Change history:  try "svn log" or "svn diff"