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.
Monday, February 21, 2011
Subscribe to:
Posts (Atom)