[Dart-dev] DART/branches Revision: 11392

dart at ucar.edu dart at ucar.edu
Thu Mar 23 16:42:21 MDT 2017

thoar at ucar.edu
2017-03-23 16:42:18 -0600 (Thu, 23 Mar 2017)
Documenting the new required interfaces in the default template model_mod.html
Repurposing the models/template/README to be the model/README - no content change yet.

Copied: DART/branches/rma_trunk/models/README (from rev 11391, DART/branches/rma_trunk/models/template/README)
--- DART/branches/rma_trunk/models/README	                        (rev 0)
+++ DART/branches/rma_trunk/models/README	2017-03-23 22:42:18 UTC (rev 11392)
@@ -0,0 +1,241 @@
+# DART software - Copyright 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
+# DART $Id$
+Hints for porting a new model to DART:
+copy this template directory into a DART/models/xxx
+directory for your new model.
+if the coordinate system for the model is 1d, you're ok as-is.
+if model coordinates are 3d, edit the work/path_names_* files
+and change location/oned/* to location/threed_sphere/*
+if your model is closer to the simpler examples (e.g. lorenz),
+the existing model_mod.f90 is a good place to start.
+if your model is a full 3d geophysical one (e.g. like cam, pop, etc)
+then rename full_model_mod.f90 to model_mod.f90 and start there.
+edit all the work/path_names_* files and change models/template/xxx
+to use the name of the directory for your model.
+try ./quickbuild.csh and everything should compile at this point.
+the required subroutines are these:
+public :: 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
+in addition, model_mod can contain subroutines that are used
+for other utility programs and we recommend at least the following
+routines be added to model_mod.f90:
+public :: model_file_to_dart_vector, &     ! converter
+          dart_vector_to_model_file, &     ! converter
+          get_gridsize,              &     ! called by everyone
+          get_model_filename,        &     ! called by both (set_model_filename?)
+          get_state_time,            &     ! model_to_sv, static_init_model
+          set_state_time  !(?)             ! sv_to_model, trans_time
+edit the model mod and fill in the routines in this order:
+1. static_init_model() - make it read in the grid information
+  and the number of variables that will be in the state vector
+ (fill in the progvar derived type).   fill in the model_size
+  variable.  as part of this work, fill in the get_gridsize() 
+  code.
+  after number 1 is done, get_model_size() and 
+  get_model_time_step() from the template should be ok as-is.
+2. model_file_to_dart_vector() - given a model data file, read in
+  the fields and put them into the 1D DART state vector.  make
+  sure the order and values match the progvar array.  
+3. dart_vector_to_model_file() - do the reverse of the previous step.
+4. get_state_meta_data() - given an index number into the state vector
+    return the location and type.  the code which loops over the
+    progvar should already do the type, but code to compute what
+    lon, lat, and vertical (for a 3d model) or x location (1d)
+    corresponds to this item must be written.
+5. model_interpolate() - given a location (lon/lat/vert in 3d, x in 1d)
+   and a state KIND_xxx kind, return the interpolated value the field
+   has at that location.   this is probably one of the routines that
+   will take the most code to write.
+6. nc_write_model_atts(), nc_write_model_vars() - when filter runs
+   it calls these routines to output model data into a netcdf diagnostic
+   file which is unrelated to the model data files.  it is possible to
+   have the ensemble data just be dumped as a single 1D vector but
+   that makes the files less useful.  generally it's most useful to
+   put the grid info and dump each variable from the state vector
+   into a separate netcdf variable.  the diagnostic files contain the
+   ensemble mean, the ensemble stddev, the inflation information, and
+   then optionally some or all of the individual ensemble members.
+for now, ignore these routines:
+   get_close_maxdist_init()
+   get_close_obs_init()

More information about the Dart-dev mailing list