Tuesday, June 1, 2021

Release of FDS 6.7.6

 A new maintenance release of FDS and Smokeview is available for download at 

https://pages.nist.gov/fds-smv/downloads.html

Release notes can be found at 

https://github.com/firemodels/fds/wiki/FDS-Release-Notes

For those of you who have been having difficulties with tunnel fire scenarios, you might want to search the new User's Guide for the parameter TUNNEL_PRECONDITIONER. This parameter has the effect of stabilizing the pressure and velocity fields in long tunnels with fires and solid interior walls.

Wednesday, June 27, 2018

Test blog

This is a test to see if Google has fixed the problem of sending Blogger posts to connected Google Groups discussions.

Thursday, June 23, 2016

FDS-SMV 6.5.0 Minor Release

This minor release is meant to address reports of numerical instabilities in tunnel fire cases with the recently released FDS 6.4.0, which may be attributed to relaxing the VN stability constraint from 0.5 to 1 in order to speed up calculations.

The key change implemented in FDS 6.5.0 is to include the baroclinic term in the pressure iteration scheme.  This corrects a time lag between the hyrdodynamic pressure in the baroclinic term and the output from the pressure Poisson equation.

Other improvements implemented in this version include an optional iteration in the radiation solve for multi-mesh simulations and more accurate interpolation of particle force terms.  More information is given in the Release Notes.

Here is a link to our Downloads page.


Tuesday, April 12, 2016

FDS-SMV 6.4.0 Minor Release

A new minor release, FDS-SMV 6.4.0, has been posted.  This release fixes a couple of issues with the combustion model.  The first was a bug in the reaction divergence expression that led to below ambient temperatures in some instances.  The second was a problem with boundedness for multiple reactions, mainly affecting complex chemistry.

https://pages.nist.gov/fds-smv/downloads.html

In this release we have also fixed several issues with MPI scaling.  With a time grant on the Oak Ridge National Lab supercomputer, Titan, we were able to run FDS on up to roughly 10,000 processes.  Linear scaling was achieved to roughly 16^3 mesh size (4096 cells/mesh).


















For further details on this release see the FDS Release Notes.



Monday, December 7, 2015

FDS-SMV 6.3.2 Maintenance Release

A maintenance release, v6.3.2, has been posted to correct a bug in the liquid evaporation routines.  The bug should only affect v6.3.1.

FDS-SMV Downloads

Thursday, November 12, 2015

Uploading text files for Issues on GitHub

I recently got notification from GitHub support that they now allow Write access for uploading text files to Issues posts.  This is welcome news.

Thanks to Dave McGill for testing this new feature.

This means that when you post an Issue you can attach your input file.  But remember you need to append ".txt" to the file name.  For example, if your input file is simple_test.fds, you need to change the name to simple_test.fds.txt or just simple_test.txt.

Tuesday, November 10, 2015

FDS 6.3.1 Maintenance Release

Today we posted a maintenance release, FDS 6.3.1, bundled with Smokeview 6.3.2.

The main motivation for pushing out this release is to correct a bug in the mixing step for multi-step and finite-rate chemistry calculations.  The default simple chemistry model is not affected.

An optional input parameter DT_HVAC has been added to help stabilize duct flow calculations.

Additionally, we have been working on testing FDS scaling on large compute clusters, like Titan at Oak Ridge National Laboratories.  The results for weak and strong scaling on our burn cluster at NIST are published in the new user's guide and we have added an option to suppress output diagnostics, which slow the code for large jobs.

FDS-SMV website

FDS-SMV download page

Installation Instructions

FDS Release Notes

Smokeview Release Notes

Thursday, November 5, 2015

CFAST 7 Released

Although this blog is intended primarily for news about FDS and Smokeview, we want to turn your attention for the moment to the zone model CFAST (Consolidated Fire And Smoke Transport). CFAST has been around since the late 1980s, and as the word "consolidated" implies, it was intended to unify into one code base various zone models that were developed at NIST and elsewhere in 1980s. It's been around for 25 years and has undergone 7 major revisions; the latest was released this week.

