[Dart-dev] [5040] DART/trunk/models/cam: Minor updates - incorporate the cgd-cam information in the model_mod.html

nancy at ucar.edu nancy at ucar.edu
Wed Jun 29 10:22:55 MDT 2011


Revision: 5040
Author:   nancy
Date:     2011-06-29 10:22:55 -0600 (Wed, 29 Jun 2011)
Log Message:
-----------
Minor updates - incorporate the cgd-cam information in the model_mod.html
page, and add a bit more intro stuff to the cam_guidelines.  so far the
async3 option is NOT part of the distribution so remove references to it
in the cam doc for now.

Modified Paths:
--------------
    DART/trunk/models/cam/doc/cam_guidelines.html
    DART/trunk/models/cam/model_mod.html

-------------- next part --------------
Modified: DART/trunk/models/cam/doc/cam_guidelines.html
===================================================================
--- DART/trunk/models/cam/doc/cam_guidelines.html	2011-06-29 15:51:14 UTC (rev 5039)
+++ DART/trunk/models/cam/doc/cam_guidelines.html	2011-06-29 16:22:55 UTC (rev 5040)
@@ -69,26 +69,48 @@
 
 <!--===============================================-->
 <A NAME="OVERVIEW"></A>
-<H2>DART-CAM OVERVIEW</H2>
+<H2>DART-CAM Setup Overview</H2>
 
 <P>
-The up-to-date overview will always be available at 
-<a href="http://www.image.ucar.edu/DAReS/DART/cgd_cam.shtml">
-http://www.image.ucar.edu/DAReS/DART/cgd_cam.shtml</a>
+This document gives specific help in setting up a
+DART-CAM experiment for the first time.
+Unless you just came from there, also see the
+<a href="../model_mod.html">model_mod</a> documentation
+on the code-level interfaces and namelist values for DART-CAM.
 </P>
 
+<P>
+Usually a run of DART-CAM involves executing multiple sequential
+batch job steps, each step consisting of a day's worth
+of assimilation.  Between job steps the output from the
+previous job step must be saved or moved to be used as
+input for the next job step.  Files may need to be archived
+or postprocessed.  And finally, DART is a parallel MPI program
+and CAM can be compiled as a serial job, an OpenMP parallel job,
+or an MPI parallel job.  On some systems an MPI parallel job
+cannot start another MPI parallel job, so running both a
+parallel DART and parallel CAM as a single job can be hard.
+</P>
 
 <P>
-For the <A HREF="../../../../doc/html/Kodiak_release.html"> Kodiak_release </A>
-and beyond, the async=3 (.../input.nml:filter_nml) option 
-has been given a new functionality; advancing several purely OpenMP CAMs at once.
-This contrasts with async = 4, which runs each purely MPI CAM on all available processors
-in sequence.
+The DART distribution comes with some scripts which will probably
+have to be customizes for other users.  The <em class=file>shell_scripts</em>
+directory contains simple example scripts.  The <em class=file>
+full_experiment</em> directory contains scripts which do a full-up
+experiment with multiple days and automatic archiving.
+</P>
 
-Async=2 also runs an MPI filter, but a single-threaded CAM.
-This will advance 1 ensemble member on each processor 
-(up to the lesser of the number of ensemble members or the number of processors).  
+<P>
+For parallelism options it is fastest to run a serial (single-threaded)
+or OpenMP CAM with a parallel DART.  This is selected by compiling
+CAM with the proper options, and then setting the <em class=code>async</em>
+namelist variable in the <a href="../../../filter/filter.html#Namelist">&amp;filter_nml</a>
+namelist to 2.   If there is not enough memory to run CAM as a serial
+job CAM can be compiled as a parallel program using MPI and then the
+<em class=code>async</em> value is set to 4 instead.
+</P>
 
+<P>
 For the short forecasts (6 hours) typically needed for assimilation,
 and on machines with at least as many processors as ensemble members,
 async=4 is usually much less efficient than async=2.
@@ -98,11 +120,10 @@
 async=2 lets all the start-up phases run at the same time on all of the processors.
 The drawback of async=2 is that there may not be enough memory on a single
 processor to handle a whole CAM.
-Async = 3 will be between 2 and 4, and depend on the distribution of processors.
 </P>
 
 <P>
