Modified FDS 6 Options

For anyone testing FDS6=T on the MISC line, please be aware that with the latest SVN (4801) there have been some noteworthy modifications. Generally speaking, these modifications are the result of experience gained by solving issues presented by our user community and we would like to thank those who have contributed to this effort. It is simply not possible for the developers to test every possible scenario the user may encounter: your feedback is invaluable.

The original list of FDS6 options can be found here:
http://groups.google.com/group/fds-smv/browse_thread/thread/7bb35719784756b7#

This list has been modified as follows:

1. CHECK_KINETIC_ENERGY=F is the new default. This is a rather inconsequential change, but as we get further into the development cycle timing becomes a more important concern and so removing this flag as a default provides a closer comparison with FDS 5. If the user wishes to output QUANTITY='TURBULENCE_RESOLUTION' then they need to set CHECK_KINETIC_ENERGY=T on MISC.

2. PROJECTION=T (on MISC) is a new option in FDS6. With this option the time integration scheme is a true projection method. Because of the current structure of FDS 5 this option uses more flops, but in my experience this is not noticeable. So, what is a true projection method as opposed to the usual scheme in FDS 5? In FDS 5 the assumption is made that the pressure field obtained from the Poisson solve will force the velocity to exactly match the velocity divergence computed from the time derivative of the equation of state. Because we use a direct Poisson solver at the end of a time step the actual discrete velocity divergence is very close to an exact match of the desired velocity divergence from the equation of state. BUT, on the next time step whatever error (however small) that we incurred on the previous time step is still present. For very refined and long-time calculations there is the possibility that this error could become significant, potentially even causing an instability. Put simply, a true projection method does not have this deficiency. On every time step the velocity field is projected to match the desired divergence and the error from the previous projection is erased. Provided this method can be made as efficient as the FDS 5 method -- and it can with the proper code structure -- the true projection is clearly the more desirable approach.

3. For DNS=T we now set FLUX_LIMITER=4. FL=4 invokes the Charmers limiter which is convergent whereas FL=2 invokes Superbee which does a better job at retaining shocks in the scalar data but is not convergent. We hope to eventually have a scheme that smoothly transitions from one method to the other (FL=2 to FL=4) as the grid is refined (i.e. as we converge from LES to DNS).

In addition to the modifications listed above, a significant improvement has been made to the stability check (i.e. the time step calculation) used in FDS 6. In short, the previous method was overly restrictive and was adding unnecessary computational expense to FDS 6 calculations. What we find now is that the cost of the velocity calculations in FDS 6 are roughly 16% more than FDS 5 due to the calculation of the dynamic Smagorinsky constant. But, we also find that the mass transport routines are half the cost of FDS 5. The overall cost difference is problem dependent but we feel we are slowly trimming the fat from FDS 6.

Please keep your observations coming (with the latest SVN, of course :))!

FDS Verification and Validation

A few years ago, Prof Jose Torero of the University of Edinburgh remarked during a presentation that for any given quantity that you might want to predict with a fire model, you can find 2 or 3 papers in the literature that report that FDS works well, and 2 or 3 that report that it does not work well. Putting aside for the moment what is meant by "works well," the point Jose was trying to make is that it is very difficult for practicing engineers to know when to trust or not trust model predictions. The complementary processes of Verification and Validation are intended as checks of the mathematical algorithm and physical submodels, respectively, and there has been a considerable amount of work to V&V FDS over the past decade. Yet, the problem Jose alludes to remains.

When FDS was first released, we had in mind the idea that V&V would be performed by students and engineers using the model for research or commercial applications, and the results would be published in the fire literature. This did indeed happen, and there are numerous papers, reports, and theses spread across the various journals and websites. However, several years ago as we were working on a V&V study with the US Nuclear Regulatory Commission, it became apparent that we could not just depend on the fire literature as a repository of FDS V&V work. There were several reasons:

1. V&V, especially Validation work, cannot be easily crammed into a short journal article.
2. Results of older versions of the model lose their validity after a few years.
3. Often the experimental conditions and uncertainties are unknown.
4. Often the work is performed by students who are just learning how to use the model.
5. There are too many different ways of quantifying accuracy, which gets back to the question above as to what "works well" means.
6. Cases have to be re-run with each new release, and we cannot expect journals to keep publishing the same old stuff.