Many of you might be surprised to learn that CFAST is even still around. Why do we need CFAST when we have FDS? Doesn't FDS do everything that CFAST does, and more? Yes, it does, but FDS doesn't run in a second. Over the past decade, we've collaborated with the U.S. Department of Energy and the U.S. Nuclear Regulatory Commission, both of which still endorse the use of CFAST for its own inspectors and licensees in doing hazard analyses of high risk facilities. These analyses, or probabilistic risk assessments (PRAs), typically involve facilities with hundreds of compartments, many of which are simple and not heavily loaded with combustibles. CFAST is a great tool for doing "screening" analyses of these compartments. FDS is sometimes used in cases where the fire scenario does not conform to the basic assumptions of CFAST -- usually it is geometric complexity that demands CFD as opposed to a two-zone model.

Because we have a limited staff at NIST, we have tried to leverage all of the fire modeling expertise we have in maintaining CFAST. You will notice that the latest releases of FDS and CFAST are both installed in a folder called "firemodels" on a Windows PC. CFAST and FDS are in the same organization on GitHub, https://github.com/firemodels/, they use the same experiments for validation, they use the same basic installation process under Windows, and most importantly, they both use Smokeview.

CFAST 7 is a significant overhaul of the model, but not because we added new features. In fact, we removed many features, streamlined the source code and documentation, and improved (hopefully) the graphical user interface. We did this because we realized that CFAST was too bloated with unvalidated, undocumented, untested, and unnecessary features that detracted from its real value of being a simple, robust compartment fire model. How did this happen? Easy -- and it should be seen as a cautionary tale to anyone who wants to develop a new fire model. If you take a look at a survey conducted by the engineering firm Combustion Science and Engineering,

http://www.firemodelsurvey.com/ZoneModels.html

you'll notice that there have been over 50 zone models developed in the past 3 decades, but only 3 (in the survey anyway) are still under some kind of maintenance. The rest -- who knows? We suspect, based on our own experience, is that developing a zone model is fairly easy, but maintaining it is hard. We spend more time doing routine maintenance work for FDS than we spend developing new features. CFAST is certainly not as complex as FDS, but it still requires good documentation, a usable interface, verification and validation, and compatibility with evolving computer operating systesm. The team that developed CFAST has dwindled down to a few people, principally Rick Peacock, and its long term prospects are uncertain. At the very least, the latest overhaul of CFAST has put it in a better place with respect to long term maintenance, but no matter how good our current practices are, no model can sustain itself on auto-pilot. Those 50 plus zone models have essentially rotted -- even if one is able to recompile and run them, they would not pass a thorough quality review that we expect of fire models these days. These old codes were basically academic exercises developed by individuals or organizations who had no particular long term plan for them.

In the next few months, we're hoping to do some kind of survey to assess who is using CFAST so that we can plan for the future. Your input will be critical. There is no point in expending scarce resources on a model that is not used. We hope, however, that if you take a look at the new CFAST you will find that it still has a role to play in fire protection engineering. Don't be shy with your feedback. If something doesn't work, or even if something seems more difficult than it should be, let us know. CFAST uses GoogleGroups for general discussion:

https://groups.google.com/forum/#!forum/cfast

and GitHub for specific Issue Tracking:

https://github.com/firemodels/cfast/issues

Friday, October 9, 2015

Some Recent FDS Validation Exercises

With the release of FDS 6.3, we'd like to take this opportunity to point out a few notable FDS validation cases that have been added to the FDS Validation Guide.

NRCC Smoke Tower Experiments 

About 10 years ago, researchers at the National Research Council Canada conducted fire experiments in a 10 story tower that was specially designed to study fire and smoke movement in a high rise building. The experiments and subsequent FDS simulations are described in the following papers:

Y. Wang, E. Zalok, and G. Hadjisophocleous. An Experimental Study of Smoke Movement in Multi-Storey Buildings. Fire Technology, 47:1141–1169, 2011.

G. Hadjisophocleous and Q. Jia. Comparison of FDS Prediction of Smoke Movement in a 10-Storey Building with Experimental Data. Fire Technology, 45:163–177, 2009.

