GUI for FDS, state and developments

[Emanuele Gissi]

Hi,
after teaching in many fire safety engineering courses I am convinced
that a simple GUI for FDS is strongly needed to lower the entering
barrier.

Some sparse information:

1) In my dreams a GUI for FDS should be:
- simple: only basic FDS features should be presented to the user. In
my opinion, hand editing is still the best way to deeply know your
models.
- multiplatform and opensource, as FDS is.

2) To my knowledge, Pyrosim (http://thunderheadeng.com/pyrosim) is the
only existing GUI for FDS
(Disclaimer: I am not affiliated, nor using it in my daily work) It
seems very user friendly. But it has some cons: MS Windows only,
expensive, closed source.

3) As Kevin wrote in:

http://groups.google.com/group/fds-smv/browse_thread/thread/8af4f46fcb7f8201/5d043180332a4d7d?lnk=gst&q=gui#5d043180332a4d7d

there should be another FDS GUI in development by Reaction Engineering
Inc.
I tried to contact them but I never had the chance to speak with them.
So I don't know anything about this development. Will it be open
source? multiplatform?

4) I am pretty sure that many of us developed some filters from common
CAD formats to FDS input.
I am in contact with researchers of an Italian University, who
developed a filter from STL format to FDS that optimize the
description of round geometries. It's fortran code and they are ready
to release it as open source.

5) I contacted some developers of the following two (open source,
multiplatform, free) projects that could be easily extended to provide
a sort of GUI for FDS:
http://www.blender.org
http://www.salome-platform.org
These developers seemed very interested in such a development; with
the support of our community, of course.

Question time to the community:

6) What are your dreams for a GUI for FDS? Do you share my point of
view?

7) Do you have any other information about existing GUIs for FDS? or
geometry conversion tools?

8) Could you be interested in joining the forces and helping one of
the developments described in point 5?

As usual, I thank you in advance.
Emanuele Gissi

[Kristopher Overholt]

As for point number 3, I got a response from REI a couple of weeks back and have been meaning to post it:

"Hello,

Thank you for your interest in our FireExplorer (previously FireStudio) project. At present, we have passed the half-way point in our project. We are anticipating having a beta release available near the beginning of 2009.I can add you to the list of potential beta testers if you would be interested.

Here is a quick overview of the user interface:
1) it is targeted toward firefighters for training purposes and strongly emphasizes ease-of-use
2) it is a closed-source, commercial application (developed under Air Force SBIR funding)
3) it is currently targeted only for Microsoft Windows (XP/Vista 32/64 bit)

I will also post this information to the discussion group.

Best Regards,
Dave Swensen
Reaction Engineering International"

As for your other points, I agree that this would be a good area for a community supported GUI for FDS. Now with such an active FDS community online, we should be able to sustain development on something like this, and I agree with all of your points about open-source, cross-platform, etc.

As far as the functionality, I feel that the biggest areas that a GUI would streamline would be geometry and spatial tasks like device and surface placement as well as organizing lists of materials/surfaces/etc. I also know that Bryan Klein was doing some preliminary work with Google Sketchup (free, but closed source and proprietary) and the Ruby language.

I would be willing to put some effort in organizing and helping with the development. Feel free to contact me with further ideas and communication.

--
Kristopher James Overholt
Worcester Polytechnic Institute
Fire Protection Engineering Graduate Student
Secretary, SFPE WPI Student Chapter
Mobile: 832.247.7507

[Bryan Klein]

This is an area of great interest for me, and I am curious about the
meaning in point 1 of your message. You say 'simple' and 'only basic
features' what are these features in your opinion?

What are the most difficult/tedious/horrible, parts about building an
FDS Input file by hand that you would like a GUI to help eliminate or
reduce? Where are the barriers you see in classes? I have my list,
but it would be nice to compare to others.

I like free and open source too, but unless the developers are instead
selling services such as consulting or training, it is not very viable
economically to support GUI development full time. In addition,
providing auxiliary services takes time away from further development
and support. How would you imagine this issue resolved?

In regards to your question #7, I know about some work presented at
IAFSS regarding BIM IFC data models and conversion to FDS.
http://iafss.haifire.com/html/iafss/symposium/9/abstracts/9-212.htm
Also there has been some work by a major CAD software vendor that
sounds promising, but is still in early development.
http://tinyurl.com/vw-fds This would likely be an add-on to the CAD
package.
I have heard some hints at other upcoming FDS related tools, but don't
have any real details yet.

I have many more questions, but answers to the few above would be a
good place to start.
-Bryan Klein

[Emanuele Gissi]

I wanted to reply today. But I did not succeed.
Now it's time to rest a little, I'll be back on Jan, 7th refilled of
new energy.
So, happy new year to everybody!
Emanuele Gissi.

On 22 Dic, 05:03, "Bryan Klein" <bryanwkl...@gmail.com> wrote:
> This is an area of great interest for me, and I am curious about the
> meaning in point 1 of your message.  You say 'simple' and 'only basic
> features' what are these features in your opinion?
>
> What are the most difficult/tedious/horrible, parts about building an
> FDS Input file by hand that you would like a GUI to help eliminate or
> reduce?  Where are the barriers you see in classes?  I have my list,
> but it would be nice to compare to others.
>
> I like free and open source too, but unless the developers are instead
> selling services such as consulting or training, it is not very viable
> economically to support GUI development full time.  In addition,
> providing auxiliary services takes time away from further development
> and support.  How would you imagine this issue resolved?
>
> In regards to your question #7, I know about some work presented at

> IAFSS regarding BIM IFC data models and conversion to FDS.http://iafss.haifire.com/html/iafss/symposium/9/abstracts/9-212.htm

> Also there has been some work by a major CAD software vendor that

> sounds promising, but is still in early development.http://tinyurl.com/vw-fds This would likely be an add-on to the CAD

> package.
> I have heard some hints at other upcoming FDS related tools, but don't
> have any real details yet.
>
> I have many more questions, but answers to the few above would be a
> good place to start.
> -Bryan Klein
>
> On Fri, Dec 19, 2008 at 5:21 PM, Emanuele Gissi
>

> <emanuele.gi...@gmail.com> wrote:
>
> > Hi,
> > after teaching in many fire safety engineering courses I am convinced
> > that a simple GUI for FDS is strongly needed to lower the entering
> > barrier.
>
> > Some sparse information:
>
> > 1) In my dreams a GUI for FDS should be:
> > - simple: only basic FDS features should be presented to the user. In
> > my opinion, hand editing is still the best way to deeply know your
> > models.
> > - multiplatform and opensource, as FDS is.
>
> > 2) To my knowledge, Pyrosim (http://thunderheadeng.com/pyrosim) is the
> > only existing GUI for FDS
> > (Disclaimer: I am not affiliated, nor using it in my daily work) It
> > seems very user friendly. But it has some cons: MS Windows only,
> > expensive, closed source.
>
> > 3) As Kevin wrote in:
>

> >http://groups.google.com/group/fds-smv/browse_thread/thread/8af4f46fc...

[Tim]

As a independent fire consultant company, we are currently developing
a GUI for FDS v5, initially, for our day-to-day work. This should
cope with typical issue such as material, ventilation, fire and
combustion specification. We hope that this may help the user
community in long term.

[DavidShep]

I agree that a very simple interface for FDS would be very useful.

NIST already has a very mature, windows based, and easy to use GUI for
developing a computer model. It is the interface for CFAST. CFAST
already uses Smokeview to view the output data.

It would be very easy for the CFAST GUI to create an FDS data file
where every CFAST compartment was defined as an FDS mesh.

