Hydrodynamics and Turbulence

Following the announcement of the v6 beta release, we thought it might be helpful expand a little bit on some of the topics in the release notes.  Our aim here is to explain why certain changes were necessary or why certain choices were made in a way that might provide more insight than can be gleaned from just reading the formal documentation (though reading the guides is still highly encouraged!).

The focus in this article will be hydrodynamics and turbulence.  Hydrodynamics is the foundation of any CFD code, especially a reacting flow code like FDS.  Chemical species cannot react until they have mixed, and (in a diffusion flame) they cannot mix until they have been transported.  The velocity field, therefore, plays a critical role in fire dynamics.  In a model like FDS, other things being equal, the model for the turbulent viscosity determines the behavior of the velocity field and hence to a large extent the dynamics of the fire.

In v5, the turbulent viscosity was modeled by constant coefficient Smagorinsky (1963) (csmag), which has the drawback being overly dissipative (have you ever seen a 10-foot fire look like a candle flame?).  Thus, finer grid resolution was required to achieve accurate results.  But even highly resolved flames did not look qualitatively correct.  The reason: csmag is not convergent.  That is, the modeled term does not go away (as it should) when the grid is refined to the level of a DNS.

The original candidate to replace csmag was the dynamic Smagorinsky model (dsmag).  While this model added about 20% to the cost of computing the velocity field, in theory this cost could be recovered by achieving more accurate results (statistically) with coarser grid resolution.  So, dsmag was implemented and run through a battery of verification and validation tests with more or less satisfactory results.  On the plus side, we were getting very realistic-looking flames at moderate grid resolution.  But on the minus side, if the resolution was too coarse (often inevitable in engineering calculations), the flames were erratic---instead of a 10-foot flame looking like a candle, dsmag might produce an unstable ball of fire.

The solution to this dilemma came in the form of Deardorff’s model (1972), with a twist.  In the model Deardorff originally proposed, he solved a transport equation for the subgrid kinetic energy (sgs ke).  This strategy is expensive, but it allows for the inclusion of complex subgrid physics, like unresolved buoyancy production.  To avoid this cost, we employ a simple algebraic model for the sgs ke based on the scale similarity model of Bardina (1986).  The result is a model that is cheap and performs reasonably well at both coarse and fine resolution.  As an added benefit, the framework is now in place to utilize a transported sgs ke, a topic that might be worth exploring as FDS gets pushed to model large-scale outdoor flows in both wildfire and wind engineering applications.

While the new turbulence model is certainly significant, the change that really defines v6 is the new scalar transport scheme.  The ripple effects of this modification were not fully appreciated until a couple of years after the initial implementation.  What follows is the “saga of removing spurious temperature wiggles.”

Take FDS 5 and simulate a simple fire plume with open boundaries and 20 C ambient air temperature.  Now look closely at the temperature field near the corner of the burner.  You will see unphysical excursions of the local temperature to well below ambient, near 0 C.  Clearly this is undesirable.  What is not as obvious is that there are also unphysical excursions well above ambient, within the fire.  Of course, 1020 C versus 1000 C is not as dramatic a problem.

So why does this happen?  The root cause is central differencing in the solution of the density equation.  Purely centered schemes are notorious for generating dispersion errors---wiggles.  To combat this problem, v5 uses a boundedness correction which tries to prevent the scalar fields (density and species concentration) from going above or below defined limits.  With mass fractions the limits are easy to set (0 and 1).  With density there is only one hard limit (0).

In v6, we have decided to try another approach: total variation diminishing (TVD) scalar transport.  This is a fancy way of saying “we use just the right amount of upwinding.”  Pure upwind schemes are too dissipative (translation: inaccurate).  But TVD schemes are specially designed to track scalar discontinuities with minimal dispersion error and minimal dissipation.  This effectively solved the temperature wiggles problem.