However, the FDS simulations were done with FDS 4 and up until now there has been no mention of these experiments in the FDS Validation Guide. So, if you wanted to cite these papers as evidence that FDS is an appropriate model for this kind of fire scenario, you would probably be challenged because FDS 4 was last released in 2005, about the same time the experiments were performed. Thankfully, Paul Tyson, a student at Ulster University (formerly the U. of Ulster), re-analyzed the experimental data and performed simulations with the latest version of FDS. He then worked with us to get these simulations permanently archived in the FDS Validation Guide. This was not an easy job. Paul had to dig up old plans of the building, talk to the various researchers involved, weed through the various experimental data sets, and then figure out how to use the new ventilation features in FDS to model the leakage in the building. In the end, Paul found that leakage was a significant factor in the modeling, but this information was not well-quantified in the existing documentation.

PRISME DOOR Experiments

PRISME is the name of a fire test program conducted under the auspices of the Organization for Economic Cooperation and Development, Nuclear Energy Agency (OECD/NEA). The experiments were conducted at the French Institut de radioprotection et de sûreté nucléaire (IRSN) at Cadarache. A variety of experiments were conducted to study ventilation effects, electrical cable failure, and leakage. The test reports are not publicly available, but an entire edition of Fire Safety Journal documented various experimental and modeling studies. Two notable papers are:

L. Audouin, L. Rigollet, H. Prétrel,W. LeSaux, and M. Röwekamp. OECD PRISME project: Fires in confined and ventilated nuclear-type multi-compartments–Overview and main experimental results. Fire Safety Journal, 62:80–101, 2013.

J.Wahlqvist and P. van Hees. Validation of FDS for large-scale well-confined mechanically ventilated fire scenarios with emphasis on predicting ventilation system behavior. Fire Safety Journal, 62:102– 114, 2013.

As with the NRCC experiments, the FDS simulations were not added to the FDS Validation Guide until recently, for various reasons. We would like to give thanks to Jonathan Wahlqvist of Lund University, who analyzed the HVAC system of the test facility using FDS. He provided us his FDS input files and now these calculations are permanently archived in the FDS Validation Guide. These experiments and simulations demonstrate that the HVAC functionality in FDS that was added by Jason Floyd over the past decade works quite well. Thanks to Jonathan for his perseverance in setting up the fairly complex series of ducts, nodes, and fans.

What you can do to help

Even with the help of students, it is a tremendous amount of work to add a new data set to the FDS Validation Guide. In our experience, fire experiments are typically documented in a variety of test reports, student theses, papers, and conference proceedings. Rarely is there a single comprehensive test report and electronic file containing the data in an easy to understand format. So if you are now performing validation simulations using FDS or considering it, please contact us as soon as possible. Waiting until your thesis is done or your paper published is usually too late -- we need to work with you now so that when you are done the input files, data sets, and documentation will be in a form that is easy for us to incorporate into our Validation Guide. The final paper or thesis is rarely good enough -- there is always information that falls between the cracks.

The value added in contacting us early is that we have developed a fairly elaborate set of scripts to analyze and compare experimental data and FDS simulations. We would want to get your data and results into this system early so that both you and the rest of the community can benefit from the added set of validation.


Tuesday, October 6, 2015

Realizability paper accepted

Issue 2261 posted by Dan Swenson of Thunderhead Engineering led to a revamp of the species transport scheme to guarantee realizable mass fractions.  These changes were incorporated into FDS 6.2.0.  The approach we developed has a few novel aspects and so Jason Floyd and I submitted the work for publication in Fire Safety Journal.  Today we got word that the final version has been posted online and may be viewed here.

Thursday, October 1, 2015

FDS-SMV 6.3.0 Release

Today we posted a new minor release of FDS and Smokeview, version 6.3.0.  Please visit the downloads page on the FDS-SMV website to download the bundle for your platform.

The changes made to FDS are in some ways quite minor and likely will not affect most users.  The two most important changes are (1) the heat release rate limiter has been removed from the combustion model and (2) new default values of radiative fraction have been assigned to select fuels (such as methane, which has a radiative fraction of approximately 0.2; a complete list is given in the FDS User Guide).

We have also implemented a multi-fuel model for the radiative fraction where we weight the local value by the reaction rate for each fuel.  Because of this change, the RADIATIVE_FRACTION input parameter has been moved from the RADI line to the REAC line.  This should be the only input parameter change required for this new version.

