[Dart-users] fix when running with R4 reals in DART

[Nancy Collins]

hello dart-users,

this note is directed to dart users who redefine R8 (8 byte reals)
to be R4 (4 byte reals) in the DART/types/common_mod.f90 file,
and who have data with very small values in their state vector.

it's always possible to find 2 numbers that are individually larger than
zero, but their product is small enough to underflow and be exactly 0.
with 8-byte reals this happens around 1e-308, but with reals defined
as 4-bytes, this happens around 1e-38.   we had some code in dart
where we compute correlations for inflation and sampling error correction
where we test that both operands are > 0 and then divide by their
product, which in rare underflow cases could be 0.

if the denominator is 0 the result is Infinity or NaN (not a number)
depending on the value of the numerator.  Infinity would get reset
to 1.0 by the code lines directly after the divide, but NaN would be
carried along by the code and might eventually result in a NaN appearing
in the output state vector.  this generally upsets most models when they
do the next advance.

we have updated the assim_tools/assim_tools_mod.f90 file on both
the trunk and in the kodiak branch (and the other specialized branches
as well) in the dart subversion repository.  the updated code now does
the tests and computations in a different order to avoid this possibility.
the original code was not wrong and was unlikely to cause problems
with full 8-byte reals and commonly occurring data value ranges.

at this point we believe we have eliminated problems with R4 and underflow
from small values in fields, but there still remains the possibility of 
overflow
if you are using R4s and working with fields that have very large values.
R4 values overflow around 1e38 and we are computing sums and squares
of the data, so fields with data values greater than ~1e15 should not be
run with an R4 version.  (R8 precision goes up to 1e308.)  there are
fundamental limitations to numerical accuracy in all cases, but running
with R4 makes it more likely to encounter them.   please report any
apparent numerical problems (R4 or R8) to us and we will do our best
to address them.

WRF users in particular often build and run with R4 reals and several
wrf/dart users have recently reported discovering NaNs in their output
state vector.  this might show up as a crash immediately after WRF
starts up from an updated wrfinput file.  this patch to assim_tools_mod
has fixed this problem for at least 2 users.  there is also a 
possibly-related
patch available for the WRF code to zero out very small values on the
boundary rows that may have contributed to a higher probability of
the dart divide-by-zero problem occurring.

i'll be sending around more details about the WRF source code fix to
the wrfdart-users mailing list.  click here 
<http://mailman.ucar.edu/mailman/listinfo/wrfdart-users> if you aren't 
on that list
and would like to be.  if that link gets stripped out, the location to
sign up for the wrfdart users list is:

http://mailman.ucar.edu/mailman/listinfo/wrfdart-users

if you want to alter any settings or get off this general dart-users list
(or if you want to add someone else), the mailman page for this list
is here <http://mailman.ucar.edu/mailman/listinfo/dart-users> which is a 
link to:

http://mailman.ucar.edu/mailman/listinfo/dart-users


thanks,
nancy at ucar dot edu


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/dart-users/attachments/20120229/c566122d/attachment.html