[dr_jfloyd]

I don't think this is nearly as easy as you think. Meshes have to
line up and compartment dimensions may not in and of themselves lend
to that without a good deal of logic having to make assumptions on
gridding and how to define walls, etc. Not to mention that the CFAST
GUI is not going to support all of the other inputs required by FDS
without a significant amount of development.

[DavidShep]

A simple interface wouldn’t need to give the user access to advanced
FDS features. An FDS model that does essentially what CFAST does would
be great for classes where we teach fire dynamics concepts.

With no modification the CFAST GUI defines a model consisting of a
series of interconnected rectangular compartments. In the CFAST GUI,
the user adds details to define fires, targets, detector locations.
In CFAST, the user visually verifies his model description using
Smokeview.

For output the GUI could automatically include a 3D vector slice of
temperature, and boundary files of heat flux and surface
temperature.

Defining aligned meshes would not have to be difficult. The interface
could limit the grid size to a single global size or it could require
grid spacing to be even multiple (e.g. 0.15, 0.3, 0.6, etc.).

For compartment geometries, the GUI could simply round-up the
compartment boundaries to the grid. The only small challenge to
creating the geometries would be that CFAST treats adjacent
compartments as closed except at vents, and FDS allows free flow when
two meshes touch. This could be easily fixed by either modifying FDS
or by adding OBST at compartment boundaries.

[Bryan Klein]

People keep saying words like 'easy' and 'very simple' without
defining how a very simple tool could help?
What difficult parts of building an FDS input file could be alleviated
with a simple tool?

From what I understand, the most difficult parts of building an input
file are...

- Creation and Placement of Geometric Objects; Meshes, Obstructions,
Holes, Vents, Slices, Devices, etc.
This is especially true in modeling real world scenarios, with complex
shapes and placement of similar items in many places throughout the
domain. As far as I can tell, this issue cannot be solved with a
simple GUI, unless this simple GUI is paired with a fully functional
3D modeling application. Ultimately an Architectural/Mechanical CAD
application that can intelligently convert highly detailed elements
into simplified OBST representations. Then built in tools for defining
Meshes, Slices, Vents, DEVC, etc. None of this is simple or easy.

- Material Properties
Defining a material in the input file is only a few lines at the most.
This is fairly simple to do, so a GUI to click around in seems like
much more trouble than it is worth. The hard part is getting the
input parameters to type in and knowing if the input parameters are
applicable for the particular case. This would require the creation
of a global material properties database that has all of the
validation data and experimental results detailed for each property.
This is not something a simple GUI can do.

-Control (CTRL) Logic
This by definition is something that requires some thought, and at
best I could imagine a 2D drawing GUI like LabVIEW that lets you build
and test logic functions. But this is not a simple GUI to build or
use. It will take some understanding and skill to assemble complex
controls. I would bet that this tool would be required by less than
5% of FDS users. Which would be considered when justifying the effort
required to build a tool like this.

The rest of the input file is trivial after this, HEAD, TIME, MISC,
DUMP, ISOF, etc. are only a few lines in the file.

To me it seems that the best GUI is a great text editor that allows
FDS input file syntax highlighting and code completion and possibly a
built in help/doc system that would let a user quickly lookup
information about the namelist parameters that are available for each
namelist group. I use TextMate on OS X and it does much of this for
me. I have seen a gvim syntax file generator script, and other
similar tools created by users.

Maybe I am off base here, but it seems that a simple GUI with minimal
functionality would not be useful for the majority of FDS users.
Unless it is tied to some more complex system that addresses some of
the hard problems.
Oh and cross platform would be nice too. :)

-Bryan

On Dec 31, 9:11 am, DavidShep <david.shepp...@atf.gov> wrote:

[Bryan Klein]

In this case, a simple tool as you describe would be great.
And rarely, if ever used again outside of the second week in FDS 101
class.

If I was modeling a case that was as simple as could be built with a
zone model, I would probably not waste time running FDS and use CFAST
instead. Which works really well for a few boxes connected with
doors. It even handles more complex room shapes, sprinklers, etc.

Most users need tools to help with real problems, after they
understand what FDS is and how it works.

We have so many example input files in the repository, that you could
spend a year going through them and seeing how many different modeling
techniques are implemented in FDS syntax. This would teach new users
way more than a simple CFAST-ish GUI will ever do.

So, I am not sure why any amount of effort should be put into a tool
with such a limited range of applicability.

As a side note, CFAST is open source too, and can 'easily' be checked
out and modified by anyone with enough interest. http://code.google.com/p/cfast/
If I am missing something and someone feels that making an FDS GUI out
of the CFAST framework is a good idea, I would encourage them to
checkout the code and get started. You should probably also work with
the developer Rick Peacock, as he may be interested in offering some
support to this endeavor.

-Bryan

[dr_jfloyd]

Easy as fixing FDS or adding OBST at boundaries? How easy is this?
How many lines of code to determine where the OBST should be and to
handle all the potential poor user inputs (for example compartments
that are not adjacent but the user defines connecting vents for)?
What changes in FDS get made to do this that don't impact the user not
using the CFAST GUI? What happens when grid rounding causes
compartments to overlap or become non-adjacent? What if compartment
dimensions do not result in nice (2^j 3^k 5^l) grid numbers?

CFAST doesn't need to define the geometric location of the fire, it
just exists. In FDS this must be defined explicitly.

Keep in mind that very efficient programmers code at 20 - 25 SLOC/day
(software lines of code) over the life of a project. The GUI needs to
be maintained as FDS evolves and inputs change.

On Dec 31, 10:09 am, DavidShep <david.shepp...@atf.gov> wrote:

[DavidShep]

I would like to have a simple interface that I could use in classes
and that I could teach senior fire investigators to use. I would also
like a method to make quick models that could be used for preliminary
assessments. We currently use the NUREG spreadsheets and CFAST for
quick analysis. I know that FDS models consisting of simple
interconnecting rectangular compartments and fires with predefined HRR
would be very useful for users of FDS. We don’t use FDS for
preliminary assessments now because the overhead is too high.

Most of the advanced issues like material properties and control logic
are not needed for a preliminary model. Besides, defining these types
of inputs is beyond the capabilities of almost all practicing
engineers using FDS. We don’t even know how to accurately measure
most of these properties at this time.

I agree that for an advanced user a text editor is the preferred
method of developing a detailed model. I use Excel when I generate my
custom models.

I feel that there is a need for a simple user interface that would
develop a limited FDS model.

[dr_jfloyd]

A simple interface could be useful, the question is who is going to
develop and perhaps more importantly maintain it? What you have
described sounds simple, but the actual software coding to accomplish
it is not going to be trivial. From defining software requirements
through developing and testing the software is going to be a
significant amount of someone's time (time = $$).

One can almost guarantee that the first real user will immediately do
something that should be possible that will break it. Now who fixes
the bug?

Such a simple tool will have limited commercial value. How much would
you be willing to pay for an FDS tool that only supports very simple
simulations? $0, $10, $100 ? My guess is few people would want to
pay much of anything for a tool that is highly limited in its
usefulness. So my guess is no real potential for this to be developed
commercially. A student / university could develop this as a project,
but those efforts almost always result in software that is
unmaintainable once the students who wrote it graduate.

[Kevin]

This is a great discussion.