We realize there has been a lot of chatter on the discussion forum recently about running MPI on Windows machines.  Unfortunately, we have not been able to simplify this process as of yet.  Our best advice is contained in the wiki Running FDS MPI on Windows. Please let us know as soon as possible if you run into trouble with this latest release.  Issues may be submitted here.

GitHub pull requests are welcome!

This is the first release since our migration from Google Code to GitHub.  We have, I believe, managed to maintain a balance between the stability of our old Subversion workflow and the flexibility and power of a distributed Git workflow.  We have basically adopted what Atlassian refers to as the Forking Workflow [insert bad joke here].  Each project member "forks" the repository and sends pull requests to the project maintainer.  What this means is that YOUR workflow and MY workflow for FDS development are nearly identical---the only difference is that I can accept pull requests.  We hope this will take collaboration to a new level.

If you are new to Git, the following link may be helpful:

FDS-SMV Git User Workflow

What's on the horizon?

The migration from Google Code to GitHub was a fairly heavy lift.  But with this minor release we hope to be in a position in the coming year to focus on development of chemistry, complex geometry, and scalability for multi-mesh calculations.

Please continue to monitor progress on Issues you care about and present enhancement requests for features you feel would be helpful.

Monday, June 29, 2015

FDS-SMV has moved to GitHub

Dear Users,

As of today, the FDS-SMV code project is officially on GitHub.

The project GitHub site is

https://github.com/firemodels/fds-smv

The new website URL is

http://firemodels.github.io/fds-smv

Please note that the Issue Tracker has moved to

https://github.com/firemodels/fds-smv/issues

The migration of issues was not a seamless process.  A couple of things happened:  The issue numbers got out of sync and a few of the issues were dropped.  So, if you have an open issue you have been monitoring, please go to the issues site and locate it.  You cannot find it, please post a new issue.

We are hopeful that Git will fulfill its promise of easing collaboration for a large, open-source project.   We've outlined a suggested workflow here:

https://github.com/firemodels/fds-smv/wiki/Git-User-Workflow

Let us know if there are any problems with the website links or downloads. We look forward to your contribution and feedback.

Cheers,

The FDS-SMV Development Team

Tuesday, June 23, 2015

Please Postpone Issue Submission for GitHub Migration

Next week we will be migrating the FDS-SMV project from Google Code to GitHub.  There will be more to say about this transition over the coming days and weeks.  For the time being, please postpone submitting any new Issues or commenting on active Issues for roughly the next three days while we migrate the Issues over to GitHub.  Thank you for your understanding.

Plans are for the GitHub site to go live on Monday.  Stay tuned...

Monday, April 13, 2015

FDS 6.2.0 released

We just posted a release of FDS 6.2.0. This is a minor release, meaning that you can expect to see some changes in model results due to minor changes in various algorithms. We would urge you to finish out existing projects or studies with your current version and then upgrade to 6.2 as soon as you can. The reason why is that when bugs are reported for older versions, there is nothing we can do until the bug is observed in the latest version.

A significant change in this release is that there is now only one FDS executable for each of the three operating systems we support, Windows, Linux, and Mac OS X. Thus if you type "fds" or the old "fds_mpi", you will be issuing the same command. OpenMP and MPI are built in to this single executable and we urge you to take a look at the FDS User's Guide chapter called "Running FDS". There has been considerable confusion about OpenMP and MPI, and hopefully this new chapter will help clear some of it up. FDS still works like it always has from the command line if you just type

fds job_name.fds

but there are now a number of options you have to make the job run faster.

One other thing to note is that in the Windows release, we have switched from an older MPI scheduler to the one that is currently maintained by Intel. That is, when you run an MPI calculation by issuing the mpiexec command, you are using a newer version of the scheduler called "hydra_service". Those of you who are curious what this is, just do an Internet search. You should not notice a change in functionality from what we were doing in the last release, 6.1.2; it's just that a different background process will be running. Let us know as soon as possible if you notice anything different about the MPI on Windows.

Tuesday, October 7, 2014

FDS 6.1.2 released

A maintenance version of FDS has been released and is available for download at

https://code.google.com/p/fds-smv/