Several TVD schemes are implemented in v6.  The default for LES is Superbee (Roe, 1986), so chosen because this scheme does the best job preserving the scalar variance in highly turbulent flows with coarse grid resolution.  The default scheme for DNS is Charm (Zhou, 1996) because the gradient steepening used in Superbee forces a stair step pattern at high resolution, while Charm is convergent.   A few other schemes (including Godunov and central differencing) are included for completeness; more details can be found in the Tech Guide.

These modifications were completed by the summer of 2009 (yes, you are reading that right).  It seemed at this point that we were very close to a v6 release.  Then… the wheels came off the bus.  In what we thought would be a routine pass through the verification suite, we hit a snag: our energy budget cases were off, by about 10%.  In addition, several of the validation cases now showed low upper layer temperatures---yep, by about 10%.

Hmmm.  A lot of head scratching ensued---two years, in fact, until Jason Floyd finally developed a test case that pinpointed the problem.  Imagine a T-mixer in which equal mass fluxes of a hot gas with a low cp (heat capcity) and a cold gas with a high cp mix and exit together.  The critical aspect of this case is that the flow paths are one cell thick and we artificially set the diffusivity and conductivity to zero.  Thus, any mixing is purely numerical.  What we found was that the outlet stream temperature was mass weighted instead of enthalpy weighted---there was no accounting for the variation in cp.  The pieces of the puzzle finally started to come together because another relatively recent development (actually in v5) was the inclusion of variable temperature specific heats.

The aftermath of this discovery was a torturous dissection of the energy equation (see appendix of the Tech Guide) illustrating that basic assumptions of the low-Mach number approximation can hide the effects of the numerical mixing from TVD transport schemes.  The bright side of the story is that through this analysis we were able to derive corrections for numerical mixing that force FDS to satisfy the discrete, conservative form of the sensible enthalpy equation, ultimately solving the temperature issues.

The benefit of the delayed release is that many other parts of the code were improved in the mean time.  So stay tuned for our next installment.

FDS-SMV 6 Beta Testing

It has been over two years since our last official release of version 5 of FDS and Smokeview, and we are ready to start beta testing FDS-SMV 6. Downloads are available at the home page fire.nist.gov/fds. Scroll down to the bottom of the page for the appropriate links.

Our primary interest in beta testing the new release is to determine if there is sufficient documentation to convert FDS 5 input files into FDS 6 input files. In general, the major parameters are the same, and the basic syntax of the input file is the same. However, some of the sub-models are significantly different, and there is no easy way to maintain perfect backward compatibility in FDS (Smokeview, in general, is backward compatible). By issuing error statements at start up, we want to alert you to important changes, which is why we prefer to stop the program with an error statement rather than accepting an outdated parameter or construct.

For those interested in helping with the beta testing, download the latest FDS 6 "release candidate" and try to run one of your old cases. Chances are that you will receive an error message. Chapter 1 of the new FDS User's Guide has a table that lists all of the parameters that have changed from FDS 5 to 6. We would like you to tell us how easy or difficult you find the conversion process, and whether or not the changes are well-documented. If you would like to be listed as a beta tester, send us via an email your name and affiliation, and we will compile a list in the new FDS User's Guide.

You can report your findings directly to us via email, or you can also start an Issue Tracker or Discussion Group thread. The latter two are preferable so that we can all learn about the changes in FDS and Smokeview. This will also provide us with the opportunity to describe in more detail the changes that have been made. Many of these changes are "under the hood," so to speak; that is, there have been changes to core algorithms that may not be apparent at first glance. But we can discuss these improvements as we look at your cases.

Progress on FDS 6

Every once in a while, early on a saturday morning, I decide that I'm going to fix that leak under the bathroom sink, or repair the squeaky door hinge on the kitchen cabinet, once and for all. Nine times out of ten I find other things wrong, like rotten wood behind the sink, or a loose screw holding the cabinet to the wall. One thing leads to another and before long I've torn the whole room apart, and my wife is on the phone with the plumber or handyman. Which is why, by the way, monday morning is the busiest time for plumbers and handmen.

