FDS4 Beta Test

[Kevin McGrattan <kevin.mcgrattan@nist.gov>]

All

There is an updated test version of FDS4 on the FTP site

ftp://ftp.nist.gov/pub/bfrl/mcgratta/FDS4

We have addressed many of the problems reported in the last
month, so those who have
sent in bugs, please check if these problems have gone away
or have improved. Let
us know if the problem is fixed or not. It is important that
we get feedback. We 
know it is frustrating dealing with all these updates and
bugs, but the code is
developed all the more quickly because of it. We're
focussing on the WTC simulations,
so we haven't had the time to test the code on a wider
variety of geometries.
A few issues:

1. People have reported trouble accessing the FTP site.
Often the trouble is with
   security features in Windows if one is using Windows
Explorer to access the site.
   As an alternative, try using Netscape, some other FTP
tool, like WS_FTP, or try
   to FTP directly from the command line.

2. Many have reported trouble with temperatures lower than
ambient, mass fractions
   lower than zero, etc. These problems have been around for
all versions of FDS,
   and are related to the type of finite differencing used
for the transport
   equations. We have remedied some of these problems,
although they haven't
   entirely disappeared. For those reporting trouble, try
your simulations again and
   let us know if there is improvement.

3. For those using the Intel Fortran compiler, we think we
have worked out all the
   compiler errors, at least with the Linux version. We used
the Fortran options
   -O3 -xiW -ip -tpp7 -Vaxlib along with the Gnu C (gcc)
options -O -Dpp_noappend.
   The option -Vaxlib allows for the use of a non-standard
Fortran routine called
   FLUSH() that flushes output data from file buffers. The
option -Dpp_noappend
   is a compiler directive instructing the C routines not to
append an underscore
   to the names of C routines called by Fortran. Our goal is
to compile and run
   FDS4 on as many different platforms as possible, so
please provide feedback on
   compiler problems. The new User's Guide also has a
section in the Appendix listing
   different compilers and options.

4. We have fixed a number of bugs in the parallel version of
the code. In many cases,
   jobs would run on our Linux machines but not on our
Windows machines. The most
   noticable improvement is that now one can put two meshes
just touching and the
   transfer of information should work. In other words, you
do not have to overlap
   the meshes anymore. As a test, take any rectangular
domain and break it up into
   equal size meshes, set SYNCHRONIZE=.TRUE. on the &TIME
line, and run in parallel.
   The SYNCHRONIZE=.TRUE. will lock the time steps, so every
mesh will update every
   time step. This is not absolutely necessary, but it
helps. More info is in the
   User's Guide. Also, the sprinkhall4 case is not the best
example of load
   balancing. In the parallel code, the computation time is
at best the time it takes
   to process the mesh with the most cells multiplied by the
number of time steps.
   With sprinkhall4, the first mesh takes up the most CPU
time, so running in parallel
   only saves the time it takes to process the other meshes.
A better test of
   load balancing is to consider a case in which the domain
is broken up into meshes
   of comparable size with a constant global time step.

5. The latest versions of the code have November 10
compilation dates. Throw away
   earlier versions of FDS4.


Again, let me know if the new version fixes the reported
bugs.

Thanks

Kevin


-- 
Kevin McGrattan
National Institute of Standards and Technology
100 Bureau Drive, Stop 8663
Gaithersburg MD 20899-8663

Telephone: (301) 975 2712
FAX:       (301) 975 4052