Welcome to the Data Assimilation Research Testbed - DART

DART is a community facility for ensemble DA developed and maintained by the Data Assimilation Research Section (DAReS) at the National Center for Atmospheric Research (NCAR). DART provides modelers, observational scientists, and geophysicists with powerful, flexible DA tools that are easy to implement and use and can be customized to support efficient operational DA applications. DART is a software environment that makes it easy to explore a variety of data assimiliation methods and observations with different numerical models and is designed to facilitate the combination of assimilation algorithms, models, and real (as well as synthetic) observations to allow increased understanding of all three. DART includes extensive documentation, a comprehensive tutorial, and a variety of models and observation sets that can be used to introduce new users or graduate students to ensemble DA. DART also provides a framework for developing, testing, and distributing advances in ensemble DA to a broad community of users by removing the implementation-specific peculiarities of one-off DA systems.

DART employs a modular programming approach to apply an Ensemble Kalman Filter which nudges the underlying models toward a state that is more consistent with information from a set of observations. Models may be swapped in and out, as can different algorithms in the Ensemble Kalman Filter. The method requires running multiple instances of a model to generate an ensemble of states. A forward operator appropriate for the type of observation being assimilated is applied to each of the states to generate the model's estimate of the observation.

The DART algorithms are designed so that incorporating new models and new observation types requires minimal coding of a small set of interface routines, and does not require modification of the existing model code. Several comprehensive atmosphere and ocean general circulation models (GCMs) have been added to DART by modelers from outside of NCAR, in some cases with less than one person-month of development effort (Try that with a variational system!). Forward operators for new observation types can be created in a fashion that is nearly independent of the forecast model, many of the standard operators are available 'out of the box' and will work with no additional coding. DART has been through the crucible of many compilers and platforms. It is ready for friendly use and has been used in several field programs requiring real-time forecasting. The DART programs have been compiled with several (many?) Fortran 90 compilers and run on linux compute-servers, linux clusters, OSX laptops/desktops, SGI Altix clusters, supercomputers running AIX ... a pretty broad range, really.

The Data Assimilation Research Section (DAReS)

from left to right: Tim Hoar, Jeff Anderson, Hui Liu,
Kevin Raeder, Nancy Collins, Silvia Gentile
(David Dowell and Glen Romine are not pictured)

Our small group is comprised of experts in software design, algorithm development, large-model implementation and execution, observations and observation operators, and hardware/software portability. We have given many presentations on DART - our software facility for ensemble data assimilation, and have held several workshops for young researchers interested in DA.

DAReS Staff

• Jeff Anderson, Scientist
• Nancy Collins, Software Engineer
• David Dowell, Scientist
• Glen Romine, Scientist
• Silvia Gentile, Administrative Assistant
• Tim Hoar, Associate Scientist
• Hui Liu, Project Scientist
• Kevin Raeder, Associate Scientist

Visiting scientists/post docs and graduate research assistants:

• Ryan Torn, Postdoctoral Researcher (Aug '07 -- Aug '08) Now at SUNY Albany

Affiliates

• Chris Snyder, Scientist III, MMM
• Joe Tribbia, Senior Scientist, CGD
• Doug Nychka, Senior Scientist, IMAGe
• Josh Hacker, Scientist, RAP

Our central email address is dart@ucar.edu, which will hit 'everyone' and find its way to the best person.
The categories that follow are not set in stone, everyone has some expertise in all areas.

Shipping information:

What is Data Assimilation ... "DA"?

Loosely speaking, data assimilation is any method of making models utilize the information from observations of the system being modeled. Good assimilations make the modeled state more consistent with the observations; particularly future observations. Effective data assimilation systems tend to make forecasts more accurate - within the ability of the model, naturally - and tend to make 'hindcasts' (the model state immediately after the observations have been assimilated) more accurately reflect the state of the system.

The low-order models (Lorenz '63, '96, etc.) are a great place to start learning about data assimilation. These dynamical models were created as simple analogues to chaotic systems. Once you get comfortable running and exploring assimilations with the low-order models, you are well on your way to understanding assimilations with high-order (more realistic) models.

Schematic of Ensemble Data Assimilation - from the DAReS Perspective

