Research and the release rate of FDS versions

In den vergangenen Tagen startete Dr. Guillermo Rein vom BRE Centre for Fire Safety EngineeringUniversity of Edinburgh – eine interessante und lesenswerte Diskussion zum Thema Forschung und Häufigkeit von neuen FDS-Programmversionen im offiziellen Forum.

Dr. Rein stellte zu Beginn die Frage, wie man aus wissenschaftlicher Sicht mit unterschiedlichen Ergebnissen des gleichen Falles bei verschiedenen FDS-Versionen umgehen soll, ob wissenschaftliche Publikationen immer auf der neusten Version basieren sollten und welche Auswirkungen die unterschiedlichen Ergebnisse letztlich auf die Planung und Auslegung von Gebäuden im Alltagsleben eines Ingenieurs haben.

Es lohnt sich, die interessante Diskussion zu verfolgen.

4 Kommentare

  1. Hi,

    I have just discovered this forum. I would have to write in English, as my German will take 10 more years to be readable.

    I feel the need to emphasize a bit more that I am a research user of FDS, not a code developer (my times developing any significant size code finished with my PhD thesis). My comments for thoughts in the FDS forum were placed from that particular perspective. Unfortunately, they may have sound uncomfortable or ill posed to some, but the original content remains largely untouched, and I think they will come back sooner rather than later.

    These comments, as most of my work, stem from my experience teaching to the next generation of engineers and trying to developing novel methodologies to understand fire dynamics. Commenting on the well known fact that academics are useless at solving bugs in FDS is not what I was expecting.

  2. You can see my comments in the referenced discussion.

    I do not think that it is the job of the developer to pace themselves for the comfort of the end user. They should proceed as fast as possible toward improvement and extensions of the program, in a continuous development cycle.

    As a member of the development team at NIST, I know first hand that there was not a significant amount of time spent planning the future release milestone and what it would contain. In general if something was fixed, or an added feature was deemed to be stable, a release was made. The release type major, minor, maintenance was a matter of impact of the changes and not usually something that was planned in advance.

    Hopefully now at Thunderhead and managing the PyroSim product, I can at least improve how this software handles updates and informs the users.

    I have also started a new company separate from my work at Thunderhead that will offer web services which will have a large impact on how engineers can use FDS and manage the results. You hear it here before the FDS-SMV Discussion Group… http://www.solvercore.com

    Best Regards,
    -Bryan Klein

  3. Hallo Boris,

    Als Nutzer von FDS im Engineering möchte ich dazu sagen, mich stören, die vielen Minor-Releases manchmal auch. Gegen Bug-Fixes habe ich überhaupt nichts. Grundsätzlich finde ich die Arbeit von NIST sehr gut und auch sehr schnell. Ausserdem ist der Einbezug der User immer möglich und auch die Einsicht in den Code ist immer nachvollziehbar. Trotzdem erzeugen zu viele Minor-Releases meiner Meinung nach eine zu grosse Unruhe bei der Arbeit. Die Sichtweise von NIST, wenn ein Problem erkannt wurde, muss man es schnellstmöglich lösen, ist lobenswert, kann aber auch dazu führen, dass einfach immer mehr in dieses Programm eingebaut wird, was die Übersichtlichkeit nicht gerade förderlich ist.

    Viele Grüsse
    Chris

  4. Persönlich habe ich einige Anmerkungen zu Dr. Reins Kommentar:

    1. Unabhängig von seiner vieleicht berechtigten kritischen Bemerkung hat es schon eine besondere Qualität im Mai 2010 eine Arbeit auf Grundlage von FDS 4 abzugeben.

    2. Dr. Rein sollte vielleicht weniger im FDS-Versionsschema denken als in Modellen. Eine funktionierende numerische Implementierung vorausgesetzt, kann er ja für Detailuntersuchungen problemlos alte Versionen nutzen, solange das Modell ‚aktuell‘ ist.

    3. Sein abschließender Kommentar zu Kevins Reaktion geht am Thema vorbei. Kevins Darstellung verstehe ich nicht als Kritik an Wissenschaftlern sondern als Hinweis darauf, daß Fehlermeldungen keine wissenschaftliche Arbeit sein müssen und wie am sinnvollsten damit umgegangen wird.

    Boris

Kommentare sind geschlossen.

WordPress Cookie Hinweis von Real Cookie Banner