TERMS OF USE

ASP Data Assimilation Colloquium Links

$Id: DART_ASP_Summer2003.html 10837 2016-12-23 20:51:05Z thoar@ucar.edu $

note: these links only work when online.

  1. Instructions for compiling
  2. the DART code from the Summer 2003 colloquium. [gzipped tar file ~ 8.3 MB]
  1. Exercise Overview
  2. DART Exercise Documentation
  3. Slides from Introductory Talk on Exercises
  4. A Seminar on Filtering in the Bgrid Dynamical Core
  5. Talk for CAOS Workshop, Dec. 2003
  6. Overview of Filter DA, AGU, Dec. 2003


Everything below here is for the NCAR DART Development team.
If you are working with the ASP code from above,
none of the following applies.



Table of Contents

  1. Background/Overview
  2. Creating a local copy of the project
  3. Coding Standards
  4. Building an executable
  5. The Assimilation Sequence
  6. my cheat-sheet of CVS commands
  7. acronyms
  8. Related links

Overview/General.

The rough specifications for the observation set.
The draft version of the task schedule.
Rough pseudo-code calling sequence for ensemble filter.
Rough draft of User's Guide Overview.
Flowchart of intended User's Views.


To create a local version of the project ... a "sandbox"

For the purpose of simplicity, I am assuming you will be creating your DART sandbox on a machine that need not be in CGD. It the machine IS inside CGD, the directions do not change (but this is a bit of overkill).

I have named the project repository DART so when you check out the repository, your sandbox will be installed in a directory also called DART. You can sue me later. At this point, it is in my home directory, we will move it when the RAID array is operational. [That should be a momentary inconvenience.] Since it is in my home directory, I would ask that you not add any large files to the repository, such as object or data files. At this time, I have about 200 MB of free space and the current project is about 34+MB.

On a remote filesystem

This necessitates a valid account on goldhill and presumes you are running csh,tcsh on a remote machine.
  1. From your remote machine, set some environment variables and check out the project:
    setenv CVS_RSH ssh
    setenv CVSROOT :ext:goldhill.cgd.ucar.edu:/home/thoar/CVS.REPOS
    cvs co DART
    The first two commands can be (should be) put in your dotfiles. If you are using multiple CVS repositories, you can obviate the need to keep switching your CVSROOT variable by using this alternate form of the "checkout" command:
    setenv CVS_RSH ssh
    cvs -d :ext:goldhill.cgd.ucar.edu:/home/thoar/CVS.REPOS co DART
  2. Play till the cows come home.
  3. When you want to update the repository
    cvs update -dRP
    cvs commit [-m "your message goes here"]
  4. And, if you like, you can remove the sandbox. Simply deleting the sandbox counfounds CVS' ability to track who has the project checked out. Gracefully exiting is appreciated.
    cd .. <directory above sandbox>
    cvs release -d DART
Creating some ssh keys ( ssh-keygen ) is a great way to avoid botching your password every time you issue a cvs command when using ssh.

One more thing ...

I predict this will be useful for those of us with multiple "groups". Sometimes it is terribly useful to have the entire project under the SAME unix group, this can be accomplished by setting the "sticky" information for the entire DART sandbox. In this example, I am presuming you want to change the DART project so that all the members of the group "cgddart" (which must include yourself) be allowed to peruse the project. You have to be positioned just before the DART directory for the ones that specifically reference DART.

newgrp cgddart             ;# change default group
cd DART                    ;# get to DART sandbox
cd ..                      ;# want to be above sandbox
chgrp -R cgddart DART      ;# recursively change group for entire sandbox
cd DART                    ;# get to DART sandbox
chmod g+s `find . -type d`          ;# recursively set group sticky bit for all directories

I set the group sticky bit on the repository, so everything added to the repository will inherit the repository group attributes (including ... group). To set the sticky bit in your sandbox (assuming the project already has the right attributes):

chgrp -R cgddart DART
chmod g+s `find DART -type d`

setting the sticky bit for your personal sandbox is a good thing.

