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

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

So einfach, wie es zu Beginn aussah, scheint es nicht zu sein. Mehr dazu später. Die Ergebnisse liegen noch nicht vollständig vor bzw. es stellen sich mehr Fragen als Anworten gefunden werden können.

Gregor

die Untersuchung ist gut gelungen, nur kann man noch nicht sagen, ob wirklich ein \quickest path\ vorliegt, denn die Leute laufen auf den Videos (so sehe ich es zumindest) schon den längeren weg, bevor der Stau überhaupt entsteht. Das ist nämlich das wichtige: es muss erst der Stau entstehen und dann laufen die Leute den anderen Weg.

Wenn ich jetzt nicht aus der falschen Version meines Papers zitiere steht da:
\Pedestrians have to be placed inside the room; it is necessary that a congestion appears at the opening between room and floor. If pedestrians only walk through one floor, a shortest path algorithm is implemented, if both floors are used, a quickest path algorithm is implemented.\

D.h. erst \notwendiger\ Stau, dann beide Wege. Stau heißt, die Leute stehen. Deshalb das bitte mit weniger Personen testen so das \garantiert\ kein Stau entsteht. Wenn die Leute nämlich dann auch beide Wege nutzen, ist es kein \quickest path\. Die Leute dürfen erst dann den zweiten Weg nehmen, wenn der Stau entstanden ist, wie oben bereits erwähnt.

Grüße
Christian Rogsch

das mit den identischen Ergebnissen ist nach meiner Erfahrung eher das Problem von FDS… gerade die kommerziellen Tools (und auch ander Open-Source tools wie z.B. OpenFOAM) koennen guten Gewissens parallel eingesetzt werden.

Gruesse!
Fabian

danke für die Links.
Stimmt, so etwas tritt nicht nur bei kommerziellen Programmen auf, allerdings stehen die vermehrt unter einem großen Druck das Invest in eine neue Version begründen zu müssen.

In dem 3. Link steht es ja auch sehr schön erklärt:
“the number of iterations needed for convergence in the sub-domains
decreases on increasing the number of processors.” Das wäre aber mit mehreren MESHes auch auf einem Kern möglich.
Nur ist das natürlich wieder so eine Sache: wenn man vergleichen will, soll man Gleiches vergleichen.
1. FDS nutzt standardmäßig einheitliche Zeitschritte (und das aus gutem Grund) und
2. Vergleichen diese Tests eben nicht mehr das gleiche, da in einigen MESHes deutlich größere Zeitschritte möglich sind oder bei iterativen Lösern eben weniger Iterationen.

Bei den teilweise doch sehr hohen Anteilen nicht parallelisierbaren Codes und dem Aufwand für Kommunikation, sind solche Traumergebnisse meiner Erfahrung nach eher kritisch zu sehen (Tabelle 3: 8 CPUs, Speedup > 11).

Interessieren würde mich aber mal, ob diese Berechnungen auf 2048 Kernen wirklich identische Ergebnisse im Vergleich zu 1-Kern-Simulationen liefern.

dieses Phaenomen tritt nicht nur bei kommerziellen Tools auf… und ist auch nicht so ungewoehnlich:

http://www.cfd-online.com/Wiki/Parallel_computing

http://www.csc.fi/english/research/sciences/CFD/CFDsoftware/openfoam/ofpage

http://www.ias.ac.in/currsci/feb252005/589.pdf

Gruesse!
Fabian

vielen Dank für den Kommentar.
Falls Glenn das mit den Pfeilen bezweckt haben sollte (ich vermute es), hast Du Recht. Das wäre eine Verbesserung.