From what I know about the US Air Force SBIR (Small Business
Innovation Research) grant to REI (Reaction Engineering), the intent
is to create a unified interface for FDS and CFAST that could be used
by air force engineers and others in the US Government, at the very
least. Anyone from REI who reads this can correct me if I'm wrong. I'm
also under the assumption that the REI GUI would be available, in some
way, to other Feds. I also have gathered that Thunderhead Engineering
is cooperating with REI, but I don't know if they are developing
something unique from PyroSim. Anyone from REI or Thunderhead can
chime in, and please don't feel that it is inappropriate to talk about
commercial issues because that is a big part of the discussion.

Just an FYI, at the annual NIST fire conference in April (28-30),
we're planning an all day workshop on fire modeling, mainly FDS and
Smokeview related, but we'd like to talk about CFAST, the "legacy"
models, maintenance, interfaces, and so on. I'd like to invite reps
from Thunderhead and REI to come and discuss these issues, along with
others who have ideas on the subject. The workshop will go beyond the
traditional scholarly presentations that address only technical issues
because I think it is important that we discuss issues such as
commercial development, financial support, code maintenance, the roles
of government, academia and the private sector, etc, in ways that in
the past have not been brought up. Alot of good points have been
raised in this Discussion thread that we typically don't discuss at
public meetings even though they are vital as we move forward.

On Dec 31, 11:19 am, DavidShep <david.shepp...@atf.gov> wrote:

[Dave McGill]

DavidShep wrote:
> I would like to have a simple interface that I could use in classes

> and that I could teach senior fire investigators to use. ......
Hi Dave,

I can't speak for Thunderhead Engineering, but they have always provided
us with free classroom access to PyroSim.

Regards

Dave

Dave McGill
Professor
School of Fire Protection
Seneca College of Applied Arts and Technology
1750 Finch Ave. E
Toronto, ON, M2J 2X5, Canada
416-491-5050, ext. 6186

[charlie.thornton]

Dave McGill is correct. We have always provided free licenses for
classroom use. This includes trainings that last a few days as well
as multi-semester academic situations. Ideally, some of these
students will later decide that PyroSim has something to offer beyond
a text editor.

In terms of Thunderhead/REI collaboration - at this point, it looks
like collaboration might be too strong a word. I honestly don't know
what form their software will take or what kind of user it will
target. We've always tried to gear PyroSim toward users who
understand fire and understand FDS to some extent already. The target
user is someone who /could/ use FDS with a text editor, but who wants
to save some time (e.g. geometry editing) and doesn't want to have to
memorize the syntax.

The key word that comes up again and again is "simple." I suspect
this has more to do with how easily a user can "feel" the relationship
between various GUI operations and the FDS input file generated by the
GUI. I doubt it has much to do with the actual number of features.
Identifying places where PyroSim is non-simple (confusing, fiddly,
overcomplicated) is something I'm very interested in and would be
happy to discuss (thor...@thunderheadeng.com).

- Charlie
(PyroSim Developer)

On Dec 31 2008, 2:12 pm, Dave McGill <david.mcg...@senecac.on.ca>
wrote:

[Simon Ham, FiSEC, UK]

Accepting that I am an ‘old cumudgeon ’ I do think there is a need to
consider whether it is sensible to make FDS too easy or too accessible
by means of a new front-end GUI.

One of the features of FDS I quite like is that it is daunting to get
to grips with and that you have to work at it quite hard to get it
functioning. After that you join the users group you discover how
clever and intimidating some of the users and developers are. This
initially undermines your confidence and then you come to the
realisation that you cannot know everything there is to know about
computing, fire science and sophisticated mathematics but you are part
of a wider group and most people are prepared to take the time to help
you and to discuss your problems and issues.

I know there are students who seek to be spoon fed and there are
academic pressures to make things easy for them but there are risks
associated with this.

I think there are significant benefits in FDS users having to satisfy
a basic entry requirement:

1. A reasonable understanding of the use of computers,

2. a basic knowledge of fire and

3. sufficient enthusiasm to spend the necessary time getting to grips
with it.

I disgree with those in the fire community who passionately feel that
making FDS freely available is like letting the genii out of the
bottle and that the use of CFD modelling should be restricted to a
limited number of high priests capable of casting their magic runes
and passing the results on to the less worthy. The real value of FDS
lies in its symbiotic relationship with its users and their
diversity.

I nevertheless despair sometimes when I read some contributions to the
group from people who have not taken the time to read the manuals and
who have leapt into using ‘Pyrosim’ without making the effort to
understand the basics of meshes, their sizing, interfacing between
them and how Smokeview relates to them. This is not meant as a
criticism of Pyrosim.

In a similar way there are others who seem expect too much from what
remains a sophisticated mathematical model capable of handling fluid
flow well but some other aspects of fire less well and remain
blissfully ignorant of its limitations. All this is despite the road
map and Kevin’s patient explanations as to inevitable compromises that
result from developing a sophisticated system capable of running on a
desktop PC.

I would not want to see FDS bloated with features pandering to low
ability users only capable of being run on high end parallel
processing computer networks.

The introduction of a simplified GUI at the front end would not make
FDS a better modelling system.

Simon Ham
Fire Safety Engineering Consultants Ltd.


On Jan 5, 5:54 pm, "charlie.thornton" <charlie.thorn...@gmail.com>
wrote:

> Dave McGill is correct.  We have always provided free licenses for
> classroom use.  This includes trainings that last a few days as well
> as multi-semester academic situations.  Ideally, some of these
> students will later decide that PyroSim has something to offer beyond
> a text editor.
>
> In terms of Thunderhead/REI collaboration - at this point, it looks
> like collaboration might be too strong a word.  I honestly don't know
> what form their software will take or what kind of user it will
> target.  We've always tried to gear PyroSim toward users who
> understand fire and understand FDS to some extent already.  The target
> user is someone who /could/ use FDS with a text editor, but who wants
> to save some time (e.g. geometry editing) and doesn't want to have to
> memorize the syntax.
>
> The key word that comes up again and again is "simple."  I suspect
> this has more to do with how easily a user can "feel" the relationship
> between various GUI operations and the FDS input file generated by the
> GUI.  I doubt it has much to do with the actual number of features.
> Identifying places where PyroSim is non-simple (confusing, fiddly,
> overcomplicated) is something I'm very interested in and would be

> happy to discuss (thorn...@thunderheadeng.com).

[Kevin]

Well said. Here's another reason why we should be careful what we wish
for -- the use of a "database" of material properties in FDS versions
1 to 4 was intended to simplify the prescription of boundary
conditions. We foresaw, even before PyroSim, a simple "drop down" menu
would make it easy for the user to tag different surfaces with
properties. But we also recognized that many of these properties were
not known, and worse, that the FPE community had not even reached
consensus on their meaning or how to measure them. Take "ignition
temperature," for example. But we figured that if the model became
widely used, the "database" would naturally grow, as would the
knowledge of how to define and measure properties. It didn't turn out
that way. In my opinion, there seemed to be less incentive for more
research in the solid phase because many assumed that the "database"
was done. What more work was there to do?

I agree that there should be some tractable way to introduce a
complicated geometry into FDS, especially with the tremendous growth
of CAD and its routine use in building design. But I worry that the
easy "drop down" menu of material properties could hinder the research
in this area. When I do an FDS calc, approaching it like a new user
would, I find the prescription of material properties to be the most
difficult part, and I don't believe that a GUI is going to help me
much except for simple, non-combustible materials like steel and
concrete. When I have to model a burning pile of rubbish, I'm
basically on my own. Which is what modeling is all about. The real
skill in using FDS is not really making a complicated structure, but
rather making the necessary approximations to mimic the burning item
-- a mattress, pile of sticks, tray of cables, heap of garbage. I
would not want to see things like this on a drop down menu.