-async=2, 3, and 4 allow users to control the assimilation through a single script,
+async=2 and 4 allow users to control the assimilation through a single script,
 'job_mpi.csh'.
 job_mpi.csh has a section of user set parameters which define many aspects of
 the assimilation.  
@@ -116,12 +137,6 @@
 </P>
 
 <P>
-These options have been tested for DART-CAM in batch submission environments 
-PBS and LSF on Linux clusters and IBM AIX.
-<!-- ??? Nancy; how much of an overstatement is this?  -->
-</P>
-
-<P>
 There are, no doubt, things missing from these lists, so don't struggle too long
 before contacting raeder'at'ucar.edu.
 </P>
@@ -144,11 +159,11 @@
 
 <A NAME="CALLINGTREE"></A>
 <HR>
-<H2>CALLING TREE</H2>
+<H2>Calling Tree</H2>
 
 <P>
 The calling tree for the scripts and fortran executables when running under
-async=2, 3, or 4 is:
+async=2 or 4 is:
 </P>
 
 <TABLE border=0 cellpadding=3 width=100%>
@@ -203,7 +218,7 @@
 
 <!-- <A NAME="FLOWCHART"></A>
 <HR>
-<H2>FLOW CHART</H2>
+<H2>Flow Chart</H2>
 <P>
 The tasks of each script, and communication between them,  are summarized in a 
 <A HREF="flow_5.xfig.gif" > flow chart </A>.
@@ -216,7 +231,7 @@
 <!--===============================================-->
 <A NAME="SETUP"></A>
 <HR>
-<H2>EXPERIMENT SET-UP</H2>
+<H2>Experiment Set-Up</H2>
 <P>
 
 Instructions for setting up a DART/CAM in "stand-alone" mode assimilation.
@@ -248,7 +263,7 @@
          <LI>Script DART/models/cam/work/quick_build.csh is recommended for compiling 
              the package.  
 	     It is set up to compile and run the preprocessor, 
-	     compile filter and wakeup_filter as MPI processes (async=2, 3, and 4),
+	     compile filter and wakeup_filter as MPI processes (async=2 and 4),
              and compile all other executables (but not CAM) as single process programs.  
              If you want a single-process filter, quick_build.csh can take -nompi 
              as an argument, which will build filter and wakeup_filter that way.
@@ -443,7 +458,7 @@
 <!--===============================================-->
 <A NAME="INITIALFILES"></A>
 <HR>
-<H2>CAM INITIAL ENSEMBLES</H2>
+<H2>CAM Initial Ensembles</H2>
 <P>
 
 Strategies for generating an initial ensemble from which DART can start.
@@ -534,7 +549,7 @@
 <!--===============================================-->
 <A NAME="FILECONTENTS"></A>
 <HR>
-<H2>FILE CONTENTS</H2>
+<H2>File Contents</H2>
 <P>
 
 See the <A HREF="../../../doc/html/Kodiak_release.html"> Kodiak release notes </A>
@@ -613,7 +628,7 @@
 <!--===============================================-->
 <A NAME="OUTPUTDIRECTORY"></A>
 <HR>
-<H2>OUTPUT DIRECTORY </H2>
+<H2>Output Directory </H2>
 <P>
 Organization of output directories: 
 </P>
@@ -687,7 +702,7 @@
 <!--===============================================-->
 <A NAME="HINTS"></A>
 <HR>
-<H2>HELPFUL HINTS</H2>
+<H2>Helpful Hints</H2>
 
 <P>
 In the following, MPI filter uses all of the requested processors.
@@ -719,6 +734,8 @@
 
 <P>
 async = 3 is part way between async = 2 and 4.  
+It is part of an experimental version of the code which is in 
+the general release yet.
 CAM must be compiled with pure OpenMP parallelism.
 Then the MPI filter can execute multiple CAMs simultaneously on several processors each.
 The start-up for each is still a single process, 
@@ -757,7 +774,7 @@
 <!--===============================================-->
 <A NAME="SPACE"></A>
 <HR>
-<H2>SPACE REQUIREMENTS</H2>
+<H2>Space Requirements</H2>
 
 <P>
 Space requirements (Mb per ensemble member) for several CAM resolutions.

