From nancy at ucar.edu Thu Dec 5 13:40:58 2013
From: nancy at ucar.edu (nancy at ucar.edu)
Date: Thu, 05 Dec 2013 13:40:58 -0700
Subject: [Dart-dev] [6640] DART/trunk/doc/html/Kodiak_release.html: added
disclaimer line that the kodiak release notes
Message-ID:
+
+The current release of DART is named Lanai. These release notes
+are now obsolete but are being preserved for reference purposes.
+See the Lanai release notes for
+the most recent DART release information.
+
+
The DART software provides a flexible, extensible framework for conducting
data assimilation research on a wide variety of models and observations.
- In order to facilitate the incorporation of new models (which in the
- Atmospheric Science community are generally written in F90), the DART
- software is written primarily in F90. The noteable exceptions are the
- shell scripts that control execution and the Matlab® diagnostic scripts.
-
The DART system comes with many models -- ranging from 1-dimensional
Lorenz systems to full global atmospheric and ocean models.
- DART also has an extensive tutorial that explains typical DART experiments
+ DART also has extensive tutorial materials that explain typical DART experiments
and explores many aspects of ensemble data assimilation.
- The tutorial is an entire directory in the DART software distribution, so
- it can be browsed (it is a series of .pdf files)
- Download the DART source code and follow the instructions
- on the web page for the current release for
+ Download the DART source code and see the
+ release notes for
instructions on how to build an executable, run the "workshop" experiments,
- and look at the results.
+ and look at the results. The DART_LAB directory contains
+ presentation slides and interactive MATLAB demonstrations which illustrate
+ and explain the fundamentals of the ensemble data assimilation algorithms.
+ The tutorial directory contains a series of PDF files
+ which go into more mathematical detail on various ensemble data assimilation
+ topics, and specifics on the DART implementation.
+
+
+
Dart Overview
From nancy at ucar.edu Fri Dec 6 11:50:30 2013
From: nancy at ucar.edu (nancy at ucar.edu)
Date: Fri, 06 Dec 2013 11:50:30 -0700
Subject: [Dart-dev] [6648] DART/trunk/doc/html/index.shtml: update for the
Lanai release, remove obsolete items,
Message-ID: Quick Guide Topics
-
+ In order to facilitate the incorporation of new models, which in the
+ Geoscience community are frequently written in Fortran 90, the DART
+ software is written primarily in Fortran 90. Control scripts are primarily
+ in C Shell, and the distribution includes Matlab® diagnostic scripts.
+
- DART is intended to be highly portable - and has even run successfully on - Windows machines running the cygwin environment. Those instructions are under - development and so are not included in the following table. The most current - version of DART has been tested on the following: -
-hardware | -O/S | -F90 compiler | -batch manager/mpi | -
---|---|---|---|
Intel cluster/SMP/32 bit | -Red Hat Enterprise | -Intel 9.0 (build 20051201) | -none | -
Intel cluster/SMP/32 bit | -Red Hat Enterprise | -GNU Fortran 95 4.1.0 | -none | -
Intel Nocona | -SUSE | -PGI 6.0-8 | -LSF | -
Intel Nocona | -SUSE | -Intel 9.1 (EM64T) | -LSF | -
Intel iMac | -Mac OS X 10.4.6 | -gfortran 4.2.0 | -Open-MPI | -
IBM Power 5+ | -AIX 5.3 | -XLF 12.1.0 | -LSF | -
Intel | -Fedora Core 4 | -Intel 9.0 | -none | -
Macbook Pro (Intel) | -Mac OS X 10.6.8 | -Intel F90 11.1 | -OpenMPI | -
Macbook Pro (Intel) | -Mac OS X 10.6.8 | -gfortran 4.5.2 | -OpenMPI | -
PowerBook G4 (PowerPC) | -Mac OS X 10.4.8 | -Absoft Pro Fortran 9.0 | -none | -
PowerBook G4 (PowerPC) | -Mac OS X 10.3.9 | -Absoft Pro Fortran 9.0 | -Lam | -
PowerBook G4 (PowerPC) | -Mac OS X 10.3.9 | -gfortran 4.2.0 | -Lam | -
Intel cluster (Xeon) | -Fedora Core 2 | -PGI 6.0-5 | -PBS | -
Intel cluster (Xeon) | -Fedora Core 2 | -PGI 5.2-4 | -PBS | -
Intel cluster (Xeon) | -Fedora Core 2 | -Lahey 6.20c | -PBS | -
IBM cluster (of opterons) | -SUSE Enterprise 8 | -Pathscale 2.4 | -LSF | -
IBM cluster (of opterons) | -Suse Enterprise 8 | -Intel 9.1 (EM64T) | -LSF | -
IBM cluster (of opterons) | -Suse Enterprise 8 | -PGI 6.2 | -LSF | -
SGI Altix | -SUSE Linux ES 9.3 | -Intel 9.1 | -PBS | -
SGI MIPS | -IRIX 6.5 | -MIPSpro 7.4.3m | -NQS | -
Linux cluster | -Intel | -Intel 11.1 | -PBS | -
@@ -320,20 +210,31 @@
-tutorial
- subdirectory for the pdf and framemaker source for each of the 22 tutorial sections.
+ Download the DART software distribution and look in the DART_LAB
subdirectory
+ for pdf and powerpoint presentations, and MATLAB GUI point-and-click examples and
+ hands-on demonstrations. Also look in the
+ tutorial
subdirectory for pdf files for each of the 22 tutorial sections.
- The FULL list of presentations (as well as some of the + The full list of presentations (as well as some of the presentations themselves) and publications is available on our - Publications page. A short list of - presentations, posters, and seminars is offered below: -
-- We're a very small group, so the contact list is pretty short. + We're a small group, so the contact list is pretty short. Our central email contact is dart at ucar.edu. Or if you want to contact us individually, here is our information:
From nancy at ucar.edu Fri Dec 6 14:32:29 2013 From: nancy at ucar.edu (nancy at ucar.edu) Date: Fri, 06 Dec 2013 14:32:29 -0700 Subject: [Dart-dev] [6653] DART/trunk: The portion of the GITM incorporation that required Message-ID:
+ ![]() |
+
+ DART Documentation Main Index |
+
The Global Ionosphere Thermosphere Model (GITM) is a 3-dimensional spherical
+ code that models the Earth's thermosphere and ionosphere system using a
+ stretched grid in latitude and altitude. For a fuller description of using
+ GITM within DART, please see the
+ DART GITM model documentation.
+
+
+ dart_to_gitm is the program that updates the
+ GITM restart files (i.e. b?????.rst)
+ with the information from a DART output/restart file
+ (e.g. perfect_ics, filter_ics, ... ).
+
+
+ The list of variables used to create the DART state vector are specified in
+ the input.nml file.
+
+
+ Conditions required for successful execution of dart_to_gitm:
+
+The individual model instances are run in unique directories. +This is also where the converter routines +gitm_to_dart and +dart_to_gitm are run. +This makes it easy to use a single 'static' name for the input +and output filenames. +advance_model.csh is responsibile for +linking the appropriate files to these static filenames. +
+ + ++The simplest way to test the converter is to compile GITM and run a single +model state forward using work/clean.sh. +To build GITM ... download GITM and unpack the code into +DART/models/gitm/GITM2 and follow these instructions: +
++cd models/gitm/GITM2 +./Config.pl -install -compiler=ifortmpif90 -earth +make +cd ../work +./clean.sh 1 1 0 150.0 170.0 1.0 ++
And then manually run dart_to_gitm on the result. +
+We adhere to the F90 standard of starting a namelist with an ampersand +'&' and terminating with a slash '/' for all our namelist input. +Character strings that contain a '/' must be +enclosed in quotes to prevent them from prematurely terminating the namelist. +
++&dart_to_gitm_nml + dart_to_gitm_output_file = 'dart_restart', + advance_time_present = .false. + / + +&model_nml + gitm_restart_dirname = 'advance_temp_e1/UA/restartOUT', + assimilation_period_days = 0, + assimilation_period_seconds = 1800, + model_perturbation_amplitude = 0.2, + output_state_vector = .false., + calendar = 'Gregorian', + debug = 0, + gitm_state_variables = 'Temperature', 'KIND_TEMPERATURE', + 'eTemperature', 'KIND_TEMPERATURE_ELECTRON', + 'ITemperature', 'KIND_TEMPERATURE_ION', + 'iO_3P_NDensityS', 'KIND_DENSITY_NEUTRAL_O3P', + ... ++
Contents | +Type | +Description | +
---|---|---|
dart_to_gitm_output_file | +character(len=128) | +The name of the DART file containing the model state + derived from the GITM restart files. | +
advance_time_present | +logical | +If you are manually converting a DART initial conditions or + restart file this should be .false.; these files have + a single timestamp describing the valid time of the model state. + If .true., TWO timestamps are expected in the DART + file header and DART_GITM_time_control.txt) is created with + the settings appropriate to advance GITM to the time requested by DART. | +
+The full description of the model_nml namelist is documented +in the gitm model_mod, but the most important +variable for dart_to_gitm is repeated here. +
+Contents | +Type | +Description | +
---|---|---|
gitm_restart_dirname | +character(len=256) | +The name of the directory containing the + GITM restart files and runtime control information. | +
gitm_state_variables | +character(len=32), + dimension(2,80) |
+ The list of variable names in the gitm restart file to use to + create the DART state vector and their corresponding DART kind. + The default list is specified in + model_mod.nml | +
+obs_def/obs_def_upper_atm_mod.f90 +assim_model/assim_model_mod.f90 +common/types_mod.f90 +location/threed_sphere/location_mod.f90 +models/gitm/GITM2/src/ModConstants.f90 +models/gitm/GITM2/src/ModEarth.f90 +models/gitm/GITM2/src/ModKind.f90 +models/gitm/GITM2/src/ModSize.f90 +models/gitm/GITM2/src/ModTime.f90 +models/gitm/GITM2/src/time_routines.f90 +models/gitm/dart_gitm_mod.f90 +models/gitm/dart_to_gitm.f90 +models/gitm/model_mod.f90 +mpi_utilities/null_mpi_utilities_mod.f90 +obs_kind/obs_kind_mod.f90 +random_seq/random_seq_mod.f90 +time_manager/time_manager_mod.f90 +utilities/utilities_mod.f90 ++ + + + + + + + +
+none - all error messages come from modules that have their own documentation. +
+ ++none +
+ + + + + + ++None. +
+ + + + + + +
+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: | Tim Hoar |
Revision: | $Revision$ |
Source: | $URL$ |
Change Date: | $Date$ |
Change history: | try "svn log" or "svn diff" |
+ ![]() |
+
+ DART Documentation Main Index |
+
The Global Ionosphere Thermosphere Model (GITM) is a 3-dimensional spherical
+ code that models the Earth's thermosphere and ionosphere system using a
+ stretched grid in latitude and altitude. For a fuller description of using
+ GITM within DART, please see the
+ DART GITM model documentation.
+
+
+ gitm_to_dart is the program that reads
+ GITM restart files (i.e. b?????.rst)
+ and creates a DART output/restart file
+ (e.g. perfect_ics, filter_ics, ... ).
+
+
+ The list of variables used to create the DART state vector are specified in
+ the input.nml file.
+
+
+ Conditions required for successful execution of gitm_to_dart:
+
+The individual model instances are run in unique directories. +This is also where the converter routines +gitm_to_dart and +dart_to_gitm are run. +This makes it easy to use a single 'static' name for the input +and output filenames. +advance_model.csh is responsibile for +linking the appropriate files to these static filenames. +
+ + ++The simplest way to test the converter is to compile GITM and run a single +model state forward using work/clean.sh. +To build GITM ... download GITM and unpack the code into +DART/models/gitm/GITM2 and follow these instructions: +
++cd models/gitm/GITM2 +./Config.pl -install -compiler=ifortmpif90 -earth +make +cd ../work +./clean.sh 1 1 0 150.0 170.0 1.0 ++
We adhere to the F90 standard of starting a namelist with an ampersand +'&' and terminating with a slash '/' for all our namelist input. +Character strings that contain a '/' must be +enclosed in quotes to prevent them from prematurely terminating the namelist. +
++&gitm_to_dart_nml + gitm_to_dart_output_file = 'dart_ics', + / + +&model_nml + gitm_restart_dirname = 'advance_temp_e1/UA/restartOUT', + assimilation_period_days = 0, + assimilation_period_seconds = 1800, + model_perturbation_amplitude = 0.2, + output_state_vector = .false., + calendar = 'Gregorian', + debug = 0, + gitm_state_variables = 'Temperature', 'KIND_TEMPERATURE', + 'eTemperature', 'KIND_TEMPERATURE_ELECTRON', + 'ITemperature', 'KIND_TEMPERATURE_ION', + 'iO_3P_NDensityS', 'KIND_DENSITY_NEUTRAL_O3P', + ... ++
Contents | +Type | +Description | +
---|---|---|
gitm_to_dart_output_file | +character(len=128) | +The name of the DART file containing the model state + derived from the GITM restart files. | +
+The full description of the model_nml namelist is documented +in the gitm model_mod, but the most important +variable for gitm_to_dart is repeated here. +
+Contents | +Type | +Description | +
---|---|---|
gitm_restart_dirname | +character(len=256) | +The name of the directory containing the + GITM restart files and runtime control information. | +
gitm_state_variables | +character(len=32), + dimension(2,80) |
+ The list of variable names in the gitm restart file to use to + create the DART state vector and their corresponding DART kind. + The default list is specified in + model_mod.nml | +
+obs_def/obs_def_upper_atm_mod.f90 +assim_model/assim_model_mod.f90 +common/types_mod.f90 +location/threed_sphere/location_mod.f90 +models/gitm/GITM2/src/ModConstants.f90 +models/gitm/GITM2/src/ModEarth.f90 +models/gitm/GITM2/src/ModKind.f90 +models/gitm/GITM2/src/ModSize.f90 +models/gitm/GITM2/src/ModTime.f90 +models/gitm/GITM2/src/time_routines.f90 +models/gitm/dart_gitm_mod.f90 +models/gitm/gitm_to_dart.f90 +models/gitm/model_mod.f90 +mpi_utilities/null_mpi_utilities_mod.f90 +obs_kind/obs_kind_mod.f90 +random_seq/random_seq_mod.f90 +time_manager/time_manager_mod.f90 +utilities/utilities_mod.f90 ++ + + + + + + + +
+none - all error messages come from modules that have their own documentation. +
+ ++none +
+ + + + + + ++None. +
+ + + + + + +
+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: | Tim Hoar |
Revision: | $Revision$ |
Source: | $URL$ |
Change Date: | $Date$ |
Change history: | try "svn log" or "svn diff" |
The MPAS ATM interface for - Data Assimilation Research Testbed (DART) is under development. +
This document describes the DART interface module for +the MPAS-Atmosphere (or briefly, MPAS-ATM) global model, +which uses an unstructured Voronoi grid mesh, formally Spherical Centriodal Voronoi +Tesselations (SCVTs). This allows for both quasi-uniform discretization of the sphere and +local refinement. The MPAS/DART interface was built on the SCVT-dual mesh and does not +regrid to regular lat/lon grids. In the C-grid discretization, the normal component of +velocity on cell edges is prognosed; zonal and meridional wind components are diagnosed +on the cell centers. We provide several options to choose from in the assimilation +of wind observations as shown below.
-- Since MPAS ATM uses netcdf files for their restart mechanism, - a namelist-controlled set of variables is used to build the DART state vector. - Each variable must also correspond to a DART "KIND"; required for the DART - interpolate routines. For example: +The grid terminology used in MPAS is as shown in the figure below:
-&mpas_vars_nml - mpas_state_variables = 'uReconstructZonal', 'KIND_U_WIND_COMPONENT', - 'uReconstructMeridional', 'KIND_V_WIND_COMPONENT', - 'w', 'KIND_VERTICAL_VELOCITY', - 'theta', 'KIND_POTENTIAL_TEMPERATURE', - 'qv', 'KIND_VAPOR_MIXING_RATIO', - 'qc', 'KIND_CLOUDWATER_MIXING_RATIO', - 'qr', 'KIND_RAINWATER_MIXING_RATIO', - 'qi', 'KIND_ICE_MIXING_RATIO', - 'qs', 'KIND_SNOW_MIXING_RATIO', - 'qg', 'KIND_GRAUPEL_MIXING_RATIO', - 'surface_pressure', 'KIND_SURFACE_PRESSURE' - / ++
+The wind options during a DART assimilation +are controlled by combinations of 4 different namelist options. +The options control how the forward operators compute expected observation values; +how the horizontal interpolation is computed; and how the assimilation increments +are applied to update the wind quantities in the state vector. Preliminary +experimental results indicate that using the zonal and meridional winds +for the forward operator fields and using Barycentric interpolation leads +to the smoothest estimates of wind quantities, and using increments to update +the u field gives the least noisy increments. However there remains +scientific questions about how best to handle the wind fields under different +situations. Thus we have kept all implemented options available for use in +experimental comparisons. See the figure below for a flow-chart representation +of how the 4 namelist items interact: +
++
+Cycling of MPAS/DART is run in a restart mode. +As for all DART experiments, the overall design for an experiment is this: +the DART program filter will read the initial +condition file, the observation sequence file, and the DART namelist +to decide whether or not to advance the MPAS-ATM model. All of the +control of the execution of the MPAS model is done by DART directly. +If the model needs to be advanced, filter makes +a call to the shell to execute the script +advance_model.csh, +which is ENTIRELY responsible +for getting all the input files, data files, namelists, etc. into +a temporary directory, running the model, and copying the results +back to the parent directory (which we call CENTRALDIR). +The whole process hinges on setting the MPAS-ATM model namelist values +such that it is doing a restart for every model advance. +Unlike MPAS-ATM free forecast runs, the forecast step in MPAS/DART requires to +set up one more namelist parameter called "config_do_DAcycling = .true." in &restart section +of namelist.input to recouple the state vectors (updated by filter) with the mass field for the restart mode. +For more information, check the advance_model.csh script.
++ +Since DART is an ensemble algorithm, there are multiple analysis files for a single analysis time: +one for each ensemble member. Because MPAS/DART is run in a restart mode, each member should keep its own +MPAS restart file from the previous cycle (rather than having a single template file in CENTRALDIR). +Creating the initial ensemble of states is an area of active research. + + + + + + +
[top]
+NAMELIST
++This namelist is read from the file input.nml. +Namelists start with an ampersand +'&' and terminate with a slash '/'. +Character strings that contain a '/' must be +enclosed in quotes to prevent them from +prematurely terminating the namelist. +
+ ++-+&model_nml + model_analysis_filename = 'mpas_init.nc', + grid_definition_filename = 'mpas_init.nc', + output_state_vector = .false., + vert_localization_coord = 3, + assimilation_period_days = 0, + assimilation_period_seconds = 21600, + model_perturbation_amplitude = 0.0001, + log_p_vert_interp = .true., + calendar = 'Gregorian', + use_u_for_wind = .false., + use_rbf_option = 2, + update_u_from_reconstruct = .true., + use_increments_for_u_update = .true., + highest_obs_pressure_mb = 100.0, + sfc_elev_max_diff = -1.0, + debug = 0, +/+These variables are then adjusted to be consistent with observations and - stuffed back into the same netCDF analysis files. Since DART is an ensemble - algorithm, there are multiple analysis files for a single analysis time: - one for each ensemble member. Creating the initial ensemble of states is an - area of active research. -
-
- DART reads grid information from the MPAS ATM 'history' file, I have tried to keep - the variable names the same. Internal to the DART code, the following variables exist: +
+
+ +++ ++ +
++ + + + Item +Type +Description + + model_analysis_filename +character(len=256) +
+ [default: 'mpas_init.nc']The name of the MPAS analysis file to be read and/or written + by the DART programs for the state data. ++ + grid_definition_filename +character(len=256) +
+ [default: 'mpas_init.nc']The name of the MPAS file to be read + by the DART programs for the grid information. Generally + this is the same as the model_analysis_filename. + However, the grid information is large and if the grid is static + that information could be omitted from the analysis files to + save space. A single grid file could be supplied once and + not change during the assimilation run. ++ + highest_obs_pressure_mb +real(r8) +
+ [default: 100.0]Observations higher than this pressure are ignored. Set to -1.0 + to ignore this test. For models with a prescribed top boundary + layer, trying to assimilate very high observations results in + problems because the model damps out any changes the assimilation + tries to make. With adaptive algorithms this results in larger + and larger coefficients as the assimilation tries to effect state + vector change. + ++ + output_state_vector +logical [default: .false.] +The switch to determine the form of the state vector in the + output netCDF files. If .true. + the state vector will be output exactly as DART uses it; + as one long array. If .false., + the state vector is parsed into prognostic variables and + output that way -- much easier to use with 'ncview', for + example. [Recommended] ++ + assimilation_period_days +integer [default: 0] +The number of days to advance the model for each assimilation. + Even if the model is being advanced outside of the DART filter + program, the assimilation period should be set correctly. + Only observations with a time within +/- 1/2 this window size + will be assimilated. + ++ + assimilation_period_seconds +integer [default: 21600] +In addition to assimilation_period_days, + the number of seconds to advance the model for each assimilation. ++ + vert_localization_coord +integer [default: 3] +Vertical coordinate for vertical localization. + ++
- 1 = model level
+- 2 = pressure (in pascals)
+- 3 = height (in meters)
+- 4 = scale height (unitless)
++ + sfc_elev_max_diff +real(r8)[default: -1.0] +If > 0, the maximum difference, in meters, between an observation marked + as a 'surface obs' as the vertical type (with the surface elevation, in + meters, as the numerical vertical location), and the surface elevation as + defined by the model. Observations further away from the surface than this + threshold are rejected and not assimilated. If the value is negative, this + test is skipped. ++ + log_p_vert_interp +logical [default: .true.] +If .true., vertical interpolation is done in log-pressure. Otherwise, linear. ++ + use_u_for_wind +logical [default: .false.] +If .false., zonal and meridional winds at cell centers are used for + the wind observation operator [default]. In that case, triangular meshes are used for the + barycentric (e.g., area-weighted) interpolation. If .true., wind vectors at an arbitrary + (e.g., observation) point are reconstructed from the normal component of velocity on cell edges + (u) using radial basis functions (RBFs) provided by the MPAS model. ++ + use_rbf_option +integer [default: 2] +If use_u_for_wind is .true., this option controls + how many points will be used in the RBF interpolation. Options are available as 1, 2, and 3. + All the edges available in N (= 1,2, or 3) cells go into the RBF reconstruction. ++ + update_u_from_reconstruct +logical [default: .true.] +When zonal and meridional winds at cell centers are used for + the wind observation operator (use_u_for_wind = .false.), + this option decides if the normal component of velocity on cell edges (which is + the only wind prognostic variable in MPAS-ATM) should be updated from the winds at cell centers. + If .true., use_increments_for_u_update should be also decided. + If use_u_for_wind = .true. and the normal component of velocity on cell + edges is defined as a state vector, this option should be .false. so the edge winds can be + directly updated by filter. ++ + use_increments_for_u_update +logical [default: .true.] +Only if update_u_from_reconstruct is .true., this option is + used to decide if the edge winds are replaced by averaging from the analysis + winds at cell centers (.false.), or just updated by the analysis increments + at cell centers (.true.). If .true., all the wind components (e.g., both at + cell centers and edges) are read from prior and used to compute the + increments [Recommended]. ++ + model_perturbation_amplitude +real(r8) [default: 0.0001] +The amplitude of random noise to add when trying to perturb a single + state vector to create an ensemble. Only used when + input.nml::&filter_nml:start_from_restart = .false. + + Multiplied by the state vector, it produces standard deviation + of a gaussian distribution with the mean at the value of the state vector element. ++ + calendar +character(len=32) +
+ [default: 'Gregorian']Character string specifying the calendar being used by MPAS. ++ + + debug +integer [default: 0] +The switch to specify the run-time verbosity. + 0 is as quiet as it gets. + > 1 provides more run-time messages. + > 5 provides ALL run-time messages. + +
+
+ + + + ++This namelist contains the list of MPAS variables that make up the DART state vector. +The order the items are specified controls the order of the data in the +state vector, so it should not be changed without regenerating any +DART initial condition or restart files. +These variables are directly updated by the assimilation in filter. +Any variables whose values cannot exceed a given +minimum or maximum can be listed in mpas_state_bounds, +and when the data is converted back into the MPAS NetCDF files, values +outside the allowed range will be detected. Data inside the DART +state vector and data written to the diagnostic files +may exceed the allowed limits.
+++ ++&mpas_vars_nml + mpas_state_variables = 'theta', 'KIND_POTENTIAL_TEMPERATURE', + 'uReconstructZonal', 'KIND_U_WIND_COMPONENT', + 'uReconstructMeridional','KIND_V_WIND_COMPONENT', + 'qv', 'KIND_VAPOR_MIXING_RATIO', + 'qc', 'KIND_CLOUDWATER_MIXING_RATIO', + 'surface_pressure', 'KIND_SURFACE_PRESSURE' + mpas_state_bounds = 'qv','0.0','NULL','CLAMP', + 'qc','0.0','NULL','CLAMP', +/ ++
+
+ +++ ++ +
++ + + + + Item +Type +Description + + mpas_vars_nml +character(len=NF90_MAX_NAME)::
+ dimension(160) +The table that relates the MPAS-ATM variables + to use to build the DART state vector, and the corresponding + DART kinds for those variables. The first column in each pair must + be the NetCDF name of a field in the MPAS file. The second column + in each pair must be a KIND known to the DART system. See the + obs_kind/obs_kind_mod.f90 file for known names. + These must be generic kinds, not specific types. + ++ + + mpas_state_bounds +character(len=NF90_MAX_NAME)::
+ dimension(160) +MPAS-ATM variables that need to set up lower and upper bound values. + Columns are a variable name, min, max values, and 'CLAMP' or 'FAIL' in case + the field goes beyond the bounds. If the bound values have 'NULL', + the actual data range is used. +
+
+ + + + +[top]
+Grid information
+As the forward operators use the unstructured grid meshes in MPAS-ATM, the DART/MPAS interface needs to read static + variables related to the grid structure from the MPAS ATM 'history' file (specified in + model_analysis_filename). + These variables are used to find the closest cell to an observation + point in the cartesian coordinate (to avoid the polar issues). +
+
integer :: nCells | the number of Cell Centers |
integer :: nEdges | the number of Cell Edges |
integer :: nVertices | the number of Cell Vertices |
integer :: nVertLevels | the number of vertical level midpoints |
integer :: nVertLevelsP1 | the number of vertical level edges |
integer :: nSoilLevels | the number of soil level ?midpoints? |
real(r8) :: latCell(:) | the latitudes of the Cell Centers (-90,90) |
real(r8) :: lonCell(:) | the longitudes of the Cell Centers [0, 360) |
real(r8) :: zgrid(:,:) | cell center geometric height at cell centers (ncells,nvert) |
integer :: nCells | the number of cell centers |
integer :: nEdges | the number of cell edges |
integer :: nVertices | the number of cell vertices |
integer :: nVertLevels | the number of vertical levels for mass fields |
integer :: nVertLevelsP1 | the number of vertical levels for vertical velocity |
integer :: nSoilLevels | the number of soil levels |
real(r8) :: latCell(:) | the latitudes of the cell centers [-90,90] |
real(r8) :: lonCell(:) | the longitudes of the cell centers [0, 360] |
real(r8) :: latEdge(:) | the latitudes of the edges [-90,90], if edge winds are used. |
real(r8) :: lonEdge(:) | the longitudes of the edges [0, 360], if edge winds are used. |
real(r8) :: xVertex(:) | The cartesian location in x-axis of the vertex |
real(r8) :: yVertex(:) | The cartesian location in y-axis of the vertex |
real(r8) :: zVertex(:) | The cartesian location in z-axis of the vertex |
real(r8) :: xEdge(:) | The cartesian location in x-axis of the edge, if edge winds are used. |
real(r8) :: yEdge(:) | The cartesian location in y-axis of the edge, if edge winds are used. |
real(r8) :: zEdge(:) | The cartesian location in z-axis of the edge, if edge winds are used. |
real(r8) :: zgrid(:,:) | geometric height at cell centers (nCells, nVertLevelsP1) |
integer :: CellsOnVertex(:,:) | list of cell centers defining a triangle |
integer :: edgesOnCell(:,:) | list of edges on each cell |
integer :: verticesOnCell(:,:) | list of vertices on each cell |
integer :: edgeNormalVectors(:,:) | unit direction vectors on the edges (only used if use_u_for_wind = .true.) |
- input.nml&mpas_vars_nml
+ input.nml :: &mpas_vars_nml
defines the list of MPAS variables used to build the DART state vector.
Combined with an MPAS analysis file, the information is used to
determine the size of the DART state vector and derive the metadata.
@@ -109,17 +437,19 @@
character(len=NF90_MAX_NAME), dimension(NF90_MAX_VAR_DIMS) :: dimname
integer, dimension(NF90_MAX_VAR_DIMS) :: dimlens
integer :: xtype ! netCDF variable type (NF90_double, etc.)
- integer :: numdims ! number of dims - excluding TIME
+ integer :: numdims ! number of dimensions - excluding TIME
integer :: numvertical ! number of vertical levels in variable
- integer :: numcells ! number of horizontal locations (typically cell centers)
- logical :: ZonHalf ! vertical coordinate has dimension nVertLevels
- integer :: varsize ! prod(dimlens(1:numdims))
+ integer :: numcells ! number of cell locations (typically cell centers)
+ integer :: numedges ! number of edge locations (edges for normal velocity)
+ logical :: ZonHalf ! vertical coordinate for mass fields (nVertLevels)
+ integer :: varsize ! variable size (dimlens(1:numdims))
integer :: index1 ! location in dart state vector of first occurrence
integer :: indexN ! location in dart state vector of last occurrence
integer :: dart_kind
character(len=paramname_length) :: kind_string
logical :: clamping ! does variable need to be range-restricted before
- real(r8) :: range(2) ! being stuffed back into MPAS analysis file.
+ real(r8) :: range(2) ! lower and upper bounds for the data range.
+ logical :: out_of_range_fail ! is out of range fatal if range-checking?
end type progvartype
type(progvartype), dimension(max_state_variables) :: progvar
@@ -134,28 +464,36 @@
x(nVertical,nHorizontal,nVariables). The fastest-varying dimension is vertical,
then horizontal, then variable ... naturally, the DART state vector is 1D.
Each variable is also stored this way in the MPAS analysis file.
+
- was compiled with the gfortran 4.2.3 compilers and run on a Mac.
-
-
- The DART components were built with the following mkmf.template settings:
-
- FC = gfortran - LD = gfortran - NETCDF = /Users/thoar/GNU - INCS = -I${NETCDF}/include - LIBS = -L${NETCDF}/lib -lnetcdf -lcurl -lhdf5_hl -lhdf5 -lz -lm - FFLAGS = -O0 -fbounds-check -frecord-marker=4 -ffpe-trap=invalid $(INCS) - LDFLAGS = $(FFLAGS) $(LIBS) --
+The DART interface for MPAS-ATM can be compiled with various fortran compilers such as (but not limited to) +gfortran, pgf90, and intel. It has been tested on a Mac and NCAR IBM supercomputer (yellowstone). +
+ ++NOTE: While MPAS requires the PIO (Parallel IO) and pNetCDF +(Parallel NetCDF) libraries, DART uses only the plain NetCDF libraries. +If an altered NetCDF library is required by the parallel versions, there may +be incompatibilities between the run-time requirements of DART and MPAS. +Static linking of one or the other executable, or swapping of modules +between executions may be necessary. +
+ +is relatively straightforward. Given the namelist mechanism for @@ -173,7 +511,7 @@
model_to_dart.f90 | -converts an MPAS analysis file (nominally named mpas_analysis.nc) into a + | converts an MPAS analysis file (nominally named mpas_init.nc) into a DART-compatible file normally called dart_ics . We usually wind up linking the actual analysis file to a static name that is used by DART. | @@ -188,7 +526,7 @@ dart_to_model updates the MPAS analysis file specified in input.nmlmodel_nml:model_analysis_filename. If the DART file contains an 'advance_to' time, separate control information is written - to an auxiliary file that is used by the advance_model.csh script. + to an auxiliary file (named 'mpas_time') that is used by the advance_model.csh script.
366 mirage2:thoar% ncdump -h mpas_analysis.nc +366 mirage2:thoar% ncdump -h mpas_init.nc netcdf mpas_analysis { dimensions: StrLen = 64 ; Time = UNLIMITED ; // (1 currently) - nCells = 10242 ; available in DART - nEdges = 30720 ; available in DART + nCells = 10242 ; available in DART + nEdges = 30720 ; available in DART maxEdges = 10 ; maxEdges2 = 20 ; - nVertices = 20480 ; available in DART + nVertices = 20480 ; available in DART TWO = 2 ; THREE = 3 ; - vertexDegree = 3 ; available in DART + vertexDegree = 3 ; FIFTEEN = 15 ; TWENTYONE = 21 ; R3 = 3 ; - nVertLevels = 41 ; available in DART - nVertLevelsP1 = 42 ; available in DART + nVertLevels = 41 ; available in DART + nVertLevelsP1 = 42 ; available in DART nMonths = 12 ; nVertLevelsP2 = 43 ; - nSoilLevels = 4 ; available in DART + nSoilLevels = 4 ; available in DART variables: - char xtime(Time, StrLen) ; available in DART - double latCell(nCells) ; available in DART - double lonCell(nCells) ; available in DART - double latEdge(nEdges) ; - double lonEdge(nEdges) ; + char xtime(Time, StrLen) ; available in DART + double latCell(nCells) ; available in DART + double lonCell(nCells) ; available in DART + double latEdge(nEdges) ; available in DART + double lonEdge(nEdges) ; available in DART int indexToEdgeID(nEdges) ; double latVertex(nVertices) ; double lonVertex(nVertices) ; + double xVertex(nVertices) ; available in DART + double yVertex(nVertices) ; available in DART + double zVertex(nVertices) ; available in DART + double xEdge(nVertices) ; available in DART + double yEdge(nVertices) ; available in DART + double zEdge(nVertices) ; available in DART int indexToVertexID(nVertices) ; int cellsOnEdge(nEdges, TWO) ; int nEdgesOnCell(nCells) ; int nEdgesOnEdge(nEdges) ; - int edgesOnCell(nCells, maxEdges) ; + int edgesOnCell(nCells, maxEdges) ; available in DART int edgesOnEdge(nEdges, maxEdges2) ; double weightsOnEdge(nEdges, maxEdges2) ; double dvEdge(nEdges) ; double dcEdge(nEdges) ; double angleEdge(nEdges) ; - double edgeNormalVectors(nEdges, R3) ; + double edgeNormalVectors(nEdges, R3) ; available in DART double cellTangentPlane(nEdges, TWO, R3) ; int cellsOnCell(nCells, maxEdges) ; - int verticesOnCell(nCells, maxEdges) ; + int verticesOnCell(nCells, maxEdges) ; available in DART int verticesOnEdge(nEdges, TWO) ; int edgesOnVertex(nVertices, vertexDegree) ; - int cellsOnVertex(nVertices, vertexDegree) ; available in DART + int cellsOnVertex(nVertices, vertexDegree) ; available in DART double kiteAreasOnVertex(nVertices, vertexDegree) ; double rainc(Time, nCells) ; double cuprec(Time, nCells) ; @@ -327,182 +671,7 @@
We adhere to the F90 standard of starting a namelist with an ampersand -'&' and terminating with a slash '/' for all our namelist input. -Consider yourself forewarned that character strings that contain a '/' must be -enclosed in quotes to prevent them from prematurely terminating the namelist. -
--namelist /model_nml/ model_analysis_filename, & - assimilation_period_days, assimilation_period_seconds, & - model_perturbation_amplitude, output_state_vector, calendar, debug --
This namelist is read in a file called input.nml. - This namelist provides control over the assimilation period for the model. - All observations within (+/-) half of the assimilation period are assimilated. - The assimilation period is the minimum amount of time the model can be advanced, - and checks are performed to ensure that the assimilation window is a multiple of - the model dynamical timestep. This also specifies the MPAS analysis file that will - be read and/or written by the different program units. -
- -Contents | -Type | -Description |
---|---|---|
model_analysis_filename | -character(len=256) - [default: 'mpas_analysis.nc'] |
- Character string specifying the name of the MPAS analysis - file to be read and/or written by the different program units. |
output_state_vector | -logical [default: .true.] | -The switch to determine the form of the state vector in the - output netCDF files. If .true. - the state vector will be output exactly as DART uses it - ... one long array. If .false., - the state vector is parsed into prognostic variables and - output that way -- much easier to use with 'ncview', for - example. |
assimilation_period_days | -integer [default: 1] | -The number of days to advance the model for each assimilation. - |
assimilation_period_seconds | -integer [default: 0] | -In addition to assimilation_period_days, - the number of seconds to advance the model for each assimilation. - |
model_perturbation_amplitude | -real(r8) [default: 0.2] | -Reserved for future use. - |
calendar | -character(len=32) - [default: 'Gregorian'] |
- - Character string specifying the calendar being used by MPAS. |
debug | -integer [default: 0] | -The switch to specify the run-time verbosity. - 0 is as quiet as it gets. - > 1 provides more run-time messages. - > 5 provides ALL run-time messages. - |
-&model_nml - model_analysis_filename = 'mpas_restart.nc'; - assimilation_period_days = 0, - assimilation_period_seconds = 60, - model_perturbation_amplitude = 0.2, - output_state_vector = .true., - calendar = 'Gregorian', - debug = 0 - / -- -
-namelist /mpas_vars_nml/ mpas_state_variables --
@@ Diff output truncated at 40000 characters. @@
From nancy at ucar.edu Wed Dec 11 08:36:50 2013
From: nancy at ucar.edu (nancy at ucar.edu)
Date: Wed, 11 Dec 2013 08:36:50 -0700
Subject: [Dart-dev] [6668] DART/trunk/models/mpas_atm/model_mod.html: a few
addition changes suggested by soyoung, a typo fix,
Message-ID:
The wind options during a DART assimilation
-are controlled by combinations of 4 different namelist options.
-The options control how the forward operators compute expected observation values;
-how the horizontal interpolation is computed; and how the assimilation increments
-are applied to update the wind quantities in the state vector. Preliminary
-experimental results indicate that using the zonal and meridional winds
-for the forward operator fields and using Barycentric interpolation leads
-to the smoothest estimates of wind quantities, and using increments to update
-the u field gives the least noisy increments. However there remains
+are controlled by combinations of 4 different namelist values.
+The values determine which fields the forward operator uses to compute expected
+observation values; how the horizontal interpolation is computed in that
+forward operator; and how the assimilation increments
+are applied to update the wind quantities in the state vector.
+Preliminary results based on real data assimilation experiments indicate that
+performance is better when the zonal and meridional winds are used as
+input to the forward operator that uses Barycentric interpolation, and when the
+prognostic u wind is updated by the incremental method described in
+the figure below.
+However there remain
scientific questions about how best to handle the wind fields under different
situations. Thus we have kept all implemented options available for use in
experimental comparisons. See the figure below for a flow-chart representation
@@ -305,17 +308,27 @@
-This namelist contains the list of MPAS variables that make up the DART state vector.
+The &mpas_vars_nml namelist contains the list
+of MPAS variables that make up the DART state vector.
The order the items are specified controls the order of the data in the
-state vector, so it should not be changed without regenerating any
+state vector, so it should not be changed without regenerating all
DART initial condition or restart files.
-These variables are directly updated by the assimilation in filter.
+These variables are directly updated by the filter assimilation.
+
Any variables whose values cannot exceed a given
-minimum or maximum can be listed in mpas_state_bounds,
-and when the data is converted back into the MPAS NetCDF files, values
-outside the allowed range will be detected. Data inside the DART
-state vector and data written to the diagnostic files
-may exceed the allowed limits.
+minimum or maximum can be listed in mpas_state_bounds.
+When the data is written back into the MPAS NetCDF files values
+outside the allowed range will be detected and changed.
+Data inside the DART state vector and data written to
+the DART diagnostic files will not go through this test and
+values may exceed the allowed limits.
+Note that changing values at the edges of the distribution
+means it is no longer completely gaussian. In practice
+this technique has worked effectively, but if the assimilation
+is continually trying to move the values outside the permitted
+range the results may be of poor quality. Examine the diagnostics for
+these fields carefully when using bounds to restrict their values.
mpas_vars_nml
character(len=NF90_MAX_NAME)::
dimension(160)
- The table that relates the MPAS-ATM variables
- to use to build the DART state vector, and the corresponding
- DART kinds for those variables. The first column in each pair must
- be the NetCDF name of a field in the MPAS file. The second column
- in each pair must be a KIND known to the DART system. See the
- obs_kind/obs_kind_mod.f90 file for known names.
- These must be generic kinds, not specific types.
+ The table that both specifies which MPAS-ATM variables will be
+ placed in the state vector, and also relates those variables
+ to the corresponding DART kinds. The first column in each pair must
+ be the exact NetCDF name of a field in the MPAS file. The second column
+ in each pair must be a KIND known to the DART system. See
+ obs_kind/obs_kind_mod.f90 for known names.
+ This file is autogenerated when DART builds filter for a particular
+ model, so run quickbuild.csh in the work directory
+ first before examining this file. Use the generic kind list in
+ the obs_kind_mod tables, not the specific type list.
mpas_state_bounds
character(len=NF90_MAX_NAME)::
dimension(160)
- MPAS-ATM variables that need to set up lower and upper bound values.
- Columns are a variable name, min, max values, and 'CLAMP' or 'FAIL' in case
- the field goes beyond the bounds. If the bound values have 'NULL',
- the actual data range is used.
+ List only MPAS-ATM variables that must restrict their values to remain
+ between given lower and/or upper bounds.
+ Columns are: NetCDF variable name, min value, max value, and action to take
+ for out-of-range values. Either min or max can have the string 'NULL' to indicate
+ no limiting will be done. If the action is 'CLAMP' out of range values will be
+ changed to the corresponding bound and execution continues;
+ 'FAIL' stops the executable if out of range values are detected.
Anything underlined is a URL.
-All filenames look like this -- (typewriter font, green).
-Program names look like this -- (italicized font, green).
-user input looks like this -- (bold, magenta).
-
-And the contents of a file are enclosed in a box with a border: -
-$Id$
- -The Data Assimilation Research Testbed (DART) is designed to -facilitate the combination of assimilation algorithms, models, -and observation sets to allow increased understanding of all three. -(an -in-depth design discussion) -For the -ASP colloquium -on Data Assimilation, a subset of the complete DART facility was -used to examine ensemble filter assimilation algorithms using -synthetic observations. -The DART programs were compiled with the Intel 7.1 Fortran compiler -and run on a linux compute-server while analysis was performed with -Matlab on a DEC workstation. If your system is different, you will -definitely need to read the -Customizations section. -
- -DART programs can require three different types of input. -First, some of the DART programs, those for creating synthetic -observational datasets, require interactive input from the keyboard. -For simple cases, this interactive input can be made directly -from the keyboard. In more complicated cases, a file containing -the appropriate keyboard input can be created and this file -can be directed to the standard input of the DART program. -Second, many DART programs expect one or more input files in -DART specific formats to be available. For instance, -perfect_model_obs creates a synthetic -observation set given a particular model and a description -of a sequence of observations requires an input file that -describes this observation sequence. -At present, all DART-specific input files are inefficient but -human-readable ascii files. Third, many DART -modules (including main programs) make use of the Fortan90 -namelist facility to obtain values of certain parameters -at run-time. All programs look for a namelist input file -called input.nml in the directory in which -the program is executed. The input.nml -file can contain a sequence of individual Fortran90 namelists -which specify values of particular parameters for modules that -compose the executable program. -Unfortunately, the Fortran90 namelist interface -is poorly defined in the language standard, leaving -considerable leeway to compiler developers in implementing the -facility. The Intel 7.1 compiler has some particularly unpleasant -behavior when a namelist file contains an entry that is NOT defined -in the program reading the namelist. -Error behavior is unpredictable, but often results in read -errors for other input files opened by DART programs. -If you encounter run-time read errors, the first course of action -should be to ensure the components of the namelist are actual components. -Changing the names of the namelist components will -create unpleasantries. -
- --DART uses the -netCDF -self-describing data format with a particular metadata convention to -describe output that is used to analyze the results of assimilation -experiments. These files have the extension .nc -and can be read by a number of standard data analysis tools. -Three sets of tools are available to work with netCDF files for the ASP -colloquium. First, the simple tool ncview is -provided to do rudimentary graphical display of slices of output -data fields. -ncview -will be of most use for output of the more comprehensive models at -the end of the exercise set. Second, a set of tools called the -NCO tools, produced by -UCAR's Unidata group, are aailable to do operations like -concatenating, slicing, and dicing of netCDF files. -Finally, a set of Matlab -scripts, designed to produce graphical diagnostics from DART netCDF -output files are available. -
- --This document outlines the installation of the DART software -and the system requirements. For convenience, some of the original -colloquium exercises are repeated here, mostly just to check the -installation. The entire installation process is summarized in -the following steps: -
- --We have tried to make the code as portable as possible, but we -do not have access to all compilers on all platforms, so there are no -guarantees. We are interested in your experience building the system, -so please email me (Tim Hoar) at thoar @ ucar . edu -
- --After the installation, you might want to peruse the following. -
- --The DART software has been successfully built on several Linux/x86 -platforms with the -Intel Fortran -Compiler 7.1 for Linux, which is free for individual scientific use. -It has also been built and successfully run with the -Portland Group Fortran Compiler. -Since recompiling the code is a necessity to experiment -with different models, there are no binaries to distribute. -
- - - - --DART uses the -netCDF -self-describing data format for the results of assimilation -experiments. These files have the extension .nc -and can be read by a number of standard data analysis tools. -In particular, DART also makes use of the F90 interface to the library -which are available through the netcdf.mod and -typesizes.mod modules. -IMPORTANT: different compilers create these modules with -different "case" filenames, and sometimes they are not both -installed into the expected directory. It is required that both modules -be present. The normal place would be in the netcdf/include -directory, as opposed to the netcdf/lib directory. -
- --If the netCDF library does not exist on your system, you must build -it (as well as the F90 interface modules). The library and instructions -for building the library or installing from an RPM may be found at -the netCDF home page: - -http://www.unidata.ucar.edu/packages/netcdf/ -Pay particular attention to the compiler-specific patches that must -be applied for the Intel Fortran Compiler. (Or the PG compiler, for -that matter.) -
- --The location of the netCDF library, libnetcdf.a, -and the locations of both netcdf.mod and -typesizes.mod will be needed by the makefile -template, as described in the compiling -section. -
- - - - -DART also uses the very common - -udunits library for manipulating units of physical quantities. If, -somehow, it is not installed on your system, you will need to install -it (instructions are available from -Unidata's Downloads page). -
- --The location of the udunits library, libudunits.a, -will be needed by the makefile template, as described in the -compiling section. -
- - - - --The DART source code is distributed as a compressed tar file. -DART_ASP_SUMMER_2003.tar.gz -[8307414 bytes]. When untarred, the source tree will begin with a -directory named DART and will be approximately -23.5Mb. Compiling the code in this tree (as is usually the case) will -necessitate much more space. -
- --The code tree is very "bushy"; there are many directories of support -routines, etc. but only a few directories involved with the -customization and installation of the DART software. If you can -compile and run ONE of the low-order models, you should be able to -compile and run ANY of the low-order models. For this reason, -we can focus on the Lorenz `63 model. Subsequently, the only -directories with files to be modified to check the installation -are: - DART/mkmf, - DART/models/lorenz_63/work, and - DART/matlab (but only for analysis). -
- - - - --DART executable programs are constructed using two tools: -make and -mkmf. -The make utility is a relatively common -piece of software that requires a user-defined input file that records -dependencies between different source files. make -then performs a hierarchy of actions when one or more of the -source files is modified. The mkmf utility is -a custom preprocessor that generates -a make input file -(named Makefile) and is designed specifically to work -with object-oriented Fortran90 (and other languages) for systems like -DART. -
- --mkmf requires two separate input files. -The first is a `template' file which specifies details of the commands -required for a specific Fortran90 compiler and may also contain -pointers to directories containing pre-compiled utilities required by -the DART system. This template file will need to -be modified to reflect your system. The second input file is a -`path_names' file which includes a complete list of the locations -(either relative or absolute) of all Fortran90 source files that are -required to produce a particular DART program. -Each 'path_names' file must contain a path for -exactly one Fortran90 file containing a main program, -but may contain any number of additional paths pointing to files -containing Fortran90 modules. -An mkmf command is executed which -uses the 'path_names' file and the mkmf template file to produce a -Makefile which is subsequently used by the -standard make utility. -
- --Shell scripts that execute the mkmf command for all standard -DART executables are provided as part of the standard DART software. -For more information on mkmf see -the FMS mkmf description -
- - --A series of templates for different compilers/architectures exists -in the DART/mkmf/ directory and have names with -extensions that identify either the compiler, the architecture, or both. -This is how you inform the build process of the specifics of your system. -For the discussion that follows, knowledge of the contents of one of these -templates (i.e. mkmf.template.pgi) is needed: -(note that only the first few lines are shown here) -
- --Essentially, each of the lines defines some part of the resulting -Makefile. Since make -is particularly good at sorting out dependencies, the order of these -lines really doesn't make any difference. -The FC = pgf90 line ultimately defines the -Fortran90 compiler to use, etc. -The lines which are most likely to need site-specific changes -start with FFLAGS and LIBS, which -indicate where to look for the netCDF F90 modules and the -location of the netCDF and udunits libraries. -
- - --Each compiler has different compile flags, so there is really no way -to exhaustively cover this other than to say the templates as we supply -them should work -- depending on the location of the netCDF modules -netcdf.mod and -typesizes.mod. -Change the /usr/local/netcdf/include string to -reflect the location of your modules. -The low-order models can be compiled without the -r8 -switch, but the bgrid_solo model cannot. -
- - -
-Modifying the LIBS value should be relatively
-straightforward.
-Change the /usr/local/netcdf/lib string to
-reflect the location of your libnetcdf.a.
-Change the /usr/local/udunits-1.11.7/lib string to
-reflect the location of your libudunits.a.
-
-Several path_name_* files are provided in -the work directory for each specific model, -in this case: DART/models/lorenz_63/work. -
- --Since each model comes with its own set of files, no customization is -needed. -
- - - - -Currently, DART executables are constructed in a work -subdirectory under the directory containing code for the given model. -In the top-level DART directory, change to the L63 work -directory and list the contents: -
- -filter_ics -input.nml -mkmf_create_obs_sequence -mkmf_create_obs_set_def -mkmf_filter -mkmf_perfect_model_obs -path_names_create_obs_sequence -path_names_create_obs_set_def -path_names_filter -path_names_perfect_model_obs -perfect_ics- -
-There are four mkmf_xxxxxx -files for the programs -create_obs_set_def, -create_obs_sequence, -perfect_model_obs, and -filter along with the -corresponding path_names_xxxxxx files. -You can examine the contents of one of the -path_names_xxxxxx files, -for instance path_names_filter, to see a list of -the relative paths of all files that contain Fortran90 modules -required for the program filter for -the L63 model. All of these paths are relative to the -DART directory that you copied into -your local storage. The first path is the main program -(filter.f90) and is followed by all -the Fortran90 modules used by this program. -
- --The mkmf_xxxxxx scripts -are considerably more cryptic and need to be modified to use the appropriate -DART/mkmf/mkmf.template.xxx -file containing the site-specific customizations of the previous section -(i.e. the template customization section). -For example, suppose you modified -DART/mkmf/mkmf.template.ifc -and want to create the create_obs_set_def program. -Simply make sure the appropriate template file -(kmf.template.ifc) is referenced -by mkmf_create_obs_set_def: -
- --The first command generates an appropriate Makefile and -the second results in the compilation of a series of Fortran90 modules which -ultimately produces an executable file: -create_obs_set_def. -Should you need to make any changes to the -DART/mkmf/mkmf.template.ifc, -you will need to regenerate the Makefile. -A series of .o and .mod files for each module compiled will also be -left in the work directory. -You can proceed to create the other three programs needed to work with -L63 in DART as follows: -
- -program | purpose |
---|---|
create_obs_set_def | -specify a (set) of observation characteristics taken - by a particular (set of) instruments - |
create_obs_sequence | -specify the temporal attributes of the observation sets - |
perfect_model_obs | -spinup, generate "true state" for synthetic observation experiments, ... - |
filter | -perform experiments - |
-Create an observation set definition. -create_obs_set_def creates an observation -set definition, the time-independent part of an observation sequence. -An observation set definition file only contains the -location, type, -and observational error characteristics -(normally just the diagonal observational error variance) -for a related set of observations. There are no actual observations, -nor are there any times associated with the definition. -For spin-up, we are only interested in integrating the L63 model, -not in generating any particular synthetic observations. -Begin by creating a minimal observation set definition. -
- --In general, for the low-order models, only a single observation set need -be defined. Next, the number of individual scalar observations -(like a single surface pressure observation) in the set is needed. -To spin-up an initial condition for the L63 model, only a -single observation is needed. -Next, the error variance for this observation must be entered. -Since we are not interested in this observation having any impact -on an assimilation (it will only be used for spinning up the model -and the ensemble), enter a very large value for the error variance. -An observation with a very large error variance has essentially no -impact on deterministic filter assimilations like the default variety -implemented in DART. Finally, the location and type of the -observation need to be defined. For all types of models, -the most elementary form of synthetic observations are called -'identity' observations. These observations are generated simply -by adding a random sample from a specified observational error -distribution directly to the value of one of the state variables. -This defines the observation as being an identity observation of the -first state variable in the L63 model. -The program will respond by terminating after generating a file -(generally named set_def.out) -that defines the single identity observation of the first -state variable of the L63 model. The following is a screenshot, -the user input looks like this. -
- --[unixprompt]$ ./create_obs_set_def - create_obs_set_def attributes: - $source$ - $revision: 2801 $ - $date: 2007-04-04 22:11:48 -0600 (Wed, 04 Apr 2007) $ - - Input the filename for output of observation set_def_list? [set_def.out] -set_def.out - assim_model attributes: - $source$ - $revision: 2801 $ - $date: 2007-04-04 22:11:48 -0600 (Wed, 04 Apr 2007) $ - namelist read; values are - sigma is 10.00000000000000 - r is 28.00000000000000 - b is 2.666666666666667 - deltat is 1.0000000000000000E-002 - output_state_vector is T - model attributes: - $source$ - $revision: 2801 $ - $date: 2007-04-04 22:11:48 -0600 (Wed, 04 Apr 2007) $ - model size is 3 - Input the number of unique observation sets you might define -1 - How many observations in set 1 -1 - Defining observation 1 - Input error variance for this observation definition -1000000 - Input an integer index if this is identity observation, else -1 -1 - set_def.out successfully created. - Terminating normally. --
-Create an observation sequence definition. -create_obs_sequence creates an 'observation -sequence definition' by extending the 'observation set definition' -with the temporal attributes of the observations. -
- --The first input is the name of the file created in the previous step, -i.e. the name of the observation set definition that you've -just created. -It is possible to create sequences in which the observation sets -are observed at regular intervals or irregularly in time. -Here, all we need is a sequence that takes observations over a -long period of time - indicated by entering a 1. -Although the L63 system normally is defined as having a non-dimensional -time step, the DART system arbitrarily defines the model -timestep as being 3600 seconds. By declaring we have 1000 observations -taken once per day, we create an observation sequence definition -spanning 24000 'model' timesteps; sufficient to spin-up the model -onto the attractor. Finally, enter a name for the -'observation sequence definition' file. Note again: there are no observation -values present in this file. Just an observation type, location, time and the -error characteristics. We are going to populate the observation sequence -with the perfect_model_obs program. -
- --[thoar at ghotiol work]$ ./create_obs_sequence - create_obs_sequence attributes: - - $source$ - $revision: 2801 $ - $date: 2007-04-04 22:11:48 -0600 (Wed, 04 Apr 2007) $ - - What is name of set_def_list? [set_def.out] -set_def.out - Setting times for obs_def 1 - To input a regularly repeating time sequence enter 1 - To enter an irregular list of times enter 2 -1 - Input number of observations in sequence -1000 - Input time of initial ob in sequence in days and seconds -1, 0 - Input period of obs in days and seconds -1, 0 - time 1 is 0 1 - time 2 is 0 2 - time 3 is 0 3 -... - time 998 is 0 998 - time 999 is 0 999 - time 1000 is 0 1000 - Input file name for output of obs_sequence? [obs_seq.in] -obs_seq.in --
-Initialize the model onto the attractor. -perfect_model_obs can now advance the -arbitrary initial state for 24,000 timesteps to move it onto the -attractor.
--perfect_model_obs uses the Fortran90 namelist -input mechanism instead of (admittedly gory, but temporary) -interactive input. In input.nml, the namelist for -perfect_model_obs the following values should be set:
- -namelist variable | description |
---|---|
async | -Simply ignore this. Leave it set to '.false.' |
obs_seq_in_file_name | -specifies the file name that results from running - create_obs_sequence, i.e. the - 'observation sequence definition' file. |
obs_seq_out_file_name | -specifies the output file name containing the - 'observation sequence', finally populated with - (perfect?) 'observations'. |
start_from_restart | -When set to 'false', - perfect_model_obs generates an - arbitrary initial condition (which cannot be guaranteed - to be on the L63 attractor). |
output_restart | -When set to 'true', - perfect_model_obs will record - the model state at the end of this integration in the file - named by restart_out_file_name. |
restart_in_file_name | -is ignored when 'start_from_restart' is 'false'. |
restart_out_file_name | -if output_restart is 'true', - this specifies the name of the file containing the model - state at the end of the integration. |
init_time_xxxx | -the start time of the integration. |
output_interval | -interval at which to save the model state. |
-Executing perfect_model_obs will integrate the -model 24,000 steps and output the resulting state in the file -perfect_restart.
--Generating ensemble initial conditions -is achieved by changing a perfect_model_obs namelist parameter, -copying perfect_restart to -perfect_ics, and -rerunning perfect_model_obs. -This execution of perfect_model_obs -will advance the model state from -the end of the first 24,000 steps to the end of an additional 24,000 -steps and place the final state in perfect_restart. -
- -A True_State.nc -file is also created. It contains the 'true' state of the integration.
- --Generating the ensemble: is done with the program -filter, which also uses the Fortran90 namelist -mechanism for input. -
Only the non-obvious(?) entries will be discussed.
- -namelist variable | description |
---|---|
ens_size | -Number of ensemble members. - 20 is sufficient for most of the exercises. |
cutoff | -to limit the impact of an observation, set to 0.0 - (i.e. spin-up) |
cov_inflate | -A value of 1.0 results in no inflation.(spin-up) |
-The filter is told to generate its own ensemble initial conditions -since start_from_restart is '.false.'. -However, it is important to note that the filter still makes use of -perfect_ics which is set to be the -restart_in_file_name. -This is the model state generated from the first 24,000 step model -integration by perfect_model_obs. -Filter generates its ensemble initial conditions -by randomly perturbing the state variables of this state. -
- --The arguments output_state_ens_mean -and output_state_ens_spread are '.true.' so that -these quantities are output at every time for which there are -observations (once a day here) and -num_output_ens_members means that the same -diagnostic files, -Posterior_Diag.nc and Prior_Diag.nc -also contain values for all 20 ensemble members once a day. -Once the namelist is set, execute filter to -integrate the ensemble forward for 24,000 steps with the final ensemble -state written to the filter_restart. -Copy the perfect_model_obs restart file -perfect_restart (the `true state') to -perfect_ics, and the -filter restart file -filter_restart to -filter_ics so that future assimilation experiments -can be initialized from these spun-up states. -
- --The spin-up of the ensemble can be viewed by examining the -output in the netCDF files True_State.nc -generated by perfect_model_obs and -Posterior_Diag.nc and Prior_Diag.nc -generated by filter. -To do this, see the detailed discussion of matlab diagnostics in Appendix I. - - - -
Begin by using create_obs_set_def to -generate an observation set in which each of the 3 state variables -of L63 is observed with an observational error variance of 1.0 -for each observation. To do this, use the following input -sequence (the text including and after # is a comment and does -not need to be entered):
- -set_def.out | -# Output file name |