On Jan 6, 5:59 am, "Simon Ham, FiSEC, UK" <simon...@btconnect.com>
wrote:

> > > 416-491-5050, ext. 6186- Hide quoted text -
>
> - Show quoted text -

[R_Webster]

During my years of experience using FDS, I have created several FDS
user interfaces with AutoCAD. These interfaces have generally been
tailored to satisfy the requirements of my employer at the time.
However, are generally applicable to any fire modeling project. If
there is a need in the industry for such an interface, I would be open
to the idea of releasing these tools to the public. Feedback would be
appreciated.

My experience suggests that making FDS easier to use opens the door to
many unqualified potential FDS users. For that reason, I would suggest
any FDS GUI be limited to defining the locations of obstructions,
vents, and devices. Extending the functionality of an interface beyond
that suggests that the interface is making assumptions for the user.

An FDS user interface that has no function other than converting the
modeled geometry from a CAD format to an FDS input file format
contains no assumptions. As an engineer, any assumptions that I make
(or software used) must be supported by testing or some other means of
verification and validation. NUREG-1824 provides me with some
justification for use of FDS. However, if an interface with FDS also
makes assumptions, about the thermophysical properties, burning
characteristics, etc. of a material, then these assumptions also
require validation.

In my opinion, there is no need for a FDS GUI in an academic
environment. A GUI for FDS has a primary function of describing
complex geometries. In an academic environment, the focus is on
understanding concepts like thermally-thin and thermally-thick, fuel-
lean and oxygen limited, combustion stoichiometry, buoyancy,
stratification, etc. All of which can be described with four walls, a
fire, and a target.

Robert Webster
robert....@areva.com

[szilagyics]

My opinion may be strange, but if you think it over...

First: I understand if I want to make a real complicated building in
FDS it may be too long and too hard work.

If FDS would be really easy software with great database many people
will work with FDS. It's good. But I know I can make mistakes too
easy. Example: I use pyrosim and I think this software is really good
in drawing. But If I don't know the little details of FDS I won't set
the values in the deeper windows.
If there will be too many faulty articles. The honor of FDS will be
smaller.
I think if I use FDS I need to be really careful.
If I'm a beginner and I fight my war with FDS, I will became
experienced and careful user.

So I know the drawing in fds too heavy at a complicated building.
But everybody who wrote in this Forum (in all themes) are experienced
and careful people. I think they have learnt it with hard work.

I don't know what is the good solution. Just I think it from GUI for
FDS.

Regards,

Csaba

> robert.webs...@areva.com

[Emanuele Gissi]

Hi, I am back from holidays. When I started this discussion I never
imagined it could go so far!

Please, let me try to summarize the discussion, citing contributions:

1) What we need:

A tool (not necessarily a GUI) that eases the creation and placement
of geometric objects (meshes, obstructions, holes, vents, slices,
devices...) [Kristopher and Bryan Klein].

For now, managing material properties, control logic, and the rest of
the file can be left to editing a text file: "it seems that the best

GUI is a great text editor that allows FDS input file syntax
highlighting and code completion and possibly a built in help/doc
system that would let a user quickly lookup information about the
namelist parameters that are available for each namelist

group." [Bryan Klein]

2) What we don't need:

- A new 3D CAD. We don't have the resources to develop one.
- A competitor for Pyrosim. If you need Pyrosim, go and buy it!
- A super CFAST. If you need CFAST, just use it.
- "Drop down" menu of material properties, that could hinder the
research in this area [Kevin]
- Lower entering barriers, as I wrongly stated in my first message.
The inspiring message from Simon Ham was very convincing.

3) Goal of this new tool:

- Ease data entering for expert users. Avoid stupid errors (as when I
forget slashes or mix dots and commas :-)
- Simplify FDS teaching to new users: no need to waste precious time
on XBs...

4) How?

Open source, multi platform. As FDS is...

5) Architecture (just sparse rumblings):

For now, no need for a GUI!
We just need a good text editor and a CAD converter.

The text editor is ready: "we have a gvim syntax file generator
script, and other similar tools created by users" [Bryan Klein].

The CAD converter should translate and optimize an open, widely used,
well documented 3d file format to FDS geometries (DXF, X3D, STL, 3DS?)

The CAD converter reads the geometry, matches the colour (or the
layer, the name, the type...) of each CAD object with its FDS
properties using an user modifiable table.

EG:
yellow 3D object -> OBST with SURF_ID='UPHOLSTERY'
black 3D object -> HOLE with control logic...
red 3D face -> VENT with SURF_ID='BURNER'
dark red plane -> SLCF with QUANTITY='TEMPERATURE'

The result is:
&OBST XB=...calculated..., SURF_ID='UPHOLSTERY' / 3D object
&OBST ...

Using this approach the converter does not need to know anything about
FDS logic, and is easier to maintain. The correctness of the result is
up to the user.

The tool could output a full FDS file by prefixing an user generated
text file containing HEAD, MISC, MATLs, SURFs...

I agree with you, patient reader: there's a lot to discuss and plan
here.

6) Technologies?

I began to write my personal tool in python (www.python.org) and
vpython for visualisation (http://www.vpython.org/index5.html) Python
is easy to learn and maintain. The code is automagically multi
platform. Speed is not an issue.
Fortran could be another good choice.

7) Who is going to develop and maintain it [dr_jfloyd]? Economic
viability of this development?

In my opinion, our community is well alive and able to support such a
project. There are already some volunteers...

Thunderhead developers demonstrated their friendliness to the
community. They could be interested in helping us. Are they reading?

8) Existing experiences:

[Tim] wrote that "we are currently developing a GUI for FDS v5,

initially, for our day-to-day work. This should cope with typical
issue such as material, ventilation, fire and combustion
specification. We hope that this may help the user community in long
term."

[R_Webster] wrote about user interfaces with AutoCAD.

[me] contacts with University of Lecce, who developed an STL
converter; contacts with other open projects (Blender, Salome).

Thank you for reading.
Hope this helps.
Emanuele Gissi

[Matt]

Simon,

Great summary.

One thing I love about FDS is the simplicity and ease of the text
file. I personally prefer a complete text file input. I have tried a
few tools (GUI, dxf2fds, etc). However, I have found that I prefer to
make the input file purely from a text interface. That way I can keep
the model simple enough to get essential answers and then chnages
(which are inevitable during a design phase) are quick and easy to
do.

Matt

On Jan 6, 8:59 pm, "Simon Ham, FiSEC, UK" <simon...@btconnect.com>
wrote:

[jcutonilli]

On Jan 6, 5:13 pm, Emanuele Gissi <emanuele.gi...@gmail.com> wrote:
> Hi, I am back from holidays. When I started this discussion I never
> imagined it could go so far!
>
> Please, let me try to summarize the discussion, citing contributions:
>
> 1) What we need:
>
> A tool (not necessarily a GUI) that eases the creation and placement
> of geometric objects (meshes, obstructions, holes, vents, slices,
> devices...) [Kristopher and Bryan Klein].

What we need is an integrated graphical interface that not only
eliminates the tediousness of creating input files, but also analyzes
both the input and output files. FDS requires the inputs to conform to
its particular ways and it will typically alter the inputs so that
they are slightly different from what was actually input.

For example, the obstacles requires absolute coordinates of two
opposite corners. FDS will move these coordinates that you enter to
fit the grid you have chosen. I don't know any real world drawing that
lists all of its coordinates from one particular point. I usually find
that I know the object is 4 ft wide by 2 ft 7 in long by 5 inches
thick and the object is 5 ft 1 in from one wall and 6 ft 4-3/4 in from
the adjacent wall. Neither of the wall lie on the origin. There is a
lot of math that needs to be done to convert what is known into what
is needed by FDS.

