Ab sofort sind neue Updates über den Downloadbereich verfügbar: Diesmal das monatliche Update für die Baustatik und zusätzlich ein Update für das Programm für Fundamentberechnungen Xfun.

In der Baustatik gibt es 2 wesentliche Änderungen: Der Lastgenerator “kann” nun auch Schneelasten nach DIN 1055- das ist das ein. Das andere, weniger sichtbare ist: Alle FEM Programme wurden in weiten Bereichen parallelisiert und verwenden nun alle verfügbaren CPUs, gleichzeitig wurde der Netzgenerator dramatisch beschleunigt. Vor allem bei Systemen mit vielen Faltwerkselementen und zumindest einigen Stäben sollte man eine spürbare Beschleunigung merken. Bei Systemen die nur Stäbe verwenden, sollte sich die Nutzung von mehreren Kernen deutlich bemerkbar machen. (Dazu gab es hier und hier ja schon ein paar Zahlen.)

Das Update-Protokoll im Download-Bereich enthält wie immer eine vollständige Liste aller Änderungen und Erweiterungen.

Ein paar Kunden hatten bei der Installation der Version 1.64 das Problem, das ihr Antiviren-Programm im Zuge der Installation Alarm schlug: Was nun ?

Im wesentlichen ist es so, das die Installationsmedien auf einem "sauberen” Rechner hergestellt werden – ich bin da sehr zuversichtlich, das diese keine Viren enthalten. Bei näherem untersuchen der Meldungen kam dann folgendes raus: Seit Version 1.64 verwenden wir im Rahmen der Installation den Ngen – Microsofts Native Image Generator.

Das Programm erstellt im Laufe der Installation eine auf das vorliegende System optimierte Version der Baustatik und schreibt in diesem Zusammenhang auch native binärdateien in Systemverzeichnisse. Das passiert erst seit Version 1.64, weil unser Installationsprogramm das vorher nicht konnte.

Nun scheint es Antiviren-Programme zu geben, für die dieser Vorschlag so aussieht, als würde ein Virus den Rechner befallen – das ist aber Quatsch, und eigentlich für mich auch etwas überraschend, denn Ngen gibt es schon seit Jahren – das ist nicht wirklich was neues. Microsofts Defender (bei Windows 7 beigepackt) und Security Essentials (der kostenlose große Bruder vom Defender) haben dieses Problem beispielsweise nicht.

Wie auch immer: Nein, die von uns ausgelieferte Version 1.64 der Baustatik enthält keinen Virus, keine Sorge.

Mal angenommen, man hat so ein System:

Jetzt will man einen der sich kreuzenden Stäbe am Kreuzungspunkt aufteilen. Wie macht man das?

1. Man braucht irgendwie die Stelle, an der sich die Stäbe kreuzen. Das geht mit Erzeugen –> Punkte –> Knoten im Schnittpunkt von Geraden erzeugen
   
2. Jetzt misst man den Abstand vom Anfangsknoten zum Schnittpunktsknoten: (Werkzeuge –> Länge messen)
   
3. Jetzt klickt man auf den Stab und wählt den Befehl zum aufteilen:
   
4. Aufteilen tut man dann “Mit Abstand vom Startknoten” (den hat man gerade vorher ausgemessen)
   
   

(Bin gerade in Urlaub: Dieser Beitrag wurde aufgezeichnet.)

Diesmal: Die Marine sucht Soldaten – USA vs. Japan.

(Bin gerade in Urlaub. Dieser Beitrag wurde aufgezeichnet.)

4 Tage hier.

Ich hatte gestern eine kleine Tabelle gezeigt, aus der man die Performance-Gewinne durch den Einsatz von Multicore-Systemen ablesen konnte. (Es gibt übrigens bereits durchaus bezahlbare 24-Core Desktop Systeme.)

Aus der Kurve konnte man beim 4-Kern System sehen, das der gemessene Vorgang nur noch die Hälfte der Zeit brauchte. Das ist natürlich nicht besonders beeindruckend, wenn man bedenkt, das immerhin 4 CPUs beteiligt sind: 4 CPUs machen die Sache also nur doppelt so schnell wie eine einzelne.

