[Dart-dev] [5636] DART/branches/development/models/model_mod.html: this is the generic model_mod.html file in the DART/models directory

nancy at ucar.edu nancy at ucar.edu
Mon Apr 2 09:37:44 MDT 2012


Revision: 5636
Author:   nancy
Date:     2012-04-02 09:37:44 -0600 (Mon, 02 Apr 2012)
Log Message:
-----------
this is the generic model_mod.html file in the DART/models directory
(not for any one specific model).  a feeble start at unraveling the
types/kinds confusion; get_state_meta_data, model_interpolate, etc
all deal with generic kinds.  the specific types apply only to
observations, and are always associated with a generic kind before
they reach the model_mod code.  the original docs here only talked
about types, which is incorrect.

Modified Paths:
--------------
    DART/branches/development/models/model_mod.html

-------------- next part --------------
Modified: DART/branches/development/models/model_mod.html
===================================================================
--- DART/branches/development/models/model_mod.html	2012-03-30 19:18:58 UTC (rev 5635)
+++ DART/branches/development/models/model_mod.html	2012-04-02 15:37:44 UTC (rev 5636)
@@ -250,14 +250,10 @@
 
 <P>
 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. 
+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.
 </P>
 
 <TABLE width=100% border=0 summary="" cellpadding=3>
@@ -269,7 +265,7 @@
     <TD>The location of state variable element.</TD></TR>
 
 <TR><TD valign=top><em class=optionalcode>var_type</em></TD>
-    <TD>The type of the state variable element.</TD></TR>
+    <TD>The generic kind of the state variable element.</TD></TR>
 
 </TABLE>
 
@@ -295,14 +291,16 @@
 <!-- Description -->
 
 <P>
-Given a state vector, a location, and a model state variable type,
+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 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
+which case a positive value should be returned. The itype variable
+is one of the KIND parameters defined in the
+<a href="../../obs_kind/obs_kind_mod.html">obs_kind_mod.f90</a> 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.
@@ -318,7 +316,7 @@
     <TD>Location to which to interpolate.</TD></TR>
 
 <TR><TD valign=top><em class=code>itype</em></TD>
-    <TD>Type of state field to be interpolated.</TD></TR>
+    <TD>Kind of state field to be interpolated.</TD></TR>
 
 <TR><TD valign=top><em class=code>obs_val</em></TD>
     <TD> The interpolated value from the model.</TD></TR>
@@ -503,7 +501,7 @@
 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,
+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.
 <br><br>
@@ -514,7 +512,7 @@
 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_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                
@@ -558,7 +556,7 @@
 <em class=code>models/template/model_mod.f90</em> 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
+form more closely resembling the computational grid and variable kind if
 if desired.
 This routine is required for all models.
 <br><br>
@@ -569,7 +567,7 @@
 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_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                


More information about the Dart-dev mailing list