If this obstacle was a vent with a rather coarse grid resolution, the
flowrate or velocity may be significantly different from what was
entered because FDS adjusted its size to fit to the grid.

Jason pointed out that determining the grid can be very complicated.
FDS wants the inputs in terms of the number of cells in the X,Y, and Z
directions, with the cell number needing to be "magic" numbers. When I
determining the ngrid, I am concerned with the cell spacing and the
total number of cells, neither of which are an input. It can be very
complicated in a multi-block run to coordinate all of the inputs, but
its relatively trivial to have an interface spit out several possible
solutions (or even 100's of possible solutions)

I also seem to spend a large amount of time trying to figure out what
is wrong with the input file I am using. Smokeview is pretty useless
for this because it only displays the results you thought you needed
before you ran into your problem. For example, it's extremely
difficult to determine flowrates through openings or vents even though
I have appropriate data in slice files or Plot3D files. I typically
find myself rerunning the model multiple times trying to figure out
the right data needed to solve the problem.

The problem is that the typical interface designer only sees the
requested inputs and does not understand what it takes to obtain those
inputs. They will often optimize the inputs one way, which is
typically the lowest common denominator (new user). This allows the
program to have the greatest appeal to the largest number of users.
Unfortunately it also makes using the program more difficult/tedious
for more experienced users.

>
> For now, managing material properties, control logic, and the rest of
> the file can be left to editing a text file: "it seems that the best
> GUI is a great text editor that allows FDS input file syntax
> highlighting and code completion and possibly a built in help/doc
> system that would let a user quickly lookup information about the
> namelist parameters that are available for each namelist
> group." [Bryan Klein]

I think a text editor is a horrible GUI. There is a lot of repetition
and calculations that need to be made to determine inputs needed for
FDS. Text editors do not make either of those tasks easy. Syntax
highlighting might make reviewing a text file easier and code
completion might make small modifications easier, the bulk of the
inputs are still going to be tedious. I find Excel makes creating
input files much less tedious.

>
> 2) What we don't need:
>
> - A new 3D CAD. We don't have the resources to develop one.

While its dumb to create yet another 3D CAD program, the ability to
import 3D CAD files is important.

> - A competitor for Pyrosim. If you need Pyrosim, go and buy it!

Competition is good. Pyrosim is not perfect. Any interface that is
created will compete with Pyrosim, does that mean there should be no
new interfaces?

> - A super CFAST. If you need CFAST, just use it.

CFAST has a number of advantages over FDS, speed and model size come
to mind. I can do a full parameter study in CFAST to determine what
parameters might be important before you can finish building the FDS
model. Being able to move from CFAST to FDS and reusing the
information is a good thing.

> - "Drop down" menu of material properties, that could hinder the
> research in this area [Kevin]

I find it a bit ironic that the National Institute of STANDARDS and
Technology is not willing to to set any standards with respect to
material properties and that they expect non research people to
determine these properties even though its part of their (NIST's)
mission.

> - Lower entering barriers, as I wrongly stated in my first message.
> The inspiring message from Simon Ham was very convincing.

Lowering entering barriers is a good thing so long as it does not make
it more difficult/tedious for more experienced users to use the
program.

>
> 3) Goal of this new tool:
>
> - Ease data entering for expert users. Avoid stupid errors (as when I
> forget slashes or mix dots and commas :-)
> - Simplify FDS teaching to new users: no need to waste precious time
> on XBs...

The goal should be to eliminate the tediousness of creating input
files for all users and allow the input and output files to be
analyzed.

John

[DavidShep]

I disagree with you and strongly agree with Kevin on his
interpretation on the outcome of including a thermal properties
database in early version of FDS.

Everyone agrees that in the long term it would be great to include
accurate thermal properties as part of the FDS distribution. The
problem is that, at this time, no one knows the best way to measure
these properties for input into FDS. The research hasn’t been done to
find or develop methods to measure the properties that will produce
the best results in FDS.

When NIST included a material properties database in FDS it was
understood by the high level FDS users that the values were
essentially just place holders until accurate values could be
measured.

In practice, I found that many (or most) practicing users were using
the database values as if they were certified by NIST. Because NIST
provided the database values as a convenience and not as a certified
library, they included properties for different materials in different
FDS releases. I found that many people kept all of the old database
versions so that they could use “NIST” certified values for more
materials.

The result of NIST including the database was that few went looking
for the material properties and even fewer realized that the research
hadn’t been done to learn the proper methods of measuring the
properties. This perception that the materials properties problem had
been solved essentially halted all research in this area until this
past year.

[JLord]

>
> I find it a bit ironic that the National Institute of STANDARDS and
> Technology is not willing to to set any standards with respect to
> material properties and that they expect non research people to
> determine these properties even though its part of their (NIST's)
> mission.
>

And please remember that NIST does not have unlimited manpower and
funds. They have provided a huge amount of extremely useful software
and data for the rest of us with a handful of people. I think it is
not too much to ask that the rest of us do some of the work towards
finding ways to get good material properties. Even those of us who
are "non research people" have the abilitiy to contribute to this...or
at least the ability to write to our political representatives asking
that they help get more money for the folks at NIST so that they could
expand their effort one day.

In the mean time, I agree that it is best to not provide default
features that new users would interpret as being a list of
"sanctioned" material properties. If the end user can't find a few
referenced values to use they should probably do some more research
before using computational fluid dynamics.

[Kevin]

> I find it a bit ironic that the National Institute of STANDARDS and
> Technology is not willing to to set any standards with respect to
> material properties and that they expect non research people to
> determine these properties even though its part of their (NIST's)
> mission.
>

John -- NIST and similar institutions develop test methods for
measuring material properties. For example, the project funded by NIST
that is described in the following thread,

http://groups.google.com/group/fds-smv/browse_thread/thread/d4cd90e26eb68145#

has as its goal the standardization of measurement techniques for
material properties suitable for fire modeling. However, these
standards will not be NIST standards, but rather ISO, ASTM, and the
like (many of which already exist), plus engineering guidance via the
SFPE. The cone calorimeter was developed at NIST, and NIST has several
of the devices, but it does not typically do commercial product
testing with it. Nor does it compile an exhaustive list of HRRs for
different materials using it. The NIST mission is the measurement
technique, not necessarily the measurement, if you understand my
meaning.

What is ironic is that there is so much discussion of GUIs, but very
little about the thread I cited above. At the end of the day, what is
more important?

[Bryan Klein]

Two comments...
The first, NIST is doing something to set standards for material properties.
http://groups.google.com/group/fds-smv/msg/f17b6cf322c2702e

Second, I don't see how it will ever be possible for one test lab or
agency such as NIST, to test every possible configuration of MATL and
SURF properties for all the real world materials that users of FDS will
require over time. This data gathering process has to be user driven
from the bottom up. This is why it is so critical that there be
standard processes for gathering this information. My guess is that
once there is a standard method, then testing labs can incorporate the
guidance and provide testing, analysis and reporting services in
accordance with the guidance provided. This would then allow
non-research users to request testing on materials and get the data they
need in a reliable and consistent manner. In my opinion it is not
NIST's role to replace what is essentially a commercial test lab
function. The problem is not NIST's lack of support in this area, it is
that there is not yet a standard methodology for commercial labs to follow.

-Bryan Klein

[charlie.thornton]

John, you've given me a great opportunity to respond to your comments
from the PyroSim developer's standpoint. Maybe our experience will be
interesting to the makers of our next competitor :)

> The problem is that the typical interface designer only sees the
> requested inputs and does not understand what it takes to obtain those
> inputs. They will often optimize the inputs one way, which is
> typically the lowest common denominator (new user). This allows the
> program to have the greatest appeal to the largest number of users.
> Unfortunately it also makes using the program more difficult/tedious
> for more experienced users.
>

You make a good point. In trying to make PyroSim a great tool, our
huge disadvantage is that we are programmers, not fire protection
engineers or fire researchers. We can run problems and play at using
FDS and PyroSim, but, at the end of the day, we're 100% reliant on our
friends and customers to tell us what's good and what needs
improving. If our bias appears to lean toward entry-level users, it's
because they most closely resemble ourselves (our loudest source of
feedback). I've enjoyed this thread very much because it has
extracted so many opinions about the perfect FDS UI.

>
> I think a text editor is a horrible GUI. There is a lot of repetition
> and calculations that need to be made to determine inputs needed for
> FDS. Text editors do not make either of those tasks easy. Syntax
> highlighting might make reviewing a text file easier and code
> completion might make small modifications easier, the bulk of the
> inputs are still going to be tedious. I find Excel makes creating
> input files much less tedious.
>

In reading this thread, I've envisioned something like Microsoft
Frontpage. It's a web developer tool where you have a WYSIWYG design
tool and an HTML view. You can edit elements in either view and both
views will be updated. That sort of interface provides the mechanism
to flip back and forth between hard-core text editor mode and cuddly
3D mode as well as enough smarts to do your additional validation.

>
> > - A competitor for Pyrosim. If you need Pyrosim, go and buy it!
>
> Competition is good. Pyrosim is not perfect. Any interface that is
> created will compete with Pyrosim, does that mean there should be no
> new interfaces?
>

I'm optimistic that we'd be okay :) Emannuele made a good point
though - you've already got a PyroSim. The most effective thing to do
for the industry is to create a tool that somehow serves a
fundamentally different need. Otherwise, 3 years from now, you'd have
PyroSim and OpenPyroSim and another new forum thread about the perfect
FDS GUI.