Modified: DART/trunk/models/cam/model_mod.html
===================================================================
--- DART/trunk/models/cam/model_mod.html	2011-06-29 15:51:14 UTC (rev 5039)
+++ DART/trunk/models/cam/model_mod.html	2011-06-29 16:22:55 UTC (rev 5040)
@@ -53,7 +53,65 @@
 <H2>Overview</H2>
 
 <P>
-This is the DART interface module for the stand-alone CAM model,
+DAReS has successfully incorporated CAM -- The Community Atmosphere Model --
+into the DART framework. It is being actively used by graduate students,
+post-graduates, and scientists at universities and research labs. Others are
+only using analyses for their time period and resolution of interest,
+produced here at NCAR using DART-CAM. In addition to the standard DART
+features described elsewhere, current capabilities (Jamaica-release) include
+the abilities to:
+</P>
+
+<UL>
+<LI>Use either the Eulerian or finite-volume core.</LI>
+<LI>Use any resolution of CAM without recompiling DART. The standard resolutions of 
+T21, T42, T85, FV 2x2.5 and 4x5 have been tested.</LI>
+<LI>Assimilate a variety of observations; to date the observations 
+successfully assimilated include the NCEP reanalysis BUFR obs (T,U,V), 
+Global Positioning System radio occultation obs, and MOPITT carbon monoxide 
+(when a chemistry model is incorporated into FV CAM). Research is under way to 
+assimilate surface observations, specific humidity, cloud liquid water, and aerosols.</LI>
+<LI>Specify, via namelist entries, the CAM (initial file) variables which will be 
+directly affected by the observations. This allows users to change the model state 
+without recompiling.</LI>
+<LI>Generate analyses on the CAM grid which are of comparable quality to those 
+produced by operational centers, but which have only CAM model error in them, 
+rather than the model error of the models used at the centers.</LI>
+<LI>Generate such analyses with as few as 20 ensemble members.</LI>
+</UL>
+
+<P>
+In addition to the standard DART package there is a collection of initial
+condition files at the large file website
+http://www.image.ucar.edu/pub/DART/CAM that are helpful for interfacing CAM
+with DART. More information and instructions for setting up assimilation
+experiments are available in the DART/models/cam/model_mod.html documentation
+and links.
+</P>
+
+<P>
+Sample sets of observations, which can be used with DART-CAM assimilations,
+can be found at http://www.image.ucar.edu/pub/DART/Obs_sets/ of which the
+NCEP BUFR observations are the most widely used. More information and
+instructions for setting up assimilation experiments are available in the
+DART/models/cam/model_mod.html documentation and links.
+</P>
+
+<P>
+Experience on a variety of machines has shown that it is a very good idea to
+make sure your run-time environment has the following:
+</P>
+
+<pre>
+limit stacksize unlimited
+
+limit datasize unlimited
+</pre>
+
+
+<P>
+This page contains the documentation for 
+the DART interface module for the separate-executable CAM model,
 using the either the Eulerian and Finite Volume dynamical core,
 soon the HOMME core on the cubed sphere,
 and possibly the Semi-Lagrangian core. 
@@ -68,6 +126,7 @@
 carried forward by the CAM and CLM initial files.
 For CAM 3.6 and later the ICE restart files also carry along non-state variables.
 <!-- (non-NetCDF before cice4_0_20090603 ~? cam3_6_41.). -->
+We anticipate integrating DART with the full CESM of CAM in the near future.
 </P>
 
 <P>
@@ -77,7 +136,7 @@
 the model considers to be parameters, although ongoing research is
 being conducted into the difficulties and meaning of 
 tuning  model parameters of various kinds by this method.
-The CLM incorporated in the stand-alone CAM is currently (2011-4)
+The CLM incorporated in the separate-executable CAM is currently (as of 6/2011)
 treated as a parameterization.  That is, none of its variables
 are incorporated into the DART state vector.
 For each distinct set of fields comprizing a state vector, 
@@ -92,7 +151,7 @@
 (non-surface) variable in the state vector (which are variables native to
 CAM) plus pressure on height levels.  The default state vector is PS, T,
 U, V, Q, CLDLIQ, CLDICE.  
-Variables which are not on the initial file 
+Variables which are not in the initial file 
 <A HREF="./doc/cam_guidelines.html" >can be added </A> , 
 but minor modifications to model_mod.f90 (and perhaps CAM) may be necessary.  
 </P>


More information about the Dart-dev mailing list