FDS Update

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

All

We are continuing to work towards a release of FDS 5.  It is taking longer 
than we anticipated because of the need to re-organize the code 
substantially.  Many of the requests that we have received require us to 
change many routines that have been around since the beginning.  Over the 
years, these routines have gotten fat, with too many add-ons that have 
become too difficult to maintain.  Over the past few years, while we were 
heavily involved in the WTC Investigation, we were very hesitant to make 
such fundamental changes, as we had deadlines to meet.  Now there is some 
flexibility, and we've decided to do what needs to be done rather than 
putting it off.

In making these changes, we're starting to think long-term.  Up to now, the 
FDS code has been written primarily by myself, Jason Floyd, and Simo 
Hostikka, and all three of us are still at it.  But we know that we can't 
continue like this forever, so we're trying to re-organize the code in a way 
that others can understand.  We're naming variables in a meaningful way, 
adopting  an "object-oriented" programming style, eliminating overly 
complicated routines, and so on.  With the help of a new staffer here at 
NIST, Bryan Klein, we've established an account on SourceForge.net 
(http://sourceforge.net/projects/fds-sv/).  This is a very popular 
open-source program development environment, with features such as revision 
control, archiving, software distribution, bug reporting, and so on.  We're 
not yet completely up and running, but you'll see at this site the most 
recent version of the source code.  Eventually, you will be able to download 
the latest stuff from here, plus those who want to work with the source code 
will have access (via anonymous CVS) to the latest version.  I can no longer 
handle the daily email traffic from users who report bugs, ask questions, 
and so on.  SourceForge has all of this type of user feedback functionality.

We are also assembling a Verification and Validation Guide, a new FDS 
manual.  It will contain all Verification cases (calcs we use to check the 
code) and Validation cases (FDS inputs, outputs and experimental data).  The 
V&V Guide is going to grow as we continue to add new features to FDS, and 
new experimental data sets.  As I have remarked in previous mailings, our 
rather informal V&V strategy of the past has had to change.  We can no 
longer simply point to journal articles as proof that we've V&V'ed FDS.  We 
have to re-run, and replot, all past cases and permenantly archive them.  In 
future, if an AHJ or other interested party asks for a demonstration of FDS 
capabilities, this will be it.

All of this opens up new opportunities for collaboration.  While it is 
gratifying to see so much work being done with FDS, I am afraid that much of 
this work is not being put to good use.  Many of you send me papers about 
validation efforts with FDS, or masters/PhD theses, or just your own 
experience.  Much of this duplicates efforts of others.  Some of the 
validation papers present  conflicting and confusing results.  We intend the 
new V&V Guide to form the basis of a more organized effort to maintain and 
improve FDS.  Our experience over the past few years in re-working some of 
the past validation exercises has convinced us that the basic transport 
algorithm within FDS is working quite well, but there are other areas that 
need improvement.  Just looking at a few experiments will not tell us 
this -- we've had to look at dozens of test series at different labs, 
hundreds of individual experiments, thousands of point to point comparisons.

So we are now laying the groundwork for the future.  It's all going quite 
well, but there just are many new issues to consider.  So we need your help. 
In a few weeks time, we're going to ask the more experienced FDS users 
(larger companies might want to select one or two for this task) to develop 
simple input files with the new FDS 5 format, to test various features that 
are new, that you requested, that were buggy in the past.  We refer to these 
as "Verification" calcs.  They are short and simple, sometimes running in 
seconds, or minutes, at most a few hours.  We've been doing alot of this 
ourselves, but there are just too many things to test, and inevitably things 
fall through the cracks.  We want to permanently maintain these test cases, 
so that if anyone has trouble in the future, these cases would provide an 
easy means to debug the problem.  I once used something called "silly.data" 
for this purpose.  We want a suite of silly test cases.

We want to conduct this beta testing during March.  For you Americans, this 
will kill time between basketball games.  What we will be asking you to do 
is to download the test version of FDS 5, plus the new manuals, put together 
a few simple calcs to test various features of interest to you, and report 
to us your findings, and potentially send us the input files.  We'd like to 
iron out bugs, confusing input parameters, errors in the manuals, and so on. 
In the past, we've done this after the official release, but many have 
complained about constantly changing versions.  So we hope to nail down 
simple things now, rather than later.

So in the next few weeks, we'll have an announcement about a beta release, 
and work with the beta testers through March.

K


Kevin McGrattan
National Institute of Standards and Technology
100 Bureau Drive, Mail Stop 8663
Gaithersburg MD 20899
Phone: 301 975 2712
Fax:       301 975 4052