> The goal should be to eliminate the tediousness of creating input
> files for all users and allow the input and output files to be
> analyzed.

I agree. Tools should be responsible for the annoying, tedious,
repetitive work and users should be responsible for the high-powered
creative vision. In FDS problems, the high-powered aspect is
frequently the material properties - about all the tool can do there
is make sure the numbers you type in are sane. Our customers
frequently want to import elaborate CAD geometries as well, but
perhaps this new tool wouldn't be targeted for those users.

Also, in defense of NIST - It seems to me very comforting that NIST
isn't falling over itself to standardize a collection of uncertain
materials. We all want NIST to know the correct material properties,
but they just don't...yet. I take comfort in believing that official
NIST standards are more than numbers that seemed pretty good at the
time.

- Charlie

[Emanuele Gissi]

1) First of all, I think we would better be grateful to NIST and its
personnel for what *they do* and not complain for what *they don't
do*: they are releasing their jewels as open source.

2) In reply to jcutonilli:

"What we need is an integrated graphical interface that not only
eliminates the tediousness of creating input files, but also analyzes
both the input and output files."

In this moment I largely prefer exactly the opposite: I want the FDS
file to be under my complete control. In my opinion, this is the only
way to have full control of the outputs. This is why I don't use
PyroSim.

3) An update about possible developments:

a- On February 20th, I'll meet some researchers of Politecnico di
Torino and Università di Lecce (Italy) here in Genova. We'll draft a
plan to develop a plugin to export geometric data from Blender 3D
modeller (www.blender.org) to FDS. If someone is passing near Genova,
he will be welcome at the meeting. Ideas are welcome, too.
b- In my little spare time I am developing a simple geometry editor
for FDS in Python. It's intended as a teaching tool. But it can grow
up. As soon as it's usable I will release it to those interested in
helping out.

Emanuele Gissi

[clauten]

One difficulty associated with material property estimation is that
not much can be directly measured (density, that's about it). Instead,
properties are INFERRED from experimental measurements (Cone, TGA,
DSC, etc.). Take the simplest example: thermal inertia and ignition
temperature are inferred from Cone Calorimeter ignition time plots via
the classical thermally thick ignition model.

We basically do the same thing with generalized pyrolysis models (such
as that in FDS), but niow there's 10 or more adjustable parameters
(material properties) to determine because the physics are treated in
greater detail. For a simple charring material, there'as at least 11:
kv, cv, kc, cc, rhoc, ev, ec, A, E, n, DHvol.

Simultaneous optimization of 10+ parameters is a major computer
science challenge. To date, people have tried stochastic optimization
(genetic algorithms), but tens of thousands or even hundreds of
thousands of trial solutions are usually necessary due to the large
number of degrees of freedom, so you have two choices: wait a long
time for your answer, or use parallel processing (even then you may
still wait a long time). Rarely does one get "good" results on the
first optimization run as these algorithms are not magic, they're just
a tool (and a tweaky tool at that).

There are much more sophisticated algorithms out there than have been
applied in the fire community to date--genetic algorithms, simulated
annealing, and hybrid methods. A badly needed contribution (and a
great project for an MS or PhD student) is development of a search/
optimization algorithm designed specifically for material property
estimation.

On Jan 13, 7:24 am, Bryan Klein <bryan.kl...@nist.gov> wrote:
> Two comments...

> The first, NIST is doing something to set standards for material properties.http://groups.google.com/group/fds-smv/msg/f17b6cf322c2702e

> > before using computational fluid dynamics.- Hide quoted text -

[dr_jfloyd]

Such an approach is discussed in thes publication that Simo provided a
link in the current thread on PU properties:

http://www.sal.hut.fi/Publications/pdf-files/TMAT08.pdf

(it was also presented at the last IAFSS)

[Hostikka Simo]

I would like to continue the discussion about material property
estimation in a new thread. In threads "GUI for FDS, state and
developments" and "Polyurethane Foam Reaction properties..", several
comments have been made about using reaction schemes, finding the
values, role of NIST and mathematical methods. They were getting
off-topic.

One point that I have found very challenging, is the fact that for
practical materials, knowing the material properties (or rather model
parameters) is not enough because the actual fire performance of the
_product_ is determined by 1) the material properties, and 2)
construction. Even accurate knowledge of the material properties may not
yield good prediction of cone calorimeter test.

Let's take electrical cables as an example. Even though the physical
construction of cables may be quite far from the assumptions behind the
FDS condenced phase solver, that's what we constantly end up simulating.
When doing this, I have found that the actual construction of the cable
is quite important. In addition to the material layers (typically
sheath, filler, insulator, conductor), there may be layers of thin
plastic or metal sheets, metal bands enhancing electrical properties and
strength, etc. These layers may or may not be permeable by the pyrolysis
products. Also, depending on the chemical compounds used, the char
residue of the materials may be impermeable to some extent - an
additional mechamism of fire retardancy.

How to handle these 'construction effects' when doing the parameter
estimation? So far, we have not described the permeability issues at
all, but rather tweaked the thermal and reaction parameters to obtain as
good cone calorimeter performance as possible. But is this the right
way?

Yet another question is, how many different tests (TGA, cone, lateral
flame spread, SBI, ...) one has to use for estimation and validation to
be confident that the model gives a good prediction of the actual
application.

Simo

[clauten]