This is the DART view of ensemble data assimilation for models that run as separate executables. Starting at the top and working clockwise: Everything is driven by a Fortran namelist and the presence or absence of observations. A Fortran executable named 'filter' reads a namelist, an initial state for the ensemble, and a file containing observations and goes to work. Given the observations and an initial state, 'filter' assimilates the observations and then determines how far to advance the model (using information from the namelist and the observation file). 'filter' forks a shell script to the system and it is this shell script that is responsible for three things: 1) for converting the DART state vectors and 'advance_to_time' to the format required by the underlying model, 2) advancing the model, and 3) converting the model output into a form suitable for 'filter'. [The script is responsible for the lower portion of the diagram.] The model advances each ensemble member (either in turn or all-at-once) and the model output is converted to the input format expected by 'filter'. The shell script finishes and signals 'filter' to continue. We are now back at the beginning and the cycle continues as long as there are observations to assimilate or until the control information in the Fortran namelist is met. When that happens, a set of restart files is written (suitable to continue an experiment with more observations) and diagnostic files are written. These diagnostic files allow for the exploration of the assimilation before and after each assimilation step and for exploration of the assimilation in 'observation space'; each real observation is paired with the estimates of the observation from all of the ensemble members (if desired). Minimally, the ensemble mean estimate of the observation and the ensemble spread of the estimates is recorded.

DART code distributions

DART is distributed primarily through an anonymous-access readonly Subversion (SVN) repository. This makes updates and comparisons between your sandbox and the latest, greatest version of the code trivially easy. The same cannot be said with a TAR file. If you are not familiar with SVN (the client application of subversion), you should take a stroll through my svn primer If you cannot (i.e. are firewalled out) use svn, please let me know and I'll send you a tarfile ... as a last resort.

Since the DART software is still an area of active research, there are multiple distributions, with more on the way. We'd like to be able to contact people to inform them of any bugs or updates. (This includes local users, BTW!) As you can see by the timetable of distributions, you could expect to get about 2 more emails per year, so PLEASE use a real email address when signing up. I solemnly swear to protect your email address like it is my own!

download instructions

User-Visible changes to the TRUNK (circa 2 Jun 2008)

Some ideas are just too good to postpone till the next major release. The following changes to the DART trunk code may require you to take additional action after an update:

1. Additional function added to the preprocess program also means that you now only need to have obs_def_mod.f90 in your path_names_* files and it will include the code for all other obs_def_* modules automatically. If you have additional obs_def lines for gps, altimeter, or other specialized obs_def files, they must be removed or you will get an error similar to this:
   AMBIGUOUS: Module obs_def_gps_mod is associated with ../../../obs_def/obs_def_gps_mod.f90 as well as ../../../obs_def/obs_def_mod.f90.
   Adding and removing various obs_def files now only involves changing the &preprocess_nml:input_files namelist item in the input.nml file. We will update all path_names_* files in the DART subversion (svn) repository; this only applies to files you have that are not under svn control.


2. All model work directories now have a quickbuild.csh script instead of workshop_setup.csh. The workshop script still exists in some model directories, but may change in upcoming releases to accomodate DART tutorial workshops. The quickbuild script recompiles all the programs; it does not try to run any of them. By default it builds all small models without MPI, and builds the large models (CAM, WRF, AM2) with MPI. It takes -mpi and -nompi arguments.


3. The MPI version of filter would sometimes not kill the entire job if one task failed. This resulted in jobs hanging and using up computing resources unnecessarily. We added a new routine to the utilities_mod.f90 called exit_all(). For MPI-enabled jobs it calls MPI_Abort() to inform all other tasks that one has failed. This should cause an MPI job to exit immediately on error. Nothing new happens for programs which do not use MPI. However, this change requires adding the mpi_utilities/null_mpi_utilities_mod.f90 file to many of the path_names_* files where it was not required before. It might also require adding time_manager/time_manager.f90 if it is not already there. We will update all path_names_* files in the DART subversion repository, but you may have programs of your own that use utilities_mod routines - in which case your programs will now need to link with null_mpi_utilities_mod. Without it, the error you see will be similar to this:
   /usr/bin/ld: Undefined symbols:
   _exit_all_


4. The default mpi interface utility code should now compile as-is for every supported compiler except gfortran. (You should no longer need to go into the code and edit the interface block for the system function.) If you are using the gfortran compiler, in the $DART/mpi_utilities directory you will find a script called fixsystem that you can run to make the file compile without having to edit it by hand.

Suggestions for the DART facility ...