For these reasons, we decided to maintain two manuals, Volumes 2 and 3 of the FDS Technical Reference Guide, called the FDS Verification and Validation Guides, respectively. In these, we have compiled existing V&V work and continually add case studies to demonstrate mathematical accuracy and physical fidelity. The Validation Guide

http://fds-smv.googlecode.com/svn/trunk/FDS/trunk/Manuals/All_PDF_Files/FDS_5_Validation_Guide.pdf

now has hundreds of experiments and thousands of individual point to point comparisons for a wide variety of output quantities. The Verification Guide

http://fds-smv.googlecode.com/svn/trunk/FDS/trunk/Manuals/All_PDF_Files/FDS_5_Verification_Guide.pdf

is more recent, but it is growing.

Everyone who is using FDS ought to familiarize themselves to some extent with these Guides. They are not the sort of thing you sit down and read, however. Rather, they are reference documents that you should refer to whenever the question arises, "Can FDS do that?"

We would like to especially encourage students who are interested in working with FDS to look through these Guides. More than anything else, they indicate subjects of current interest, especially areas that we are working to improve. In addition to consulting these Guides, we encourage you to contact us via the Discussion Group (or off-line if you like) and indicate which areas you might want to work in. Using specific examples directly out of the V&V Guides is a great way to start a collaboration because we are familiar with the cases and either the analytical or experimental technique. It is far more difficult for us to work with you when all we see are a few comparisons of FDS with experiments we are not familiar with. The value of working with such a large amount of test data is that anomolies in one or two experiments become outliers when compared to hundreds of other measurements.

If you have a verification case or an experimental dataset(s) that you would like to contribute, it would be very helpful if the data and FDS input files could be prepared in a way that is similar to the cases already in the repository. It takes a significant amount of time to boil down megabytes of test data into a form that can be easily plotted and compared to the model. We do not have enough time to take a test report, set up the input files, work the experimental data into a useable form, run the cases, prepare the output graphs, and document the process for each and every experimental test series. If you have already done this, it takes much less time to re-organize the material into a form that we can easily work into one of the Guides. But, please contact us early in the process. There are plenty of useful techniques we have developed for doing V&V, and it these are adopted early, there is a much greater likelihood that the work will make a significant contribution to the whole project.

FDS 5.4 Release -- A Few Installation Issues

Thanks to all of you who have given feedback on the new release of FDS, version 5.4. We're currently fixing a few problems related to the Mac installation and the OpenMP test for Windows. We'll post an update when these are ready for use.

Also, note that these blog posts automatically get posted to the FDS-SMV Discussion Group. So please respond with comments in the Discussion Group so that we can maintain a consistent thread.

Pyrolysis Model in FDS

In the next few weeks we plan to write a few articles to alert you to some changes made in FDS 5.4. This article focuses on the solid phase pyrolysis model; that is, where you specify a reaction or reactions that the solid undergoes in releasing fuel gases. There is still confusion among users as to the various ways that you can describe a fire. Most simply specify a heat release rate per unit area (HRRPUA). In that case, there is no need to provide more details about the solid phase reaction. HRRPUA is equivalent to a gas burner that you control via RAMPs or similar parameters.

However, if you specify material (MATL) properties, including kinetic parameters, to describe one or more reactions that occur as your solid heats up, be aware that the definition of the parameter REFERENCE_TEMPERATURE has changed in 5.4. In previous versions of FDS, this parameter, along with REFERENCE_RATE, was used to calculate the Arrhenius parameters A and E in the reaction rate expression. These parameters are typically found via thermo-gravimetric analysis (TGA) or similar small-scale measurement techniques. Since these measurements are most often unavailable for a particular material of interest, FDS provides a way, via these "reference" values, of estimating the kinetic parameters. You have also probably seen discussion of genetic algorithms that also are intended to estimate various kinetic parameters when only a partial number are measured directly.