Anna's MS thesis and her IAFSS paper applied a genetic algorithm.
Although genetic algorithms were proposed for property estimation in
some early work (e.g., http://dx.doi.org/10.1016/j.firesaf.2005.12.004,
among others) and have been used by several research groups since
then, there are more efficient search/optimization algorithms than
straight GA that have not yet been explored for this purpose. GA might
be a good starting point, but it is very tweaky, not always efficient,
and sometimes doesn't even give a good answer. A more efficient search/
optimization algorithm (simulated annealing, hybrid methods, etc.)
would save frustration and headaches. Point is that property
estimation is not "solved" from a computer science or algorithmic
standpoint.

> > > - Show quoted text -- Hide quoted text -

[bryan...@nist.gov]

I agree with Simo, the discussion is beginning to fragment into
different topics.

I have created a new thread for the material properties discussion.
http://groups.google.com/group/fds-smv/browse_thread/thread/a016a2bed103877d

Please continue there.
-Bryan

On Jan 14, 10:11 am, clauten <chris.lautenber...@gmail.com> wrote:
> Anna's MS thesis and her IAFSS paper applied a genetic algorithm.
> Although genetic algorithms were proposed for property estimation in

> some early work (e.g.,http://dx.doi.org/10.1016/j.firesaf.2005.12.004,

[Tim]

Sorry I miss the discussion for the whole week.

I agree with jcutonilli (6 Jan 2009) on what should be in the user
interface. As a independent fire consultant, we are developing a GUI
just very similar in line with what John's suggested. For instance,
when the user change the grid spacing, the specification of the OBST
and other elements will change with it.

We believe that a good GUI should be able to guide the user to apply
the software in the right direction. AT this moment, a lot of users
apply the software without knowing the flexibility as well as
limitation. A good GUI should help to user to understand what the
limitation is and to correct the data file. By doing this we can
achieve lowering the entering barriers for new users.

It will be useful to see more discussion on this.

Tim

[DavidShep]

A major concern that I have about any type of user interface for FDS
is what happens to the default values in FDS. As we all know, FDS
doesn’t expect the user to input every variable value. Instead, the
developers of FDS have chosen reasonable default values for every user
input. The user should only changes variables from their default
values when they have a good reason.

When user interfaces are developed it is often easier to code the
program to always specify values instead of only specifying variables
that change. This becomes a significant problem when the values vary
from the FDS defaults without the user’s specific knowledge. I have
often heard this mentioned as a problem with Pyrosim.

It is, of course, the responsibility of the User Interface developer
to make sure that the default values are not changed without the
user’s specific direction. However it is understandable why a
developer would not take the time to retype what must be hundreds of
values from the 27 tables in Chapter 13 of the user guide.

It would help the user interface developers if FDS created an output
of all of the default values. This would also remove any excuse that
interface developers might have for using non-default values.
Interface developers could slim down their input files because they
could use a simple if..then statement to only write out variable
values that had changed from the default. It would also assist FDS
users in debugging runs from these interfaces.

[Kevin]

One problem with writing default values -- you'll notice in the tables
of input parameters in the back of the Users Guide that many variables
have no default value listed. The reason for this is that FDS often
uses the specification of a value as the trigger for a particular mode
of operation. For example, the mere specification of HRRPUA tells FDS
to use the mixture fraction combustion model. We did this to avoid
having the user make this decision explicitly -- in fact, the
combustion cannot be done any other way in FDS if the user simply
wants a specified HRR. If FDS had to list all of its default values,
you'd see alot of -1's (our equivalent of -999 that experimentalists
use to denote a value that should not be used). We prefer to list in
the .out file the parameters (default and user specified) that are
actually relevant. Listing parameters that play no role in the
calculation would lead to an unending series of questions like "How
can the thermal conductivity be negative?" even when FDS does not use
a thermal conductivity for that particular kind of surface.

[johannes]

I also developed an add-on called 3dsolids2fds that can be used within
AutoCAD environment to convert 3dsolids geometries to &OBST lines.
It's a handy utility if you know how to use CAD and construct 3dsolids
in the first place. It's available here on the third party links page.

As BIM applications are gaining popularity among building designers, I
think we should focus on developing standardized conversion tools such
as that using IFC data model, which is a non-proprietary industry
standard specification.

Johannes

On Jan 7, 6:18 am, R_Webster <robert.webs...@areva.com> wrote:
> During my years of experience using FDS, I have created several FDS
> user interfaces with AutoCAD. These interfaces have generally been
> tailored to satisfy the requirements of my employer at the time.
> However, are generally applicable to any fire modeling project. If
> there is a need in the industry for such an interface, I would be open
> to the idea of releasing these tools to the public. Feedback would be
> appreciated.
>
> My experience suggests that making FDS easier to use opens the door to
> many unqualified potential FDS users. For that reason, I would suggest
> any FDS GUI be limited to defining the locations of obstructions,
> vents, and devices. Extending the functionality of an interface beyond
> that suggests that the interface is making assumptions for the user.
>
> An FDS user interface that has no function other than converting the

> modeled geometry from aCADformat to an FDS input file format

> contains no assumptions. As an engineer, any assumptions that I make
> (or software used) must be supported by testing or some other means of
> verification and validation. NUREG-1824 provides me with some
> justification for use of FDS. However, if an interface with FDS also
> makes assumptions, about the thermophysical properties, burning
> characteristics, etc. of a material, then these assumptions also
> require validation.
>
> In my opinion, there is no need for a FDS GUI in an academic
> environment. A GUI for FDS has a primary function of describing
> complex geometries. In an academic environment, the focus is on
> understanding concepts like thermally-thin and thermally-thick, fuel-
> lean and oxygen limited, combustion stoichiometry, buoyancy,
> stratification, etc. All of which can be described with four walls, a
> fire, and a target.
>
> Robert Webster

> robert.webs...@areva.com

[charlie.thornton]

In the scheme of things, encoding the values from the back of the
manual isn't a big deal - the job is relatively small and very
measurable. The issue Kevin mentioned where you sometimes *want* to
write a default value to enable a feature does help things
challenging. However, I look at both of those as the cost of playing
the game.

Life did get a bit more interesting a while back was when some
defaults changed. When we changed PyroSim over to FDS5, we had a big
push to stop writing unnecessary defaults. Then we got caught
sleeping. We released a version where, in our bundled FDS version,
defaults for some MATL values had changed to 0.0. Because PyroSim
still used the old defaults, if you entered a specific heat of 0.1,
you would get an error (workaround: enter 0.100001). Shame stricken,
we dropped everything and posted an update. However, making sure all
the GUIs work properly isn't NIST's job. We should have caught that
problem in testing.

I do hope that someday I or someone can find the answer to: how can
you make GUI users confident that the GUI is doing exactly what you
tell it to do? Somehow a non-intrusive audit has to be build into the
process. It's a tricky problem.

- Charlie

[Kevin]

Don't beat yourself up too much over that, Charlie. We, the FDS
developers, sometimes make changes to the defaults without making it
clear enough to the users. We do change the User's Guide, but it's
hard to monitor that constantly. Plus, we realize that it's impossible
to reread the entire Guide with each new app. So usually we change a
default to force FDS to stop with an error statement if something is
not properly specified. For example, there are many parameters on the
SURF and MATL lines that are incompatible, in other words, make no
sense when used together. In older versions, FDS simply used the
parameters it needed for the particular mode of operation, and ignored
the others. But it didn't tell you this, not even with a warning.
Meaning that the user still thought that a particular parameter
mattered when it didn't. We often see "I change the value of XXX and
my results don't change at all!" Now, we just make the model fail
instantly with an error if there are too many occurrences of improper
specification of a single or set of parameters. That gets the user's
attention more so than a warning, and since it happens right away, it
actually helps the user put together a proper input file.

If it's not there already, I suggest that PyroSim or any FDS GUI show
in a window what the actual input line is going to be. At the end of
the day, it's up to the user to make sure that the text input file
read by FDS is properly specified. I see this in MS Visual Studio,
which we use for compiling FDS and Smokeview on PCs. There are
literally hundreds of compiler options in dozens of menus, but with
each click of a button, you see at the bottom of the window what the
actual compiler option is, based on your selection. Often the actual
option is very cryptic, but at least you see what the GUI is actually
doing.

On Jan 20, 5:43 pm, "charlie.thornton" <charlie.thorn...@gmail.com>
wrote:

> > > users in debugging runs from these interfaces.- Hide quoted text -

[charlie.thornton]

I like that idea (visual studio-style properties dialogs) a lot,
thanks! Compared to compiler/linker options, FDS records seem like an
easy read :)

