[Dart-dev] [5857] DART/branches/development/models/noah: Finalized the directory structure and changed the scripts accordingly.
nancy at ucar.edu
nancy at ucar.edu
Thu Sep 6 10:52:06 MDT 2012
Revision: 5857
Author: thoar
Date: 2012-09-06 10:52:06 -0600 (Thu, 06 Sep 2012)
Log Message:
-----------
Finalized the directory structure and changed the scripts accordingly.
The model_mod.f90 will truncate 'bounded' variables to be positive when
being inserted into the NOAH restart file, but the raw assimilated values
are preserved in the Posterior_Diag.nc file. The advance_model.csh script
now preserves both the *LDASOUT* and RESTART* files and appends an instance
number and '.nc' extension to those files.
The advance_model.csh script also creates just the *LDASIN* files neeed
for the model advance given "large" forcing netCDF files that contain
multiple hours of forcing data (as per Rafael Rosolem's processing).
At present obs_diag.f90 does not handle the negative heights particularly well.
The documentation needs much work.
Modified Paths:
--------------
DART/branches/development/models/noah/dart_to_noah.f90
DART/branches/development/models/noah/model_mod.f90
DART/branches/development/models/noah/model_mod.html
DART/branches/development/models/noah/model_mod_check.f90
DART/branches/development/models/noah/noah_to_dart.f90
DART/branches/development/models/noah/shell_scripts/advance_model.csh
DART/branches/development/models/noah/shell_scripts/setup_filter.csh
DART/branches/development/models/noah/shell_scripts/setup_pmo.csh
DART/branches/development/models/noah/work/input.nml
DART/branches/development/models/noah/work/namelist.hrldas
-------------- next part --------------
Modified: DART/branches/development/models/noah/dart_to_noah.f90
===================================================================
--- DART/branches/development/models/noah/dart_to_noah.f90 2012-09-05 21:51:28 UTC (rev 5856)
+++ DART/branches/development/models/noah/dart_to_noah.f90 2012-09-06 16:52:06 UTC (rev 5857)
@@ -14,11 +14,11 @@
! purpose: interface between DART and the NOAH model
!
! method: Read DART state vector and overwrite values in a noah restart file.
-! If the DART state vector has an 'advance_to_time' present,
+! If the DART state vector has an 'advance_to_time' present,
! it is read ... but nothing happens with it at this time.
! DART is NEVER expected to advance noah.
!
-! The dart_to_noah_nml namelist setting for advance_time_present
+! The dart_to_noah_nml namelist setting for advance_time_present
! determines whether or not the input file has an 'advance_to_time'.
! Typically, only temporary files like 'assim_model_state_ic' have
! an 'advance_to_time'.
@@ -89,7 +89,7 @@
x_size = get_model_size()
allocate(statevector(x_size))
-! Read the namelist to get the input filename.
+! Read the namelist to get the input filename.
call find_namelist_in_file("input.nml", "dart_to_noah_nml", iunit)
read(iunit, nml = dart_to_noah_nml, iostat = io)
@@ -138,7 +138,7 @@
call get_noah_timestepping(kday, khour, noah_timestep, output_timestep, forcing_timestep, &
restart_frequency_seconds)
-
+
if ( (noah_timestep == forcing_timestep) .and. &
(noah_timestep == output_timestep )) then
@@ -191,7 +191,7 @@
call close_file(iunit)
! We know we need the forcing file for the timestring contained in the restart file.
-! This is a direct consequence of requiring the noah_timestep to be the same as the restart_frequency.
+! This is a direct consequence of requiring the noah_timestep to be the same as the restart_frequency.
! determine how many forcing files are needed
! determine the setting of kday or khour
Modified: DART/branches/development/models/noah/model_mod.f90
===================================================================
--- DART/branches/development/models/noah/model_mod.f90 2012-09-05 21:51:28 UTC (rev 5856)
+++ DART/branches/development/models/noah/model_mod.f90 2012-09-06 16:52:06 UTC (rev 5857)
@@ -190,13 +190,16 @@
character(len=NF90_MAX_NAME) :: stagger
character(len=obstypelength), dimension(NF90_MAX_VAR_DIMS) :: dimnames
integer, dimension(NF90_MAX_VAR_DIMS) :: dimlens
- integer :: numdims
- integer :: maxlevels
- integer :: xtype
- integer :: varsize ! prod(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
+ integer :: numdims
+ integer :: maxlevels
+ integer :: xtype
+ integer :: varsize ! prod(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
+ integer :: rangeRestricted
+ real(r8) :: maxvalue
+ real(r8) :: minvalue
character(len=paramname_length) :: kind_string
end type progvartype
@@ -410,6 +413,28 @@
progvar(ivar)%stagger = '-'
endif
+ ! if the variable is bounded, then we need to know how to restrict it.
+ ! rangeRestricted == 0 is unbounded
+ ! rangeRestricted == 1 is bounded below
+ ! rangeRestricted == 2 is bounded above ( TJH unsupported )
+ ! rangeRestricted == 3 is bounded above and below ( TJH unsupported )
+ ! Until we have more information ... (i.e. the netCDF files have the appropriate
+ ! valid_range attribute) ... we must guess.
+
+ if ( varname == 'QFX' ) then
+ progvar(ivar)%rangeRestricted = 0
+ progvar(ivar)%minvalue = -1.0_r8*huge(0.0_r8)
+ progvar(ivar)%maxvalue = huge(0.0_r8)
+ elseif ( varname == 'HFX' ) then
+ progvar(ivar)%rangeRestricted = 0
+ progvar(ivar)%minvalue = -1.0_r8*huge(0.0_r8)
+ progvar(ivar)%maxvalue = huge(0.0_r8)
+ else
+ progvar(ivar)%rangeRestricted = 1
+ progvar(ivar)%minvalue = 0.0_r8
+ progvar(ivar)%maxvalue = huge(0.0_r8)
+ endif
+
! These variables have a Time dimension. We only want the most recent time.
varsize = 1
@@ -422,7 +447,7 @@
if ((trim(dimname) == 'Time') .or. (trim(dimname) == 'time')) dimlen = 1
progvar(ivar)%dimlens( i) = dimlen
- progvar(ivar)%dimnames(i) = dimname
+ progvar(ivar)%dimnames(i) = trim(dimname)
varsize = varsize * dimlen
enddo DimensionLoop
@@ -585,7 +610,7 @@
! 0 unless there is some problem in computing the interpolation in
! which case an alternate value should be returned. The itype variable
! is a model specific integer that specifies the type of field (for
-! instance temperature, zonal wind component, etc.).
+! instance temperature, zonal wind component, etc.).
real(r8), intent(in) :: x(:)
type(location_type), intent(in) :: location
@@ -600,7 +625,7 @@
if ( .not. module_initialized ) call static_init_model
-! FIXME - for the single column case - there is no obvious way to
+! FIXME - for the single column case - there is no obvious way to
! determine the extent of the domain ... EVERYTHING matches.
if( west_east*south_north /= 1 ) then
@@ -630,7 +655,7 @@
! one use of model_interpolate is to allow other modules/routines
! the ability to 'see' the model levels. To do this, we can create
-! locations with model levels and 'interpolate' them to
+! locations with model levels and 'interpolate' them to
! KIND_GEOPOTENTIAL_HEIGHT
if ( (itype == KIND_GEOPOTENTIAL_HEIGHT) .and. vert_is_level(location) ) then
@@ -669,10 +694,10 @@
exit DEPTH
endif
enddo DEPTH
- indx = progvar(ivar)%index1 + zlev - 1
+ indx = progvar(ivar)%index1 + zlev - 1
endif
-obs_val = x( indx )
+obs_val = x( indx )
if (obs_val /= MISSING_R8) istatus = 0
if ( debug > 99 ) then
@@ -777,7 +802,7 @@
function nc_write_model_atts( ncFileID ) result (ierr)
!------------------------------------------------------------------
! This routine writes all the netCDF 'infrastructure' and sets up the
-! global attributes, dimensions, coordinate variables, and output variables.
+! global attributes, dimensions, coordinate variables, and output variables.
! The actuall filling of the output variables is done by
! nc_write_model_vars() which can be called repeatedly for each
! assimilation cycle.
@@ -1224,7 +1249,7 @@
write(filename,*) 'ncFileID', ncFileID
!-------------------------------------------------------------------------------
-! make sure ncFileID refers to an open netCDF file,
+! make sure ncFileID refers to an open netCDF file,
!-------------------------------------------------------------------------------
call nc_check(nf90_inq_dimid(ncFileID, 'copy', dimid=CopyDimID), &
@@ -1258,12 +1283,12 @@
! Ensure netCDF variable is conformable with progvar quantity.
! The TIME and Copy dimensions are intentionally not queried.
- ! This requires that Time is the unlimited dimension (the last one in Fortran),
+ ! This requires that Time is the unlimited dimension (the last one in Fortran),
! and that 'copy' is the second-to-last. The variables declared in the DART
! diagnostic files are required to have the same shape as in the source
! restart file. If Time is present there, it must also be the 'last' one.
- ! FIXME ... somewhere I should ensure that IF time is present in the original
+ ! FIXME ... somewhere I should ensure that IF time is present in the original
! prognostic variable from the model, it is the last/unlimited dimension.
call nc_check(nf90_inq_varid(ncFileID, varname, VarID), &
@@ -1536,7 +1561,6 @@
integer, dimension(NF90_MAX_VAR_DIMS) :: dimIDs, ncstart, nccount
character(len=NF90_MAX_NAME) :: dimname, varname
-integer :: year,month,day,hours,minutes
integer :: ncid, ncNdims, dimlen, VarID
integer :: i, indx1, indx2, indx3, indx4, indx, ivar, ntimes
@@ -1628,7 +1652,7 @@
endif
! FIXME - this is probably the place to ensure that the Time dimension is the last
- ! dimension if it is present. unlimited dimension
+ ! dimension if it is present. unlimited dimension
! Pack the variable into the DART state vector
@@ -1759,7 +1783,7 @@
type(time_type) :: file_time
! temp space to hold data while we are writing it
-integer :: i, ni, nj, ivar
+integer :: i, ivar
real(r8), allocatable, dimension(:) :: data_1d_array
real(r8), allocatable, dimension(:,:) :: data_2d_array
real(r8), allocatable, dimension(:,:,:) :: data_3d_array
@@ -1869,7 +1893,7 @@
if ( numdims == 1 ) then
allocate(data_1d_array(progvar(ivar)%dimlens(1)))
- call vector_to_prog_var(state_vector, ivar, data_1d_array)
+ call vector_to_prog_var(state_vector, ivar, data_1d_array,limit=.true.)
call nc_check(nf90_put_var(ncFileID, VarID, data_1d_array, &
start = mystart(1:ncNdims), count=mycount(1:ncNdims)), &
'dart_vector_to_model_file', 'put_var '//trim(string2))
@@ -1879,7 +1903,7 @@
allocate(data_2d_array(progvar(ivar)%dimlens(1), &
progvar(ivar)%dimlens(2)))
- call vector_to_prog_var(state_vector, ivar, data_2d_array)
+ call vector_to_prog_var(state_vector, ivar, data_2d_array,limit=.true.)
call nc_check(nf90_put_var(ncFileID, VarID, data_2d_array, &
start = mystart(1:ncNdims), count=mycount(1:ncNdims)), &
'dart_vector_to_model_file', 'put_var '//trim(string2))
@@ -1890,7 +1914,7 @@
allocate(data_3d_array(progvar(ivar)%dimlens(1), &
progvar(ivar)%dimlens(2), &
progvar(ivar)%dimlens(3)))
- call vector_to_prog_var(state_vector, ivar, data_3d_array)
+ call vector_to_prog_var(state_vector, ivar, data_3d_array,limit=.true.)
call nc_check(nf90_put_var(ncFileID, VarID, data_3d_array, &
start = mystart(1:ncNdims), count=mycount(1:ncNdims)), &
'dart_vector_to_model_file', 'put_var '//trim(string2))
@@ -1928,7 +1952,7 @@
! It is one noah_timestep AHEAD of the valid time.
!
! for instance, if the noah_timestep is 3600 seconds, the restart_frequency_hours is 1,
-! and the filename is RESTART.2004010102_DOMAIN1 the
+! and the filename is RESTART.2004010102_DOMAIN1 the
!
! Time = UNLIMITED ; // (blah_blah_blah currently)
! DateStrLen = 19 ;
@@ -1949,7 +1973,6 @@
character(len=19), allocatable, dimension(:) :: datestring
integer :: year, month, day, hour, minute, second
integer :: DimID, VarID, strlen, ntimes
-integer, dimension(2) :: ncstart, nccount
type(time_type) :: filetime, timestep
if ( .not. module_initialized ) call static_init_model
@@ -2012,7 +2035,7 @@
character(len=*), intent(in) :: filename
integer, dimension(NF90_MAX_VAR_DIMS) :: dimIDs, ncstart, nccount
-character(len=NF90_MAX_NAME) :: dimname, varname
+character(len=NF90_MAX_NAME) :: dimname
integer :: i, iunit, DimID, VarID, numdims, dimlen, xtype
@@ -2145,7 +2168,7 @@
-subroutine vector_to_1d_prog_var(x, ivar, data_1d_array)
+subroutine vector_to_1d_prog_var(x, ivar, data_1d_array, limit)
!------------------------------------------------------------------
! convert the values from a 1d array, starting at an offset, into a 1d array.
!
@@ -2159,8 +2182,9 @@
real(r8), dimension(:), intent(in) :: x
integer, intent(in) :: ivar
real(r8), dimension(:), intent(out) :: data_1d_array
+logical, OPTIONAL, intent(in) :: limit
-integer :: i,ii, VarID
+integer :: i,ii
if ( .not. module_initialized ) call static_init_model
@@ -2173,6 +2197,19 @@
ii = ii + 1
enddo
+if (present(limit)) then
+if ( limit ) then
+ if ( progvar(ivar)%rangeRestricted == 1) then
+ where(data_1d_array < progvar(ivar)%minvalue) data_1d_array = progvar(ivar)%minvalue
+ elseif (progvar(ivar)%rangeRestricted == 2) then
+ where(data_1d_array > progvar(ivar)%maxvalue) data_1d_array = progvar(ivar)%maxvalue
+ elseif (progvar(ivar)%rangeRestricted == 3) then
+ where(data_1d_array < progvar(ivar)%minvalue) data_1d_array = progvar(ivar)%minvalue
+ where(data_1d_array > progvar(ivar)%maxvalue) data_1d_array = progvar(ivar)%maxvalue
+ endif
+endif
+endif
+
ii = ii - 1
if ( ii /= progvar(ivar)%indexN ) then
write(string1, *)'Variable '//trim(progvar(ivar)%varname)//' packed wrong.'
@@ -2186,7 +2223,7 @@
-subroutine vector_to_2d_prog_var(x, ivar, data_2d_array)
+subroutine vector_to_2d_prog_var(x, ivar, data_2d_array, limit)
!------------------------------------------------------------------
! convert the values from a 1d array, starting at an offset,
! into a 2d array.
@@ -2194,12 +2231,13 @@
real(r8), dimension(:), intent(in) :: x
integer, intent(in) :: ivar
real(r8), dimension(:,:), intent(out) :: data_2d_array
+logical, OPTIONAL, intent(in) :: limit
-integer :: i,j,ii, VarID
+integer :: i,j,ii
if ( .not. module_initialized ) call static_init_model
-! unpack the right part of the DART state vector into a 1D array.
+! unpack the right part of the DART state vector into a 2D array.
ii = progvar(ivar)%index1
@@ -2210,6 +2248,19 @@
enddo
enddo
+if (present(limit)) then
+if ( limit ) then
+ if ( progvar(ivar)%rangeRestricted == 1) then
+ where(data_2d_array < progvar(ivar)%minvalue) data_2d_array = progvar(ivar)%minvalue
+ elseif (progvar(ivar)%rangeRestricted == 2) then
+ where(data_2d_array > progvar(ivar)%maxvalue) data_2d_array = progvar(ivar)%maxvalue
+ elseif (progvar(ivar)%rangeRestricted == 3) then
+ where(data_2d_array < progvar(ivar)%minvalue) data_2d_array = progvar(ivar)%minvalue
+ where(data_2d_array > progvar(ivar)%maxvalue) data_2d_array = progvar(ivar)%maxvalue
+ endif
+endif
+endif
+
ii = ii - 1
if ( ii /= progvar(ivar)%indexN ) then
write(string1, *)'Variable '//trim(progvar(ivar)%varname)//' filled wrong.'
@@ -2223,7 +2274,7 @@
-subroutine vector_to_3d_prog_var(x, ivar, data_3d_array)
+subroutine vector_to_3d_prog_var(x, ivar, data_3d_array, limit)
!------------------------------------------------------------------
! convert the values from a 1d array, starting at an offset,
! into a 3d array.
@@ -2231,12 +2282,13 @@
real(r8), dimension(:), intent(in) :: x
integer, intent(in) :: ivar
real(r8), dimension(:,:,:), intent(out) :: data_3d_array
+logical, OPTIONAL, intent(in) :: limit
-integer :: i,j,k,ii, VarID
+integer :: i,j,k,ii
if ( .not. module_initialized ) call static_init_model
-! unpack the right part of the DART state vector into a 1D array.
+! unpack the right part of the DART state vector into a 3D array.
ii = progvar(ivar)%index1
@@ -2249,6 +2301,19 @@
enddo
enddo
+if (present(limit)) then
+if ( limit ) then
+ if ( progvar(ivar)%rangeRestricted == 1) then
+ where(data_3d_array < progvar(ivar)%minvalue) data_3d_array = progvar(ivar)%minvalue
+ elseif (progvar(ivar)%rangeRestricted == 2) then
+ where(data_3d_array > progvar(ivar)%maxvalue) data_3d_array = progvar(ivar)%maxvalue
+ elseif (progvar(ivar)%rangeRestricted == 3) then
+ where(data_3d_array < progvar(ivar)%minvalue) data_3d_array = progvar(ivar)%minvalue
+ where(data_3d_array > progvar(ivar)%maxvalue) data_3d_array = progvar(ivar)%maxvalue
+ endif
+endif
+endif
+
ii = ii - 1
if ( ii /= progvar(ivar)%indexN ) then
write(string1, *)'Variable '//trim(progvar(ivar)%varname)//' filled wrong.'
@@ -2271,7 +2336,7 @@
forcing = forcing_timestep
restart = restart_frequency_hours*3600
-end subroutine
+end subroutine
!===================================================================
Modified: DART/branches/development/models/noah/model_mod.html
===================================================================
--- DART/branches/development/models/noah/model_mod.html 2012-09-05 21:51:28 UTC (rev 5856)
+++ DART/branches/development/models/noah/model_mod.html 2012-09-06 16:52:06 UTC (rev 5857)
@@ -35,26 +35,26 @@
<H2>Overview</H2>
-<P>The <strong><a href="http://www.ral.ucar.edu/research/land/technology/lsm.php">NOAH</a>
- Land Surface Model</strong> may now be tested with the
+<P>The <strong><a href="http://www.ral.ucar.edu/research/land/technology/lsm.php">NOAH</a>
+ Land Surface Model</strong> may now be tested with the
<strong>Data Assimilation Research Testbed (DART)</strong>.
- This should be considered
+ This should be considered
an 'alpha' release -- the code has only been tested for a single column configuration.
- The offline 2D driver code: High-Resolution Land Data Assimilation System (HRLDAS)
+ The offline 2D driver code: High-Resolution Land Data Assimilation System (HRLDAS)
v3.3 -- April 2011 is the version used to develop the interface.
<br />
<br />
- The <em>simple_driver-v3.3</em> was deemed suboptimal because of poor restart
- characteristics. Since the offline 2D driver code can be run at a single gridpoint
- and has excellent restart characteristics, there are no plans to support the
+ The <em>simple_driver-v3.3</em> was deemed suboptimal because of poor restart
+ characteristics. Since the offline 2D driver code can be run at a single gridpoint
+ and has excellent restart characteristics, there are no plans to support the
<em>simple-driver-v3.3</em> version of NOAH.
<br />
<br />
- <strong>IMPORTANT:</strong> The <em>hrldas-v3.3</em> driver
- generates NOAH restart files that are a bit unusual in
- that the <em>Times</em> string in the restart file <strong>does not</strong> denote the
+ <strong>IMPORTANT:</strong> The <em>hrldas-v3.3</em> driver
+ generates NOAH restart files that are a bit unusual in
+ that the <em>Times</em> string in the restart file <strong>does not</strong> denote the
time at which the restart is valid. The time at which the state is valid is actually
- <strong>ONE <em class=code>noah_timestep</em> BEFORE</strong> the time in the restart
+ <strong>ONE <em class=code>noah_timestep</em> BEFORE</strong> the time in the restart
file - <em>by design</em>. This has a
<strong>HUGE</strong> impact on the complexity of the scripting. At some point soon,
I will develop a schematic to illustrate this point.
@@ -70,47 +70,47 @@
<em class=code>SKINTEMP</em>,
<em class=code>SNODEP</em>,
<em class=code>WEASD</em>,
- <em class=code>CANWAT</em>, and
+ <em class=code>CANWAT</em>, and
<em class=code>QFX</em>. These variables are then adjusted to be consistent
with real observations and stuffed back into the same netCDF restart files.
- Since DART is an ensemble algorithm, there are multiple restart files for a
+ Since DART is an ensemble algorithm, there are multiple restart files for a
single restart time: one for each ensemble member. Creating the initial ensemble
of land surface states is an area of active research. At present, it may be sufficient
- to use a climatological ensemble; e.g., using the restarts for '1 January 00Z'
+ to use a climatological ensemble; e.g., using the restarts for '1 January 00Z'
from 50 consecutive years.
<br />
<br />
- The <em>offline hrldas-v3.3</em> driver is designed to use atmospheric
+ The <em>offline hrldas-v3.3</em> driver is designed to use atmospheric
forcing files that cover a VERY short period - about every hour.
- Consequently, the directories that contain the forcing files get very
+ Consequently, the directories that contain the forcing files get very
cluttered for experiments that may cover years, for example.
- There is reason to believe that the ensemble system will benefit from having
- unique atmospheric forcing for each ensemble member.
+ There is reason to believe that the ensemble system will benefit from having
+ unique atmospheric forcing for each ensemble member.
A reasonable ensemble size is 50 or 80 or so. You do the math.
<br />
<br />
- DART reads the NOAH namelist <em class=code>&NOAHLSM_OFFLINE</em> from a file called
+ DART reads the NOAH namelist <em class=code>&NOAHLSM_OFFLINE</em> from a file called
<em class=file>namelist.hrldas</em> for several pieces of information.
- DART is responsible for starting/stopping NOAH, the restart information is
+ DART is responsible for starting/stopping NOAH, the restart information is
conveyed through the NOAH namelist.
<br />
<br />
There are several scripts in the <em class=file>DART/models/noah/shell_scripts</em>
directory that assist in configuring and running experiments:
- <em class=program>setup_pmo.csh</em>,
- <em class=program>run_pmo.csh</em>,
+ <em class=program>setup_pmo.csh</em>,
+ <em class=program>run_pmo.csh</em>,
<em class=program>setup_filter.csh</em>, and
- <em class=program>run_filter.csh</em> .
+ <em class=program>run_filter.csh</em> .
</P>
<div class=indent1>
<h2>The offline 2D HRLDAS-V3.3</h2>
<P>
- and the development branch of DART was tested and run on a MacBook Pro laptop
+ and the development branch of DART was tested and run on a MacBook Pro laptop
running OS X 10.7.4 (Lion) with gfortran v 4.5.0.
- Several trivial modifications to the hrldas makefiles were necessary to compile
+ Several trivial modifications to the hrldas makefiles were necessary to compile
<em>Noah_hrldas_beta</em> on a case-insensitive filesystem.
- [TJH include more about this]
+ [TJH include more about this]
<br />
<br />
The DART components were built for debugging with the following settings:
@@ -123,15 +123,15 @@
FFLAGS = -g -O0 -ffree-line-length-none -fbounds-check -frecord-marker=4 -ffpe-trap=invalid $(INCS)
LDFLAGS = $(FFLAGS) $(LIBS)
</pre>
-</div>
+</div>
<!-- div class=indent1>
<h3>Observations.</h3>
<P>
- The observations come from the
+ The observations come from the
<a href="http://www.nodc.noaa.gov/OC5/WOD05/pr_wod05.html">World Ocean Database 2005</a>
and are processed by DART routines in the
- <a href="../../observations/WOD/WOD.html">DART/observations/WOD</a> directory.
+ <a href="../../observations/WOD/WOD.html">DART/observations/WOD</a> directory.
</P>
</div -->
@@ -139,11 +139,11 @@
<div class=indent1>
<h3>Converting between DART files and NOAH restart files.</h3>
<P>
- The information about how the NOAH variables are stored in the DART
- state vector comes from the order in which the variables are specified in
+ The information about how the NOAH variables are stored in the DART
+ state vector comes from the order in which the variables are specified in
<em class=file>input.nml</em><em class=code>model_nml:noah_variables</em> ,
as is the the name of the NOAH restart file.
- DART also needs to read the
+ DART also needs to read the
<em class=file>namelist.hrldas</em><em class=code>&NOAHLSM_OFFLINE</em> namelist.
<br />
<br />
@@ -151,9 +151,9 @@
</P>
<table width="100%" cellpadding="10">
<tr><td valign="top"><a href="noah_to_dart.html">noah_to_dart.f90</a></td>
- <td>converts the NOAH restart file <em class=file>restart.nc</em> into a
+ <td>converts the NOAH restart file <em class=file>restart.nc</em> into a
DART-compatible file normally called <em class=file>dart_ics</em> .
- We usually wind up linking the NOAH restart files to the
+ We usually wind up linking the NOAH restart files to the
static name (<em class=file>dart_ics</em>).
</td>
</tr>
@@ -164,13 +164,13 @@
the DART state vector to aid in the application of observation operators, etc.,
without having to modify those variables in the NOAH restart file.
There are two different types of DART output files, so there is a namelist
- option to specify if the DART file has two time records or just one
- (if there are two, the first one is the 'advance_to' time, followed
+ option to specify if the DART file has two time records or just one
+ (if there are two, the first one is the 'advance_to' time, followed
by the 'valid_time' of the ensuing state). <em class=program>dart_to_noah</em>
requires the DART file to be named <em class=file>dart_restart</em> and the
NOAH restart file have a name of <em class=file>restart.nc</em> &npsp;.
- If the DART file contains an 'advance_to' time,
- <em class=program>dart_to_noah</em> creates a file
+ If the DART file contains an 'advance_to' time,
+ <em class=program>dart_to_noah</em> creates a file
<em class=file>noah_advance_information.txt</em> which contains information
to control the length of the NOAH integration.
</td>
@@ -192,25 +192,25 @@
<h3>Generating the initial ensemble.</h3>
<P>
Creating the initial ensemble of ocean states is an area of active research.
- The NOAH model cannot take one single model state and generate its own
+ The NOAH model cannot take one single model state and generate its own
ensemble (typically done with <a href="#pert_model_state">pert_model_state</a>).
<br />
<br />
- The ensemble has to come from 'somewhere else'.
- At present, it may be sufficient to use a climatological ensemble; e.g.,
- using the NOAH restarts for '1 January 00Z' from 50 consecutive years
+ The ensemble has to come from 'somewhere else'.
+ At present, it may be sufficient to use a climatological ensemble; e.g.,
+ using the NOAH restarts for '1 January 00Z' from 50 consecutive years
from a hindcast experiment.
<br />
<br />
- There is a <em class=program>shell_scripts/MakeInitialEnsemble.csh</em>
- script that is intended to demonstrate how to convert a set of NOAH netCDF
- restart files into a set of DART files that have a consistent timestamp.
- If you simply convert each NOAH file to a DART file using
+ There is a <em class=program>shell_scripts/MakeInitialEnsemble.csh</em>
+ script that is intended to demonstrate how to convert a set of NOAH netCDF
+ restart files into a set of DART files that have a consistent timestamp.
+ If you simply convert each NOAH file to a DART file using
<em class=program>dart_to_noah</em>, each DART file will have a 'valid time'
that reflects the NOAH time of that state - instead of an ensemble of states
reflecting one single time. The
- <a href="../../../utilities/restart_file_utility.f90">restart_file_utility</a>
- can be used to overwrite the timestep in the header of each DART initial
+ <a href="../../../utilities/restart_file_utility.f90">restart_file_utility</a>
+ can be used to overwrite the timestep in the header of each DART initial
conditions file. The namelist for this program must look something like:
</P>
<pre>
@@ -231,12 +231,12 @@
new_advance_secs = -1,
gregorian_cal = .true. /</pre>
<P>
- The time of days = <em class=changed>145731</em>
+ The time of days = <em class=changed>145731</em>
seconds = <em class=changed>0</em> relates to 00Z 1 Jan 2000 in the DART world.
<br />
<br />
- BTW - Experience has shown that having a paired (unique) atmospheric forcing
- maintains the ensemble spread better than simply forcing all the ocean
+ BTW - Experience has shown that having a paired (unique) atmospheric forcing
+ maintains the ensemble spread better than simply forcing all the ocean
ensemble members with one single atmospheric state.
</P>
</div>
@@ -245,29 +245,29 @@
<div class=indent1>
<h3>Generating a set of observations for a 'perfect model' experiment using the LANL/NOAH executable and scripts.</h3>
<P>
- A perfectly sensible approach to get to know the system would be to try to
+ A perfectly sensible approach to get to know the system would be to try to
</P>
<ol>
<li>assimilate data for the first assimilation period and stop. Do not advance
the model at all. The filter namelist can control all of this and you do
not need to have a working <em class=program>advance_model.csh</em>
script, or even a working ocean model (as long as you have input data files).</li>
- <li>advance the model first and then assimilate data for the first assimilation
+ <li>advance the model first and then assimilate data for the first assimilation
period and stop.</li>
<li>advance, assimilate and advance again. This tests the whole DART facility.</li>
</ol>
<P>
I always like running something akin to a 'perfect model' experiment to start.
Since I have not come up with a good way to perturb a single model state to
- generate an ensemble, here's the next best thing. The details for running
+ generate an ensemble, here's the next best thing. The details for running
each program are covered in their own documentation.
</P>
<ol>
- <li>Create a set of initial conditions for DART by running one instance of NOAH
+ <li>Create a set of initial conditions for DART by running one instance of NOAH
for a very long time and saving restart files 'every so often'.
Use one of these as the initial condition
for <em class=program>perfect_model_obs</em> and the rest as the
- ensemble for the assimilation experiment. Since no one in their right
+ ensemble for the assimilation experiment. Since no one in their right
mind would use a high-resolution model for a proof-of-concept case
(hint, hint), running a low-resolution model for a 'very long time' should
not be a problem.
@@ -275,42 +275,42 @@
<li>create a TINY (i.e. 1) set of 'perfect' observations in the normal fashion:
<a href="../../../obs_sequence/create_obs_sequence.html">create_obs_sequence</a>
- and then
+ and then
<a href="../../../obs_sequence/create_fixed_network_seq.html">create_fixed_network_seq</a>
- to create an empty observation sequence file
+ to create an empty observation sequence file
(usually called <em class=file>obs_seq.in</em>).
The programs will prompt you for all the information they require.
Read their documentation if necessary.
</li>
<li>break the <em class=file>pop_in</em> namelist that comes with NOAH into
- two pieces - one called <em class=file>pop_in.part1</em>,
- that contains the <em class=code>&time_manager_nml</em> and
- put the rest in <em class=file>pop_in.part2</em>. The
+ two pieces - one called <em class=file>pop_in.part1</em>,
+ that contains the <em class=code>&time_manager_nml</em> and
+ put the rest in <em class=file>pop_in.part2</em>. The
<em class=code>&time_manager_nml</em> will be repeatedly updated
- as the NOAH model is repeatedly called by
+ as the NOAH model is repeatedly called by
<em class=program>advance_model.csh</em>.
</li>
<li>modify <em class=file>NOAH/work/input.nml</em> as needed.
</li>
- <li>modify
- <em class=file>DART/models/NOAH/shell_scripts</em><em class=program>run_perfect_model_obs.batch</em>
- to reflect the location of your DART directory, the NOAH directory,
+ <li>modify
+ <em class=file>DART/models/NOAH/shell_scripts</em><em class=program>run_perfect_model_obs.batch</em>
+ to reflect the location of your DART directory, the NOAH directory,
and which POPFILE to use as the initial condition.
</li>
<li>Run the experiment and populate the observation sequence file by
- executing/submitting the script
+ executing/submitting the script
<em class=file>DART/models/NOAH/shell_scripts/</em><em class=program>run_perfect_model_obs.batch</em>.
- The script may require some modification, but not much.
- Please let me know if I can improve the readability or comments.
- <em class=program>run_perfect_model_obs.batch</em> runs
+ The script may require some modification, but not much.
+ Please let me know if I can improve the readability or comments.
+ <em class=program>run_perfect_model_obs.batch</em> runs
<a href="../../perfect_model_obs/perfect_model_obs.html">perfect_model_obs</a>
</li>
- <li><em class=program>run_filter.batch</em> runs
+ <li><em class=program>run_filter.batch</em> runs
<a href="../../filter/filter.html">filter</a> in a similar fashion.
I have not finished the documentation for this yet.
</li>
@@ -322,18 +322,18 @@
<div class=indent1>
<h3>Exploring the Output.</h3>
<P>
- Is pretty much like any other model. The netCDF files have the model
- prognostic variables before and after the assimilation.
- There are Matlab® scripts for perusing the netCDF files in the
- <em class=file>DART/matlab</em> directory.
- There are Matlab® scripts for exploring the performance of the
- assimilation in observation-space (after running
- <a href="../../diagnostics/threed_sphere/obs_diag.html">obs_diag</a>
- to explore the <em class=file>obs_seq.final</em> file) - use the
- scripts starting with 'plot_', i.e.
+ Is pretty much like any other model. The netCDF files have the model
+ prognostic variables before and after the assimilation.
+ There are Matlab® scripts for perusing the netCDF files in the
+ <em class=file>DART/matlab</em> directory.
+ There are Matlab® scripts for exploring the performance of the
+ assimilation in observation-space (after running
+ <a href="../../diagnostics/threed_sphere/obs_diag.html">obs_diag</a>
+ to explore the <em class=file>obs_seq.final</em> file) - use the
+ scripts starting with 'plot_', i.e.
<em class=file>DART/diagnostics/matlab/plot_*.m</em>.
- As always, there are some model-specific item you should know about in
- <em class=file>DART/models/NOAH/matlab</em>, and
+ As always, there are some model-specific item you should know about in
+ <em class=file>DART/models/NOAH/matlab</em>, and
<em class=file>DART/models/NOAH/shell_scripts</em>.
<br />
<br />
@@ -381,10 +381,10 @@
<TR><!--contents--><TD valign=top>output_state_vector</TD>
<!-- type --><TD valign=top>logical <em class=units>[default: .true.]</em></TD>
<!--descript--><TD valign=top>The switch to determine the form of the state vector in the
- output netCDF files. If <em class=code>.true.</em>
- the state vector will be output exactly as DART uses it
- ... one long array. If <em class=code>.false.</em>,
- the state vector is parsed into prognostic variables and
+ output netCDF files. If <em class=code>.true.</em>
+ the state vector will be output exactly as DART uses it
+ ... one long array. If <em class=code>.false.</em>,
+ the state vector is parsed into prognostic variables and
output that way -- much easier to use with 'ncview', for
example.</TD></TR>
@@ -395,7 +395,7 @@
<TR><!--contents--><TD valign=top>assimilation_period_seconds</TD>
<!-- type --><TD valign=top>integer <em class=units>[default: 0]</em></TD>
- <!--descript--><TD valign=top>In addition to <em class=code>assimilation_period_days</em>,
+ <!--descript--><TD valign=top>In addition to <em class=code>assimilation_period_days</em>,
the number of seconds to advance the model for each assimilation.
</TD></TR>
@@ -403,13 +403,13 @@
<!-- type --><TD valign=top>real(r8) <em class=units>[default: 0.2]</em></TD>
<!--descript--><TD valign=top> Reserved for future use.
<!-- The amount of noise to add when trying to perturb a single
- state vector to create an ensemble. Only used when
+ state vector to create an ensemble. Only used when
<em class=file>input.nml</em><em class=code>&filter_nml:start_from_restart = .false.</em>
- See also
- <a href="#InitialEnsemble">Generating the initial ensemble</a>
- at the start of this document. units: standard deviation
- of a gaussian distribution with the mean at the value of
- the state vector element. --> </TD></TR>
+ See also
+ <a href="#InitialEnsemble">Generating the initial ensemble</a>
+ at the start of this document. units: standard deviation
+ of a gaussian distribution with the mean at the value of
+ the state vector element. --> </TD></TR>
<TR><!--contents--><TD valign=top>debug</TD>
<!-- type --><TD valign=top>integer <em class=units>[default: 0]</em></TD>
@@ -417,7 +417,7 @@
<em class=code>0</em> is as quiet as it gets.
<em class=code>> 1</em> provides more run-time messages.
<em class=code>> 5</em> provides ALL run-time messages.
- All values above 0 will also write a netCDF file of the grid
+ All values above 0 will also write a netCDF file of the grid
information and perform a grid interpolation test.</TD></TR>
</TABLE>
@@ -426,9 +426,9 @@
<pre>
&model_nml
- assimilation_period_days = 1,
- assimilation_period_seconds = 0,
- model_perturbation_amplitude = 0.2,
+ assimilation_period_days = 1,
+ assimilation_period_seconds = 0,
+ model_perturbation_amplitude = 0.2,
output_state_vector = .false.,
debug = 0 /
</pre>
@@ -453,37 +453,37 @@
<P>
This namelist is read in a file called <em class=file>pop_in</em> .
- This namelist is the same one that is used by the ocean model and is used
- to control the integration length of NOAH. It is unimportant for the CESM/POP
+ This namelist is the same one that is used by the ocean model and is used
+ to control the integration length of NOAH. It is unimportant for the CESM/POP
experiments but is critically important for the LANL/NOAH experiments.
The values are explained in full in the NOAH documentation. The DART code
reads the namelist and simply overwrites several values with the new time
- integration information. All the other values are unchanged.
+ integration information. All the other values are unchanged.
<br />
<br />
- <em class=program>dart_to_noah</em> writes out a new
+ <em class=program>dart_to_noah</em> writes out a new
<em class=code>&time_manager_nml</em> in <em class=file>pop_in.DART</em>
if the DART state being converted has the 'advance_to_time' record in it.
- This is the case during the middle of a DART experiment, but is not
- typically encountered if one is working with DART 'initial conditions'
+ This is the case during the middle of a DART experiment, but is not
+ typically encountered if one is working with DART 'initial conditions'
or 'restart' files. The <em class=file>pop_in.DART</em> must be concatenated
- with the other namelists needed by NOAH into a file called
- <em class=file>pop_in</em> . We have chosen to store the other
- namelists (which contain static information) in a file called
- <em class=file>pop_in.part2</em>. Initially, the
- <em class=code>time_manager_nml</em> is stored in a companion file called
+ with the other namelists needed by NOAH into a file called
@@ Diff output truncated at 40000 characters. @@
More information about the Dart-dev
mailing list