The current "tag" of the project is rel-0-0 . We need to come up with a policy regarding when to "commit" a sandbox to the repository. (i.e. does it need to pass a test suite...)


Coding Standards all of which are worth beer

I can think of no reason why the CCM4 Coding Standard should not work for us. I don't want to keep making cosmetic changes to the code, so we might as well do it the same way from the start. Additionally, I prefer to
  1. Indent by three spaces
  2. separate full-line comments by a line of whitespace on each side
  3. Comment lines should be indented as though they were code.

Build

There are two methods being explored at the moment. They require a list of source code as input. Creating the custom list of source code for each particular build is "left as an exercise for the interested reader" ...

Really want to explore/use autoconf to generate the makefile and such ... after I understand the status quo "build" procedure. All in good time ...

mkmf "make makefile"

Given a file containing a list of source code filenames (mkmf_targets in the example below) and a file containing platform-specific environment customizations (e.g. mkmf.sun.devel), mkmf makes a makefile. I have mkmf installed in my /home/thoar/scripts directory, so if you add that to your CGD PATH ...

As I build on more NCAR platforms, I'll generate more platform-specific files (the BLUE argument below). At this point, I am using the following naming convention: mkmf.platform[.prod] (to differentiate between production and development compiler settings)

newgrp cgddart
cd DART/work
vi mkmf_targets                 ;# create list
mkmf -t mkmf.sun.devel mkmf_targets
make
./a.out | tee seq_obs.log

The CAM method

I am exploring Brian Eaton's perl scripts ( mkSrcfiles, and mkDepends) to facilitate the build. A (Gnu) makefile contains the logic on how to build for specific platforms and runs both scripts to build the targets and dependencies. One of the caveats is that the modules and the files containing the modules are necessarily named the same.

The mkSrcfiles utility assumes the existence of an input file ./Filepath, and writes an output file ./Srcfiles that contains the names of all the files that match the patterns *.F90, *.F, and *.c in all the directories from ./Filepath plus ./. The files are listed one per line. At this point, I need to modify the scripts to recognize .f or I need to rename all files to .F

mkDepends [-t dir] [-w] Filepath Srcfiles
optionvaluemeaning
-tdirTarget directory. If this option is set the .o files that are targets in the dependency rules have the form dir/file.o.
-w   Print warnings to STDERR about files or dependencies not found.
arguments
Filepaththe name of a file containing the directories (one per line) to be searched for dependencies.
Srcfilesthe name of a file containing the names of files (one per line) for which dependencies will be generated. Usually the result of running mkSrcfiles.
newgrp cgddart
cd DART/work
vi Filepath                   ;# create list
gmake -f Makefile.CAM
./a.out | tee seq_obs.log

Assimilation sequence

  1. model_mod
    1. init_model()
    2. get_model_size()
    3. init_conditions()
    4. adv_1step()
      1. adv_true_state(x)
    5. advance()
  2. model_output(x,time)
  3. diag_output_index(1:9)
  4. get_close_pts ... `distance'
  5. state_loc ... array of meta_data


Acronyms

Alphabet Soup   Description
CVS Concurrent Versions System
DA Data Assimilation
DAReS Data Assimilation Research Section
DART Data Assimilation Research Testbed
DODS Distributed Oceanographic Data System
EAKF Ensemble Adjustment Kalman Filter
EnKF Ensemble Kalman Filter
ESMFEarth System Modeling Framework
L96 the Lorenz 96 model
NetCDFNetwork Common Data Format
OSSE Observing System Simulation Experiment
PE Primitive Equations
RMS Root Mean Square (Error)
RMSE Root Mean Square Error
TLM Tangent Linear Model
WRF Weather Research and Forecasting Model


Related Links


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: DART core group
Revision: $Revision: 10837 $
Source: $URL: https://svn-dares-dart.cgd.ucar.edu/DART/releases/classic/doc/html/history/DART_ASP_Summer2003.html $
Change Date: $Date: 2016-12-23 13:51:05 -0700 (Fri, 23 Dec 2016) $
Change history:  try "svn log" or "svn diff"