- Charlie

[DavidShep]

The FDS developers should change the defaults when the change will
provide better results.

Unfortunately, this causes the users of interfaces to get incorrect
results until many steps occur such as 1) the GUI publisher discovers
the change, 2) The GUI publisher changes the program, 3) The user
updates the program on their computer.

FDS could easily be modified to assist the interface developers to
keep current with the defaults.

All it would take would be for FDS to echo to a file when the defaults
are defined. The file could be called “FDS.DEFAULTS” and the format
could be NAMELIST, VARIABLE, VALUE. FDS Interfaces could read this
file and very easily keep up to date without the developers having to
play detective or the users having to update their programs.

[Glenn Forney]

similar to
smokeview -ini

--
Glenn Forney
National Institute of Standards and Technology
100 Bureau Drive, Stop 8663
Gaithersburg MD 20899-8663

Telephone: (301) 975 2313
FAX: (301) 975 4052

Pre-decisional and sensitive information. Not for attribution, distribution, or reproduction.

[Hostikka Simo]

Dave,

This may not be as staightforward as you think. Let's take MATL line as
an example. It has following defaults:


A = 1.E13_EB ! 1/s
E = -1._EB ! kJ/kmol
REFERENCE_TEMPERATURE = -1000._EB
REFERENCE_RATE = 0.1_EB

Now, during the input processessing, if E is still < zero and
REFERENCE_TEMPERATURE > 0, E would be set based on REFERENCE_TEMPERATURE
and REFERENCE_RATE. What is the actual default of E, -1 or the computed
value?

There are number of instances like this, which make the simple printout
of default values somewhat useless.

Simo

[JWilliamson]

The information about parameter defaults is already tabulated for
everyone in the user guide in Ch. 13. I've used these tables before in
my own efforts for an excel based UI. The only problem I have with the
info in Ch. 13 is with the convenience of converting the table from
the pdf to a table in excel since the delimiters aren't convenient.
I'm sure there's a better way to do it, but I'm not aware of it. Is it
possible/easy to share the tables in Ch. 13 as a csv?

Also, to avoid conflicts with over-specifying parameters like in
Simo's example, the UI could generate an input file where un-specified
defaults are commented out. That way a user could see the default and
then make an informed decision about changing it, while you limit the
risk of conflicts.

[Kevin]

The Guides are written with LaTeX, and the tables are formatted using
certain text characters to denote columns and rows. You'd probably
want to try to convert the PDF document tables into something you can
work with, but I don't know how.

On Jan 22, 9:03 am, JWilliamson <williamson.justin.w...@gmail.com>
wrote:

> > > detective or the users having to update their programs.- Hide quoted text -

[Glenn Forney]

why not work with the latex file and convert the '&' characters to ','
s . (ie to make a csv file) You would have to do some work to clean
things up but at least you would not be re-typing parameter values

[charlie.thornton]

It's a good feeling when the capability of your software is limited
only by the speed you can type. I miss that. :)

If you open up the TEX file for the manual, you can copy out something
like this:

{\ct MASS FRACTION}$^*$ & $Y_\alpha$ & kg/
kg & D,I,P,S \\ \hline
{\ct MASS LOSS} & Integrated mass loss at surface & kg/m
$^2$ & B,D \\ \hline
{\ct MIXTURE FRACTION} & $Z$ & kg/
kg & D,I,P,S \\ \hline
{\ct MPUA}$^{**}$ & See Section~\ref{info:part_output} & kg/m
$^2$ & B,D \\ \hline
{\ct MPUV}$^{**}$ & See Section~\ref{info:part_output} & kg/m
$^3$ & D,P,S \\ \hline

Paste that into Excel. Break the values up into columns using "&" as
a delimiter. Then select everything and hit CTRL+F. Click the
Replace tab and replace everything you don't want with...nothing.

- Charlie

[Bryan Klein]

Some creative scripter out there could easily write a perl or python
script to parse read.f90 and write a report of defaults in csv, pdf,
xls, whatever.
Someone else made a program that automatically generated a VI editor
syntax file. This would probably be a good start.
If someone makes it, please host it somewhere and email me the link, I
will add it to the third party tools page.

Group Post:
http://groups.google.com/group/fds-smv/msg/997318ee227baacc

Perl Script File Link:
http://fds-smv.googlegroups.com/web/fds_make_syn.pl

-Bryan

[Mitch REI]

Hello
Reaction Engineering International (REI) is currently developing a GUI
for FDS named FireExplorer. FireExplorer is targeted toward
firefighters for training purposes and strongly emphasizes ease-of-
use. It is a closed-source, commercial application which has been
developed under Air Force SBIR funding. It is currently targeted only
for Microsoft Windows. We hope to release a Beta version of the
software sometime in the next couple months. Thank you for your
interest.

Mitch McDonald
REI

[dave]

Hi guys,

As a follow-up to Mitch's post, let me offer to answer any additional
questions you may have about the Air Force project. It has been a bit
of a ride in terms of determining exactly what functionality they are
looking for.

As noted previously, it is very much targeted for a "Non-expert" user,
which of course comes with a significant set of problems/issues. Still
we believe the idea has merit given proper bounds and user training.
Note that it is a fundamentally different tool than Pyrosim that
targets a much different group of users.

We would definitely be interested in coming to the conference Kevin
mentioned previously and showing what we have in the works. Feedback
from NIST would be most useful to our efforts.

Regards,
Dave Swensen

[Kevin]

Dave -- yes, we would welcome any and all from REI to come to our Fire
Modeling Workshop, April 29, 2009.

http://www.bfrl.nist.gov/info/fireconf/

I am drafting an agenda now. Looks like we'll start the day with a
discussion of GUIs, given that there is so much interest in the
subject. A rep from Thunderhead is coming, and we'll have Bryan Klein
and Glenn Forney talking as well about various other software tools
that we see as key to the long term viability and useablity of FDS/
Smokeview.

[Vectorworks]

After reading this thread and speaking with Bryan Klein we have posted
a new thread “FDS GUI Survey”. Within this thread we have added a
survey link for your input to justify our further involvement and
address your needs. We require 500 responses to the following survey
by Tuesday March 10th. Please fill out the survey, it should take you
less than two minutes to complete. Please pass this link on to anyone
you know that uses the FDS software or anyone that would be able to
use the software with additional GUI support.

http://www.surveymonkey.com/s.aspx?sm=ZHCEBv47qXR6tdr26XUF9g_3d_3d

Please help us pull this information so we can share the feedback and
help everyone involved with FDS.


Michael Bendler
Nemetschek North America Inc.