[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">&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