This is a good analogy for our development of FDS 6. We've been working many issues for quite some time, and making great progress, but we've thrown up alot of dust in the process. One thing just leads to another. We get asked often "when will FDS 6 be ready?" and our answer is "when it is better than FDS 5." What does "better" mean? Better physics, better numerics, better documentation -- better everything, and that's a tall order because FDS 5.5.3 has been working fairly well, or at least we have not seen too many serious bugs reported in the last few months.

But if FDS 5.5.3 is working well, why change it? Because there are long term goals for the program that simply cannot be achieved within the current framework. Things like Adaptive Mesh Refinement (dynamically adapting the local mesh to local conditions), non-rectilinear obstructions that are not tied to the grid, really big calculations running on hundreds or thousands of processors, and streamlined designation of material properties. All this without degrading the current ability of the model to track smoke and heat from specified fires, a very common design application.

One of the most challenging aspects of the current overhaul is that the new algorithms work well at fairly good grid resolution, and we're happy with the improvement in grid-independence as the mesh is refined. But we're still not completely satisfied with the results on very coarse grids. Some would ask why we should expect good results on bad grids. Two reasons -- first, most fire simulations start with a very small fire that is not well-resolved initially. Second, most simulations involve fairly large spaces. It's hardly worth developing a fire model that can only simulate fires that are just as easily re-created in a test laboratory. With relatively small fires in relatively big volumes, it is not possible to capture every detail of the fire behavior at all scales. We definitely want to push the limits and increase what we call the "dynamic range," but we know that even with multiple meshes, and eventually AMR, it's not always going to be possible to capture everything in a practical simulation. So we want to ensure that the results of the calculation are reasonable at a variety of grid resolutions.

We'll follow up this post with more details on different aspects of FDS 6 development, written by the various team members working the issues. In the next few months, we're going to ask for volunteers to run beta tests of the new version -- in particular to run cases with FDS 5 and 6 to see if there are serious problems. For those of you who are students working with FDS, consider trying out the new version (available via the GoogleCode SVN check-out) and reporting your findings to us. It may be a bit frustrating working with a moving target, but we think it's a more valuable educational experience to be working along side us developing new techniques for simulating fire rather than just running existing code.

Release of FDS 5.5.2

A maintenance version of FDS has been posted to the Downloads page. This is version 5.5.2. Unless there are serious bugs to fix, this might be our last release of FDS 5. We are working on FDS 6, and those of you who participate in the group discussions will have already heard alot of chatter about FDS 6. One thing to keep in mind is that the transition from FDS 5 to 6 will be relatively transparent to most users. We are not planning on major changes to the input parameter names or file structure. The reason for changing from 5 to 6 is that there are going to be changes to the basic algorithm that warrent a change in major release number.

As always, for those of you who have submitted bug reports for FDS 5.5.1, please check that the new version fixes the problem if we have claimed to have fixed it. This is a very important part of our quality control, but unfortunately only about 1 in 10 users follow up on bug reports and actually verify that the fix has worked. Even worse, we often find out, months after fixing something, that the original submitter of the bug report continues to use the work-around that was suggested when the report was first submitted. That's not a good way to make progress.

Google moderator for FDS-SMV

Dear Group:

In an effort to better accommodate the needs of the community moving forward, we have set up a Google moderator series to help gather feedback on questions concerning FDS-SMV development.

http://goo.gl/mod/bp0n

To get things started, I have submitted a question to you, the group, regarding the default output frequency of Plot 3D (.q) files. Please vote on this idea.

http://goo.gl/mod/ygrO

Also, feel free to submit other ideas and comment on the ideas already present.

Our feeling is that this forum will help us sort developmental priorities and answer simple questions like the one presented above. We hope this will encourage participation from the community at large and that the voice of those who do not regularly chime in on the discussion group can more easily be heard.

Best,
Randy