The change made in FDS 5.4 to the definition of REFERENCE_TEMPERATURE was intended to make the FDS pyrolysis model more consistent with current trends in materials testing and analysis. For a good introduction, read Jose Torero's chapter, "Flaming Ignition of Solid Fuels," in the Fourth Edition of the SFPE Handbook. Then read the FDS User's Guide section entitled, "Solid Fuels that do NOT Burn at a Specified Rate." All of this development is focused on the long-term goal of standardizing the process of obtaining material property data. A necessary first step is to understand the meaning of typical TGA results (a good example can be found in Torero's chapter). Then we need to translate this information into FDS inputs.

We'd like to continue the dialog on pyrolysis modeling that started last year, but has recently stalled a bit. We are starting to notice yet again that many users are simply cutting and pasting lines of input from the User's Guide and sample cases without really understanding their meaning. We are developing a suite of verification cases that can be used to check the basic kinetic parameters (a simulated TGA experiment), as well as cases to assess the overall solid phase model (a simulated cone calorimeter measurement). Nick Dembsey, Marc Janssens and Morgan Hurley are continuing their multi-year effort to develop a standard guide for obtaining material properties. Our work in FDS will hopefully move us closer to the goal.

So for those of you with an interest in this area, it would be very useful to get your feedback. I will post this blog to the Discussion Group so that it will appear near the top of the list of issues.

FDS and OpenMP

Christian Rogsch of the University of Wuppertal has implemented OpenMP directives that enable FDS to make use of multiple processors on a single computer. This is a second option for running FDS in parallel. In fact, although it still needs a bit of testing, OpenMP and MPI should work together. OpenMP (Open Multi-Processing) will run a single mesh FDS job faster by making use of all available processors on a single computer. MPI (Message Passing Interface) requires that you break up the single mesh into multiple meshes, each of which runs on a separate computer. Ideally, we should be able to break up a case over multiple meshes on multiple computers using MPI, and allow OpenMP to run the individual mesh calculations faster.

As a test, I have posted to the Downloads page two executables:

fds5_openmp.exe
fds5_openmp_mpi.exe

These are for 32 bit Windows machines. If this test is successful, we will compile and release executables for other platforms as well. Note that there is currently no guidance in the User's Guide about OpenMP. These executables should work just like fds5.exe and fds5_mpi.exe. That is, there should be nothing you need to install, and you should not need extra libraries. At least, that is what we hope and why we need to test these before doing a more general release. What you should notice is that when you run fds5_openmp.exe on a job, all of your available processors or cores should work on the case. You can check your system performance to make sure.

Please let us know if these executables work for you, or more importantly if they don't. Of course, you need to have a computer, or computers, with multiple processors. At the start of the run, FDS should tell you how many processors (or "threads") it thinks it has access to.

Good luck and thanks again to Christian for all his efforts!

Release of FDS-SMV 5.4

We have posted a new "minor" release of FDS and Smokeview on the Downloads page. You can navigate there from the FDS/SMV homepage fire.nist.gov/fds. Remember that a "minor" release means that some features of FDS have changed, in particular the velocity boundary conditions and certain aspects of the solid phase pyrolysis model. The new FDS User's Guide, which comes with the Download, has more details.

Note that we have changed the installation process of FDS/Smokeview for Windows users. First, the new default installation folder is

C:\Program Files\FDS\FDS5

The purpose of this change is to enable us to start development of FDS 6 without having to overwrite current files. The other change in the installation process is that we are only using the program WinZip for the installation. WinZip has a nice feature which allows you to download files and unzip them into a given folder. It makes it easy for us to "bundle" the files needed for installation. A problem with past releases has been that we would release a "bundle" for every minor version of FDS, but then released separate executables for each maintenance release. We have found that many used the bundles only but did not update the maintenance releases. From now on, each new maintenance release will have all the necessary files for a full installation.

Note that as part of the new installation, there is a short program that will change the "path" variables to point at the new installation folder. Once you install the new version and restart your computer, the commands "fds5" and "smokeview" will now point to the new version, not the old. You can go back to an older version by just moving the appropriate executable from the old folder to the new. Whenever you type a command at the prompt, Windows searches through the path folders until it either finds or does not find the command. If something does not work properly, check your "Environment Variables", which can be found under "System Properties" --> "Advanced" on most Windows machines. I have found it useful to look at these "path" variables from time to time because many common software problems can be traced to bad path variables.

In the coming weeks, we will post additional information about the new release and features. For now, it would be useful to us if you could try installing the new version and reporting back to us via the Discussion Group any problems you encounter. The same is true for Mac and Linux users. The installation for these platforms is still basically a zip or "tar" file, but the new executables may or may not work properly because we have upgraded to Version 11 of the Intel Fortran compilers.