A few things to note:

  1. We are only releasing the 64 bit versions of the software from now on. Of course, the source code is available for anyone who wishes to compile the code. 
  2. We have switched the Windows implementation of MPI from MPICH to Intel MPI. Instructions are in the updated User's Guide. As we discussed in an earlier blog post, MPICH, the free implementation of MPI from Argonne National Labs, is no longer supported under Windows. The new Windows download of FDS has all of the necessary libraries to run Intel MPI and no extra download is needed, however our appeal for beta testing of the software was disappointing. Only a handful of testers volunteered. This is especially frustrating for us because we've heard no end of complaints about the fact that FDS 6 is slower than 5, even though it is more accurate, robust, and so on. If you want the code to run faster, support our efforts to make this happen.
  3. Those of you who have submitted bug reports in the last few months, please go to the Issue Tracker and see if the issue has been "fixed." If so, download the new version and verify that it has been fixed. If it has not been fixed, let us know. For 9 out of 10 issues, we never hear back from the person who originally posted the bug report. Thus, we never really know if the issue has been fixed. Sometimes years later we meet this person at a meeting or wherever and the person tells us that the problem is not fixed. We cannot make progress this way.

Wednesday, September 10, 2014

Windows Test Bundle for FDS Parallel Processing using Intel MPI

We are looking for volunteers to test a bundle of FDS that uses the Intel MPI libraries for Windows. The installation procedure is the same as that of the current release of FDS. The test bundle can be downloaded from:

https://drive.google.com/folderview?id=0B_wB1pJL2bFQcURod1UyZTJUaEE&usp=sharing#list

A few things. First, we have only tested this version on a Windows domain network; that is, a network where user accounts are centrally managed. It is OK if this network has a firewall; the installation script will set up the necessary exceptions to allow FDS to run in parallel across the network even with the firewall in place. Second, the test installation will install FDS 6.1.1, but the old MPICH executable (fds_mpi.exe) will be overwritten. So anyone who has MPICH working and wants to continue using MPICH until we officially release should avoid the test installation because it will not only overwrite the executable, it will also install the Intel variant of mpiexec. Finally, there is no need to install the MPI package yourself. Everything you need to run should be in the test package. At least, this is what we want to test.

Volunteers should post to the FDS discussion group whether they have succeeded or failed to run a simple test case. Do not spend too much time fussing with this -- if the installation procedure is not simple then we have to rethink it. We have found that the old MPICH procedure was fairly difficult, and we think we have a much simpler process now.

Friday, August 22, 2014

FDS formulation to appear in Journal of Computational Physics

I apologize for the shameless self promotion.  But we code grunts need citations, too.

I am happy to report that the formulation developed and implemented in FDS 6 will appear in the high impact, peer-reviewed Journal of Computational Physics.  Please cite the article in addition to the FDS Tech Guide when referring to the mathematical formulation.  Here is a link to the article:

A velocity divergence constraint for large-eddy simulation of low-Mach flows

Abstract:

The velocity divergence (rate of fluid volumetric expansion) is a flow field quantity of fundamental importance in low-Mach flows. It directly affects the local mass density and therefore the local temperature through the equation of state. In this paper, starting from the conservative form of the sensible enthalpy transport equation, we derive a discrete divergence constraint for use in large-eddy simulation (LES) of low-Mach flows. The result accounts for numerical transport of mass and energy, which is difficult to eliminate in relatively coarse, engineering LES calculations when total variation diminishing (TVD) scalar transport schemes are employed. Without the correction terms derived here, unresolved (numerical) mixing of gas species with different heat capacities or molecular weights may lead to erroneous mixture temperatures and ultimately to an imbalance in the energy budget. The new formulation is implemented in a publicly available LES code called the Fire Dynamics Simulator (FDS). Accuracy of the flow solver for transport is demonstrated using the method of manufactured solutions. The conservation properties of the present scheme are demonstrated on two simple energy budget test cases, one involving a small fire in a compartment with natural ventilation and another involving mixing of two gases with different thermal properties.

Wednesday, July 9, 2014

Good-bye to 32 bit apps?

