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

parallel processing on the Windows command line

The purpose of this post is to explain the use of a new utility named background.exe - what it is and how it might be useful. It is available with the smokeview 5.5.5 windows installation just posted on the download site at
http://code.google.com/p/fds-smv/downloads/list


As you all know, MPI is a software library used to enable parallel processing at the program ie FORTRAN source code level. This enable ONE FDS job to make use of multiple CPUs thereby speeding up the calculation. It is often the case however that you are doing a parameter study or running a verification suit - ie you have a long list of FDS jobs to run. Typically you would create a windows batch file (.bat) containing a list of commands like

fds5 casename_1.fds
....
fds5 casername_n.fds

On a Windows system, each entry in the above list will not start until the previous entry has completed - even if your computer has multiple cores or CPUs.

Unix/Linux based systems have the capability to put a computer job in the background, meaning that when you run the job, control returns to you immediately allowing you to run another job. With computers with multiple cores or CPUS you can then run more than one job simultaneously.

I didn't see a way of doing this on a Windows system so, I wrote a little utility called background that does just that.

Here is how you might use it with FDS

background -d 1.0 -u 90 fds5 casename.fds

This command runs "fds5 casename.fds" after waiting 1 s and ensuring that the CPU usage is less than 90 %. If the CPU usage happens to be more than 90 %, "background" waits to submit the fds5 command until the usage drops below 90 % then runs fds5 casename.fds.

The purpose of the delay before submitting the job to give windows a chance to update usage from previous invocations. (not really sure if this is needed. This feature is a fail safe to enusure that a large number of jobs are not submitted at once).

The background utility is designed to use in a windows batch file. Say you have a list of 5 FDS jobs you want to run in a .bat file. On a windows computer you would have a batch file with the contents something like

fds5 case1.fds
fds5 case2.fds
fds5 case3.fds
fds5 case4.fds
fds5 case5.fds

Using background and if you accept the default you would change your script to something like

background fds5 case1.fds
background fds5 case2.fds
background fds5 case3.fds
background fds5 case4.fds
background fds5 case5.fds

(or you could add -d and -u options ) On my system, I can make use of all 4 cores cutting the run times by a factor of 4.

Type background -h to see help info. Let me know if you have any questions.

Smokeview Maintenance Release 5.5.5

A new maintenance release of Smokeview , version 5.5.5, has been posted at http://code.google.com/p/fds-smv/downloads/list . Besides bug fixes and a few other enhancements, I added a new way to manipulate the scene, inspired by a question on the users forum. Basically you can now make use of all 3 mouse buttons (on a 3 button mouse) to manipulate the scene.

LEFT – same as before – rotate the scene

MIDDLE – move in, out, left, right

RIGHT – move up and down.

The right mouse button was used for menuing. So to use the RIGHT mouse button for scene manipulation you first have to turn menuing off. Do this by press the M key . To turn menus back on press the M key again.

This feature is a work around for a problem that occurs with the Linux version of Smokeview. It did not support vertical scene movement because Smokeview could not detect the use of the ALT key.