Professionelle Simulationen arbeiten ganz anders als BAHN, nämlich in einem 3-Schritt-Zyklus. Zuerst wird ein Modell erstellt, dann wird dieses simuliert, und danach werden die Ergebnisse ausgewertet. Es ist nicht üblich, daß während der laufenden Simulation jemand am Modell eingreift und etwas ändert. In BAHN ist es aber gerade das eigentlich interessante, daß man gleichzeitig Fahren und Bauen kann, inklusive gleichzeitiger und sofortiger Darstellung/Visualisierung des Ergebnisses. BAHN ist in diesem Sinne auch keine Simulation. Es ist ein Hybrid aus Editor, Simulation und Visualisierung.Christopher Spies hat geschrieben:Hallo allerseits!
Längerfristig wäre es eine Möglichkeit, den Simulationskern von BAHN konsequent auf ereignisdiskrete Simulation umzubauen. Darüber habe ich mit Jan Bochmann schon einmal gesprochen.
Damit wäre beispielsweise zeitverzögertes Zurückschalten von Signalanlagen, wie neulich hier im Forum gewünscht, kein Problem, und Züge im Zustand "blockiert" würden keine Rechenzeit mehr verschlingen, weil nicht permanent geprüft werden müsste, ob der Folgeabschnitt frei geworden ist, sondern der Zug per Ereignis über die Fahrtstellung des vor ihm liegenden Signals oder die Weiterfahrt des vor ihm stehenden Zuges informiert werden würde.
Außerdem ist ereignisdiskrete Simulation ein Thema, welches in den letzten Jahrzehnten gründlich erforscht wurde und immer noch wird. Somit sind die entsprechenden Algorithmen hochgradig optimiert, was die Simulationsgeschwindigkeit erhöht bzw. die benötigte Rechenleistung vermindert. Es existieren auch verschiedene Verfahren zur verteilten Simulationen auf mehreren Rechnern oder mehreren Prozessorkernen innerhalb eines Rechners.
Gruß
- Christopher
Um strikt ereignis-orientiert zu arbeiten, müssen alle Zusammenhänge gespeichert werden, damit die Information über Ereignisse überhaupt zugestellt werden kann. Ein Zug, der ein rotes Signal erreicht, muß sich dort anmelden. Das Signal muß sich alle dort wartenden Züge merken und diese informieren, wenn es umschaltet. Ein Zug, der von einem anderen Zug blockiert wird, muß sich bei diesem anmelden, usw. Für alle diese Anmeldungen müssen die entsprechenden Objekte Speicherplatz vorsehen. Es ist nicht immer nur genau eine Anmeldung, sondern es können in manchen Fällen auch mehrere sein.
Hier zeigt sich ein Problem, das beim Programmieren fast immer vorkommt: Für mehr Geschwindigkeit benötigt man mehr Hauptspeicher. Man kann also in einer Hinsicht optimieren, aber nur auf Kosten einer anderen Größe.
Außerdem sind solche redundanten Daten nur schwer zuverlässig zu verwalten, wenn zwischendurch in das System eingegriffen wird. Wenn ein Zug vor einem gesperrten Signal steht und hin und wieder schaut, ob die Strecke frei ist, dann funktioniert das auch, wenn der Nutzer das Signal abreißt und durch ein einfaches Gleis ersetzt. Ansonsten muß das Signal, bevor es verschwindet, alle angemeldeten Züge informieren. Und zwar nicht mit dem Standard-Ereignis "jetzt ist frei", sondern mit einer extra Info nur für diesen seltenen Spezialfall. Anderenfalls würde der Zug niemals weiterfahren. Aus diesen Gründen gibt es viele Software-Technologen, die redundante Daten grundsätzlich ablehnen. Es gilt als zuverlässiger, wenn Abhängigkeiten stets neu geprüft und berechnet werden, anstatt sie extra zu speichern. Freilich benötigt das entsprechende Rechenleistung.
Solche Dinge sind in BAHN daher nur teilweise implementiert. Außerdem ist es so, daß viel Rechenleistung für die eigentliche Bewegung der Züge gebraucht wird. Das ist aber in der Physik ein kontinuierlicher Vorgang und kein diskreter. Natürlich wird er in einer Simulation auch in diskrete Schritte aufgeteilt, aber eben in sehr viele sehr kleine. Man kann diese nicht vergrößern und Zwischenschritte weglassen, ohne das Ergebnis wesentlich zu verfälschen.
Grüße
Jan B.