We currently compile FDS and Smokeview for MS Windows, Linux, and Apple OS X. We release both a 32 bit and 64 bit version of each program for each OS. Maintaining the 32 bit apps is becoming increasingly troublesome, and we anticipate that in the coming year we will drop support for 32 bit operating systems. I suspect that this will not be an issue for Linux and OS X users, but we do not know about Windows. MS no longer supports Windows XP, the last OS to come with 32 bit as the default, but there might still be a lot of these machines around. So this is an opportunity for any and all 32 bit users to make their case for us to continue supporting 32 bit. If we do not see a significant call for keeping 32 bit, we will drop it to simplify our compilation and release activities.

FDS Parallel Processing using MPI (Message Passing Interface)

The latest release of FDS (6.1.0) runs with OpenMP by default; that is, the code uses multiple cores/processors of a single computer to process a single mesh. In other words, OpenMP is a "shared memory, multi-processor" form of parallel processing. We are now looking at the MPI version of FDS. This is where we use multiple computers to process multiple meshes -- distributed memory, multi-processor. For linux and OS X, we use Open MPI, an open-source, free set of MPI libraries. For Windows, we have been using MPICH2 (MPI-2), a similar set of libraries distributed by Argonne National Labs. We've recently learned that the MPICH team is dropping support for Windows, and a team from Microsoft has developed MS-MPI, a similar set of libraries as MPICH, to take its place. We have experimented with MS-MPI recently, but we discovered that MS-MPI is designed for use on a Windows HPC server, essentially a dedicated cluster of computers running a special OS specifically for high performance computing. MPICH had the advantage of running on an ordinary office network. We recognize that this is probably a common configuration for small engineering firms. Now with support for MPICH on Windows going away, and MS-MPI not quite what we are looking for, we are searching for another alternative. There are two, that we know of. First, Open MPI can, in theory, port to Windows, but we discovered that it involves installing Cygwin, essentially a unix/linux emulator for MS Windows. That proved to be quite onerous. Next, there is Intel MPI. At NIST, we use Intel compilers for both FDS and Smokeview releases. Intel sells its own MPI libraries as an add-on to its existing compilers. It also would allow us to distribute the run-time libraries needed for you to be able to run our compiled version of FDS. We are currently testing Intel MPI, and while we do, if any of you has any experience with it or comments in general on MPI, we'd like to hear from you. You can post your comments via the FDS-SMV Discussion Group under this thread.

Thursday, May 29, 2014

FDS 6.1.0 Released

We are releasing today a minor release of FDS, version 6.1.0. Note that a minor release means that there are some minor changes in functionality between FDS 6.0.x and FDS 6.1.0. For a list of these changes, consult the release notes:

https://code.google.com/p/fds-smv/wiki/FDS_Release_Notes

For most of you, the most significant change is that we are now releasing the OpenMP version of FDS as the default. In the past, we released the OpenMP version as an option. Now, if you run FDS in what we used to call "serial" mode, i.e.

fds job_name.fds

the executable will exploit multiple cores of your machine, typically four but it depends on your specs. We have found via benchmark testing that four cores seems to be the optimum number for a typical Windows-based PC. It provides approximately a factor of 2 in speed-up, although we would like to hear from you if you experience something dramatically different. More details are provided in the User's Guide.

Keep in mind that OpenMP and MPI are two very different kinds of parallel processing. The MPI version of FDS, which is still the same as it was, exploits shared or distributed memory architectures; that is, it can exploit multiple cores on a single machine or on multiple machines on a network. To make MPI work, you must  divide the computational domain into multiple meshes. However, OpenMP, which can only exploit shared memory architectures, can make either single or multiple mesh calculations run faster, but you are limited to a single machine. We are exploring the possibility of using both OpenMP and MPI to exploit multiple cores on multiple machines of a network. For the moment, we want to make sure that the OpenMP version works reliably.

The implementation of OpenMP in FDS was started by Christian Rogsch several years ago and more recently by Daniel Haarhoff. Thanks also to Boris Stock and Cian Davis who helped work out a few kinks in the new release. Thanks also to all of you who have contributed results of your benchmarking exercises. This greatly helps us better understand how both the MPI and OpenMP versions work under the various operating systems we develop for. We're going to continue to put together benchmarking cases as we continue to improve the parallel processing. Let us know via the FDS-SMV Discussion Group if there is any trouble with the new version.