Es kommt aber auch immer drauf an, was man eigentlich betrachtet. Beim Vorgang gestern wurden sämtliche Vorgänge mit gemessen. Nach dem Klick auf den Befehl für die Bemessungsergebnisse finden aber eine ganze Menge Dinge statt: Es wird eine Plausibilitätskontrolle durchgeführt (beim gegebenen System mit 1800 Stäben kann das schon mal eine Sekunde oder so dauern, es wird eine FEM-Berechnung durchgeführt, die zugehörige Matrix aufgefüllt, etc. etc. – und vieles davon ist eben (noch) nicht parallelisiert.

Wenn man sich aber einen anderen Vorgang ansieht – einen, der möglicherweise häufiger vorkommt – dann sieht die Sache schon anders aus. Angenommen, man ist bereits auf dem Fenster zur Auswahl der Ergebnisse – dann geht es nur noch darum, eine bestimmte Bemessung (oder eine bestimmte Überlagerung) durchzuführen.

Der Wechsel von Bemessungsgruppe “1” zu Bemessungsgruppe “2” löst einen Bemessungsvorgang aus. Und der dauert (auf dem gleichen 4-Kern System von gestern, mit dem gleichen Tragwerk von gestern):

Mit Multicore-Support: ca. 4 Sekunden
Ohne Multicore-Support: ca. 16 Sekunden

Hier gibt es also plötzlich eine dramatische Verbesserung: Die benötigte Zeit nimmt bei so einem Vorgang tatsächlich linear zu den vorhandenen CPUs ab.

Die Baustatik enthält an einigen Stellen Unterstützung für Mehrkern-Systeme: Im Gleichungslöser war dieser Support schon immer eingebaut (wenn die Option “Einstellungen –> Allgemeines –> Schnellen Gleichungslöser verwenden” eingeschaltet ist.). Seit dem letzten Update (auf Version 1.64) haben auch alle Bemesser Unterstützung für Mehrkernsysteme und führen die Bemessung für Stäbe, Unterzüge und Faltwerkselemente parallel durch: Dabei laufen immer so viele Bemessungen gleichzeitig, wie CPUs vorhanden sind.

Ab dem nächsten Update wird das ausgebaut sein und für alle Ergebnisse – nicht nur für Bemessungsergebnisse gelten. Außerdem wurde der Netzgenerator parallelisiert.

Natürlich ist aber nicht alles parallelisierbar -  so zum Beispiel große Teil des Programmcodes, die sich mit dem “echten” Malen beschäftigen: Also praktisch alles, was irgendwelche Striche auf den Bildschirm bringt. (Wir werden ganz sicher noch darüber nachdenken, wie man das ändern kann, aber zur Zeit wird fürs zeichnen immer nur eine CPU verwendet.)

Aus diesem Grund ist es zwar so, das einige Teilbereiche tatsächliche linear mit der Anzahl der CPUs schneller werden – andere aber eben nicht. Als Gesamtergebnis erhält man dann Resultate, die insgesamt zwar mit der Anzahl an CPUs besser werden, aber nicht so linear, wie man sich das wünschen würde. Wir haben hier mal ein paar Messungen auf unterschiedlichen Systemen vorgenommen – und zwar für dieses Beispiel anhand eine Stabsystems mit > 1800 Stäben und ca. 3000 Einwirkungen, das nichtlinear berechnet wird.

Die Y-Achse gibt die benötigte Zeit (in sec) an, und zwar vom Start der Berechnung (Mausklick auf “Ergebnisse –> Bemessung”) bis zu dem Zeitpunkt, an dem die Ergebnisse (als Kurven) am Bildschirm angezeigt werden.

Dieser Vorgang wurde auf 4 Systemen durchgeführt, und zwar einmal ohne Multicore-Unterstützung (blaue Balken) und einmal mit (rote Balken [Das ist der normale Betriebsmodus der Baustatik, wenn die Option “Alle CPUs gleichzeitig verwenden” eingeschaltet ist.]).

Die Beschriftung unterhalb der Balken gibt die Anzahl der Kerne und deren Taktfrequenz an. Bei der Single-Core Berechnung kann man leicht erkennen, das die Taktfrequenz das einzig maßgebliche ist: Je höher der CPU – Takt, um so kürzer ist die Berechnungsdauer.

Im Vergleich der roten und blauen Balken kann man dann erkennen, was die Mehrkernlösung bringt: Effektiv (und unter Berücksichtigung der Tatsache, das eben nicht alle Vorgänge parallelisiert sind) braucht die 4-Kern CPU (ganz rechts) mit Multicore-Support nur noch die Hälfte der Zeit wie im Single-Core Betrieb.

Bei den anderen (Dual-Core) Systemen führt die Verwendung des zweiten Kerns dazu, das etwa jeweils ein Drittel der Zeit eingespart wird. Im Endeffekt wird der Rechner mit nur 2 CPUs dabei fast genau so schnell wie der mit den 4 CPUs – und zwar deshalb, weil die einfach langsamer laufen.

Wenn man sich also zwischen einem (etwas langsamer getaktetem, aber etwas teurerem) 6-Kern System und einem (schneller getaktetem, aber billigerem) 4 Kern System entscheiden müsste: Das 4-Kern System nehmen.

Openbuildings.com

Es passiert nicht besonders oft, aber es passiert: Die Graphik verschwindet vollständig, und statt dessen sieht man nur noch ein rotes Kreuz. Was bedeutet das, und was tut man dann?

Das rote Kreuz sagt im Wesentlichen, das eine Situation eingetreten ist, mit der der Programmierer nicht gerechnet hat – und das Programm ist dann beim zeichnen abgestürzt. Allerdings betrifft das nur den Teil des Programms der die Graphik mal: Der Rest geht noch.

Was kann man tun?

Der einfachste Weg lautet: Baustatik beenden und dann neu starten.

Der möglicherweise etwas praktikablere Wege geht so:

• Die letzte Änderung rückgängig machen. (Die letzte Änderung ist mit recht großer Sicherheit der eigentliche Auslöser.). Das geht per Bearbeiten –> Rückgängig machen.
• Dann ein neues Fenster öffnen.  Fenster –> Neues Fenster. (Jetzt sollte es wieder eine sichtbare Graphik geben.)
• Dann das Fenster mit dem roten Kreuz schließen.

Ab dem nächsten Update: Eine kleine Detailverbesserung bei der Symbolik von Streckenlagern.

Bisher:

Dann:

Diesmal: Ein Start des Space Shuttles aus der Sicht eines Boosters. (In diesem Fall aus der Mission STS-124)

In den ersten 2 Minuten passiert nicht viel: Dann wird der Booster abgetrennt und fällt zur Erde zurück – das wird dann interessant.

Für die Performance-Betrachtungen bei der Baustatik müssen ganz unterschiedliche Szenarien untersucht werden: Es macht zum Beispiel einen großen Unterschied, ob es sich um ein Tragwerk aus Stäben oder aus Faltwerkselementen, oder um eine Mischung davon handelt. Es macht auch einen Unterschied ob hauptsächlich Lastfälle überlagert werden, oder nichtlineare Gruppen berechnet werden. Dann geht es noch drum, was genau eigentlich betrachtet werden muss: Ist es der Netzgenerator, der Solver, der (die) Bemesser oder der Überlagerer, die Plausibilitätskontrolle und so weiter und so fort.

Gestern bin ich (aus ganz anderen Gründen) über einen Fall gestolpert, den wir hier offenbar noch nie auf Performance hin untersucht haben: Ein Stabwerkssystem mit vielen Stäben, in dem auch ein paar Faltwerkselemente verbaut sind. (Konkret ging es um dieses System.)

Im vorliegenden Fall ging es um die Netzerzeugung: Und die ist in solchen Fällen ab sofort dramatisch schneller.  Nach der Optimierung sank die benötigte Zeit (beim genannten Beispiel) auf meinem System von über 40 auf unter 15 Sekunden. Eine ähnlich Beschleunigung ist bei derartigen Systemen auf allen Rechnern (ab dem nächsten Update) zu erwarten.

Davon ab werden wir auch den Netzgenerator noch parallelisieren, sodass auf Multicore oder Manycore-Systemen noch darüber hinausgehende Performance-Verbesserungen eintreten werden.

Vom IBS-Kiel geplant mit der Baustatik:  Eingebaut sind 3 Faltwerkselemente und über 500 Stäbe, betrachtet werden > 30 nichtlineare Lastfallgruppen.

Heute gesehen: Ein “Erdhaus” aus der Schweiz – mit Fenstern nur an der Vorderseite:

Stammt von der Heiniger Ingenieure AG, gerechnet mit der Baustatik nach SIA.

Wenn man mit der Baustatik eine Fehlermeldung verschickt, dann landet die im allgemeinen in meiner Inbox – und ich beantworte die auch im allgemeinen (möglichst noch am gleichen Tag – das geht allerdings nicht immer.).

Meistens handelt es sich um einfache Probleme (manchmal auch um welche, die ich beim besten Willen nicht reproduzieren kann – und die dann auch nie wieder auftreten.), aber manchmal gibt es “interessante” Fälle – und heute hatte ich davon gleich 2 Stück. Ich glaube das man sich ohne diese Fehler tatsächlich gesehen zu haben nur sehr schlecht vorstellen kann, wie komplex sowas werden kann…. Darum hier einmal 2 Beschreibungen der Scenarios meiner “interessanten” Fälle von heute.

Nummer 1

Der Fehler tritt unter folgenden Bedingungen auf:

• Der Rechner muss mindestens 2 CPUs aufweisen
• Das System muss berechenbar sein und darf bei der FEM-Berechnung keine Meldungen oder sonstige Informationen in der Meldungsansicht anzeigen.
• Bei der Bemessung muss es mindestens eine Meldung in der Meldungsansicht anzeigen
• Die Option für “Alle CPUs gleichzeitig verwenden” muss eingeschaltet sein
• Die Meldungsansicht muss geschlossen sein
• In diesem Zustand müssen Bemessungsergebnisse angefordert werden
• Die FE-Berechnung wird durchgeführt und das Fenster für die Auswahl des gewünschten Bemessungsergebnisses wird angezeigt. (Die Meldungsansicht muss noch immer geschlossen sein.)
• Jetzt wird ein Bemessungsergebnis ausgewählt
• Und dann tritt der Fehler auf. (Ab dem nächsten Update aber nicht mehr)

Nummer 2

Bedingungen und benötigte Reihenfolge:

• Das Fenster für Bemessungsergebnisse muss angezeigt werden
• Es müssen Biegedrillknick-Ergebnisse angezeigt werden, und die Ergebnisse für mindestens einen Stabzug müssen nicht nachweisbare Stellen enthalten.
• Das Fenster “Bemessungsanalyse” muss ebenfalls geöffnet sein (Es zeigt die ersten nicht nachweisbaren Position der Stäbe und Stabzüge an)
• Jetzt muss der Stabzug der die nicht nachweisbaren Stellen enthält verändert werden. Die Änderung muss so erfolgen, das der Stabzug nach der Änderung keine Stäbe mehr enthält. (z.B. durch die Auswahl “ungünstiger” Knoten.)
• Schließlich muss im Fenster “Bemessungsergebnisse” ein anderes Biegedrillknick-Ergebnis ausgewählt werden
• Dann tritt der Fehler auf. (Aber auch nicht mehr nach dem nächsten Update)

In der aktuellen Version der Baustatik ist es möglich, Streckeneinwirkungen nicht nur auf Stäbe, sondern auch auf Stabzüge aufzubringen. Das ist schön, hat aber auch leider ein kleines Problem mit sich gebracht: Wenn eine Stab-Streckeneinwirkung keinen Stab zugewiesen hat, dann führt das zu einem Programmfehler. Im nächsten Update ist das korrigiert, aber bis dahin kann man sich auf folgende Art behelfen:

• Das Fenster mit der Fehlermeldung muss zunächst so verschoben werden, das es sich nicht innerhalb des Arbeitsfensters befindet. (Ansonsten erscheint die Meldung sofort wieder, wenn man sie schließt.)
• Man darf dann nicht mit der Maus über das Arbeitsfenster fahren, ansonsten erscheint die Meldung wieder, und man muss sie dann wieder aus dem Arbeitsfenster bewegen und schließen.
• Dann schließt man das Fenster mit der Fehlermeldung
• Jetzt kann man verschiedene Dinge tun: Im wesentlichen geht es aber darum, die Streckeneinwirkung zu korrigieren. Dazu ist es am einfachsten, wenn man auf Datei –> Vollständige Dokumentüberprüfen drückt.
• Daraufhin erscheint in der Meldungsansicht eine Fehlermeldung, die die Streckenlast betrifft. (Wenn die Meldungsansicht nicht sichtbar ist, kann man sie mit “Fenster –> Meldungen” anzeigen lassen.
• In der Meldungsansicht doppelklickt man nun auf die Fehlermeldung. Das öffnet das Fenster mit den Eigenschaften der betroffenen Streckenlast.
• Die korrigiert man nun, indem man ihr einen Stab zuweist.
• Jetzt kann man wieder ein normales Arbeitsfenster öffnen (“Fenster –> Neues Fenster”) und weiterarbeiten.

Gehe ich hin: 10. September im Wirtshaus im Schlachthof

Diesmal: Halo 2600 (in der Originalversion; leichte Unterschiede zur XBox sind bemerkbar) und Spaß mit Wolfram Alpha: Are you Skynet?

Die Baustatik konnte “von Anfang an” ISB-CAD Dateien (.GEO) importieren. Allerdings wurden Einwirkungen die bereits im CAD System definiert wurden nicht mit eingelesen. Ab dem nächsten Update ändert sich das: Es werden dann auch Strecken-, Flächen-, und Einzeleinwirkungen sowie die ISB-CAD möglichen “Gesamtlasten” importiert.

Dazu benötigt man die (von Haus aus automatisch angelegten) Lastfälle “1” und “2”. Alle ständigen Lasten landen nach dem Import in Lastfall 1, die Verkehrslasten in Lastfall 2.

Gut: Patterns for Parallel Programming (PDF)