Neue Boxsim-Version 1.10

[UweG]

Probiere mal Boxsim an einer Stelle zu entpacken, an der Du Lese- und Schreibrechte hast. Ich bekomme zwar nicht diesen Fehler, aber aus einem schreibgeschützten Verzeichnis will Boxsim nicht immer.

[Thiel]

kennt die meldung einer ?

habe das problem leider immer noch. ist die neuste version der homepage und der fehler tritt auch auf, wenn ich etwas selber erstellen will.

Edit:

Problem behoben! Habe mir nochmals die gleiche Version runtergeladen und jetzt funktioniert es.

[Peter K]

Hallo Uwe,

So. Jetzt habe ich etwas mehr Zeit, für einen ausführlicheren Kommentar:
Die elektrischen Frequenzgänge könnten auch noch hinkommen. Sonst ist das 100% richtig. Anders formuliert steht da: Wenn man in einem anderen Gehäuse als dem simulierten gemessen hat, aber angibt, in dem simulierten Gehäuse gemessen zu haben, dann stimmt das Ergebis nicht mehr.

Jein, der Achsenfrequenzgang ändert sich überhaupt nicht, den interpretiert Boxsim wohl (richtig) als in dem angegebenen Gehäuse gemessen.

Boxsim ist bedauerlicherweise derzeit nicht in der Lage, Messungen aus einem beliebigen Gehäuse zu akzeptieren und gleichzeitig den Treiber in einem anderen Gehäuse zu simulieren. Ausnahmen sind lediglich die VISATON-Testboxen, die DIN-Schallwand und die unendliche Schallwand.

Kann doch eigentlich nicht sooo unendlich schwierig sein, mit variablen Abmessungen auf unendliche Schallwand rückzurechnen, wenn das bei 5 Abmessungen geht, bei der Vorwärtssimulation mit Schallwandabmessungen und Treiberpositionen auf der Schallwand geht es ja auch....
Denn das wäre auch für denjenigen, der eigene Messungen verarbeitet wirklich genial, wenn er im Gehäuse X misst und in boxsim überprüfen könnte, wie sich die Dinge bei Gehäuse Y oder Z ändern würden.....

Unter der obigen Voraussetzung, dass das wirkliche Messgehäuse gar nicht dem angegebenen entspricht, sind natürlich auch die Ergebnisse zumindest fragwürdig.
Zum Thema "macht Boxsim sowieso falsch":
1. Stimmt. Jede Simulation ist falsch, fragt sich nur um wie viel.
2. Es stimmt auch, dass es einen Fall gibt, in dem zwei unterschiedliche Chassisanordnungen, die in der Praxis genau den gleichen Energiefrequenzgang ergeben, in Boxsim bis zu 4,5 dB unterschiedliche Ergebnisse liefern. Das ist zwar ein Extrembeispiel, aber diesen Fall gibt es auch. Ich bestreite nicht, dass beim Energiefrequenzgang der Glaube an die Genaugkeit infolge der schwierigen Nachmessbarkeit vielleicht manchmal etwas zu groß ist. Eine deutliche Erhöhung der Anzahl der simulierten Richtungen wäre hier der Präzision sicherlich sehr dienlich.

Da haben wir uns ja schon ausserhalb des Forums ausgetauscht, da stimme ich dir zu, zumal ich den Eindruck habe, zumindest, da etliche Boxsim-User auch sehr auf den Energiefrequenzgang achten, man ihnen aber ehrlicherweise sagen sollte, daß sie den besser nicht auf die Goldwaage legen sollten.

3. Ich kenne keinen Fall, in dem Boxsim mit korrekten Eingaben wirklich unsinnige Ergebnisse liefert. Wenn Boxsim ein Loch im Energiefrequenzgang simuliert, dann ist da in der Regel auch eins, auch wenn es vielleicht etwas tiefer oder weniger tief ist.

Die Absolutgenauigkeit ist nicht das grundlegende Problem, das ist eher, daß boxsim oft ausgeglichenen Energiefrequenzgang simuliert, wo eigentlich ein Energiefrequenzgangeinbruch sein MUSS

Die zappeligen Frequenzgänge der Auf-Achse-Messungen werden genau dann als Halbraumfrequenzgänge "verkauft", wenn man angibt, es seien welche. Das habe ich eben nochmal verifiziert.

Das verstehe ich jetzt nicht, wo kann ich denn da was diesbezügliches eingeben ausser "in der zu simulierenden Box" ??

Der Achsenfrequenzgang stimmt in der Tat auch dann wenn man zwar im gleichen Gehäuse Treiber und Box gemessen hat, in Boxsim aber ein anderes angibt. Den Rest kann man dann vergessen - stimmt.
Bei Messungen in der zu simulierenden Box sind Vorwärts- und Rückwärtssimulation der Schallwand identisch - sie werden aber definitiv durchgeführt. Deshalb sollten bei korrekter Eingabe der Schallwandmaße auch die Richtungsfrequenzgänge im Rahmen der Simulationsgenauigkeit stimmen. Wenn nicht, dann verstehe ich das gerade nicht.

Hätte ich eigentlich bei den horizontalen Richtungsfrequenzgänge auch erwartet (erhofft), ist aber leider nicht so.
Vertikal habe ich mit deutlichen Abweichungen gerechnet, traf auch zu, weil bei einer realen Vertikalmessung der TT, wenn der HT die Drehachse ist, ja mit jedem Winkel den Abstand zum Mikro ändert.
Hier mal die Messanordnung auf Drehteller:

Zusammenfassung: Boxsim ist darauf getrimmt worden, aus nur einer Messung auf Achse, alle Richtungsfrequenzgänge zu simulieren. Mit Messdaten für verschiedene Richtungen kann es nicht wirklich etwas Sinnvolles anfangen.

Dazu muss man wissen, dass der Begriff "eigene Messungen" in diesem Fall bedeutet, dass Frequenzgangmessdaten für alle Chassis in alle Richtungen vorliegen. SO pauschal, wie es hier gelesen werden kann, ist das Unfug.

Wir haben die Messungen ja auch deswegen gemacht (auch als Übungsprojekt für Fachvorträge innerhalb der Selbstbaugruppe), um überprüfen zu können, ob man sich die Winkelmessungen sparen könnte, wenn boxsim da halbwegs genau arbeiten würde. Unsere diesbezügliche Enttäuschung kannst du evtl. nachvollziehen...
Dabei wäre es so einfach: Rückrechnung auch von Fremdmessungen vom angegebenen Gehäuse ausgehend auf unendliche Schallwand, genau wie bei den vier Visaton-Varianten und fertig....
Wenn es allerdings so ist, daß die Winkelsimulationen deiner Aussage nach bei Verwendung der Maße des Messgehäuses stimmen sollten, dann habe ich ab sofort kein Zutrauen mehr zu den von Boxsim mit Visaton-Chassis dargestellten Winkelfrequenzgängen, dazu sind die Abweichungen unserer Messungen zu den boxsim-Simulationen zu deutlich.

Zitat der Boxsim-Homepage: "Zielgruppe sind ambitionierte Lautsprecher-Selbstbauer, die bereits über grundlegende Kenntnisse zur Berechnung von Lautsprechern verfügen."

Gerade diese Zielgruppe erwartet IMHO etwas mehr als "Deppensicherheit" und unnötige Gängelung (siehe Optimierer)

Wenn jemand in der Lage ist, Messdaten seiner eingebauten Chassis für alle Richtungen anzufertigen, dann spielt er für mich nicht mehr in der Hobby-Liga.

Das ist deine Auslegung, das kann man auch als "ambitionierten Lautsprecher-Selbstbauer" definieren.

Dort ist es schon viel, überhaupt eine sinnvolle Messung zustande zu bekommen. Wenn Entwickler Messdaten für alle Richtungen zur Verfügung hätten, wäre das ganze Konzept von Boxsim zu hinterfragen, nicht nur der Optimierer.

Ja schade eigentlich, zumal boxsim einige geniale Ansätze hat, die es so meines Wissens nach noch nicht gab.
Nicht auszudenken, was aus dem Prog hätte werden können, wenn du nicht mehr oder weniger eine etwas halsstarrige One-Man-Show daraus gemacht hättest.

Viele Grüße
Peter Krips

[UweG]

So. Jetzt habe ich etwas mehr Zeit, für einen ausführlicheren Kommentar:

Zitat aus einem anderen Forum:

Wenn Uwe das Programm schon so "deppensicher" angelegt hat, da wäre es sinnvoll, bei der Abfrage mit den eigenen Messungen die Schallwandmaße, Treiberposition, Treibergrößen etc. des Messobjekts abzufragen und genauso wie bei den Visatonchassis auf unendliche Schallwand rückzurechnen und dann bei Gehäuseänderungen umzurechnen.
So, wie es derzeit angelegt ist, sind SÄMTLICHE Berechnungen des Progs ausser dem Achsenfrequenzgang im Original(Mess-)gehäuse und dem Impedanzverlauf, möglicherweise noch der Phase für die Tonne...., sobald man andere Schallwandabmessungen eingibt, als bei der Messung verwendet.

Die elektrischen Frequenzgänge könnten auch noch hinkommen. Sonst ist das 100% richtig. Anders formuliert steht da: Wenn man in einem anderen Gehäuse als dem simulierten gemessen hat, aber angibt, in dem simulierten Gehäuse gemessen zu haben, dann stimmt das Ergebis nicht mehr. Boxsim ist bedauerlicherweise derzeit nicht in der Lage, Messungen aus einem beliebigen Gehäuse zu akzeptieren und gleichzeitig den Treiber in einem anderen Gehäuse zu simulieren. Ausnahmen sind lediglich die VISATON-Testboxen, die DIN-Schallwand und die unendliche Schallwand.

Wahrscheinlich sind auch die Winkelsimulationen im Messgehäuse nicht brauchbar, da vermutlich bestimmte Welligkeiten im Achsenfrequenzgang, die von Kantenreflexionen herrühren, falsch interpretiert werden, da keine Rückrechnung auf unendliche Schallwand stattfindet.

Unter der obigen Voraussetzung, dass das wirkliche Messgehäuse gar nicht dem angegebenen entspricht, sind natürlich auch die Ergebnisse zumindest fragwürdig.

Da dann aber auch weder der Energiefrequenzgang noch das Bündelungsmaß richtig berechnet wird (mach boxsim sowieso falsch), wäre es sinnvoller, bei Verarbeitung von eigenen Messungen alle anderen Berechnungen ausser dem Achsenfrequenzgang abzuschalten....
Wenn du dir mal den HT unter Chassis ansiehst, dann wird das deutlich: Da wird der wellige Frequenzgang der Achsenmessung als Halbraumfrequenzgang "verkauft"."

Zum Thema "macht Boxsim sowieso falsch":
1. Stimmt. Jede Simulation ist falsch, fragt sich nur um wie viel.
2. Es stimmt auch, dass es einen Fall gibt, in dem zwei unterschiedliche Chassisanordnungen, die in der Praxis genau den gleichen Energiefrequenzgang ergeben, in Boxsim bis zu 4,5 dB unterschiedliche Ergebnisse liefern. Das ist zwar ein Extrembeispiel, aber diesen Fall gibt es auch. Ich bestreite nicht, dass beim Energiefrequenzgang der Glaube an die Genaugkeit infolge der schwierigen Nachmessbarkeit vielleicht manchmal etwas zu groß ist. Eine deutliche Erhöhung der Anzahl der simulierten Richtungen wäre hier der Präzision sicherlich sehr dienlich.
3. Ich kenne keinen Fall, in dem Boxsim mit korrekten Eingaben wirklich unsinnige Ergebnisse liefert. Wenn Boxsim ein Loch im Energiefrequenzgang simuliert, dann ist da in der Regel auch eins, auch wenn es vielleicht etwas tiefer oder weniger tief ist.
Die zappeligen Frequenzgänge der Auf-Achse-Messungen werden genau dann als Halbraumfrequenzgänge "verkauft", wenn man angibt, es seien welche. Das habe ich eben nochmal verifiziert.

Dann haben wir mal probeweise andere Schallwandabmessungen im gemeinsamen Aussengehäuse und deutlich andere Treiberanordnungen der gemessenen Treiber eingegeben und sind dann zu folgender Einschätzung gelangt:

Zweites Zitat:

"Ja, war auch zu erwarten, da Summierung im unendlichen stattfindet.
Mit anderen Worten als Nachtrag zu meinem vorherigen Post:
Es ist wohl vollkommen egal, welche Schallwandabmessungen und Treiberpositionen man bei eigenen Messungen verwendet:
Die Achsensimu ist jeweils gleich korrekt, den Rest der Berechnungen incl. Energiefrequenzgang etc. kann man vergessen..."

Der Achsenfrequenzgang stimmt in der Tat auch dann wenn man zwar im gleichen Gehäuse Treiber und Box gemessen hat, in Boxsim aber ein anderes angibt. Den Rest kann man dann vergessen - stimmt.
Bei Messungen in der zu simulierenden Box sind Vorwärts- und Rückwärtssimulation der Schallwand identisch - sie werden aber definitiv durchgeführt. Deshalb sollten bei korrekter Eingabe der Schallwandmaße auch die Richtungsfrequenzgänge im Rahmen der Simulationsgenauigkeit stimmen. Wenn nicht, dann verstehe ich das gerade nicht.

Drittes Zitat:

"Auch das ist ausgezeichnet zusammengefasst und muss bei Simulationen mit
eigenen Messungen berücksichtigt werden:
Nur der Hauptfrequenzgang (Frequenzgang Gesamtbox) des selbst gemessenen
Lautsprechers ist korrekt und zwar für den Mikrofonmesspunkt.

Ein Schritt weiter:
Würde man ins Boxsim für den Hochtöner und den Tieftöner die 30-Grad Messung einpflegen,
dann würde Boxsim auch diesen Frequenzgang unter Frequenzgang Gesamtbox korrekt darstellen,
denn Boxsim verknüpft die eingelesenen Chassis-Frequenzgänge korrekt.

Für die anderen Winkelmessungen müsste man genauso verfahren.

Für eigene Messungen gilt
(Mikrofon ist während der Messung an einer festen Position):
Man müsste also für jeden Winkel ein Boxsim-Projekt anlegen, wenn man in Boxsim die korrekten Frequenzgänge unter Winkeln haben möchte."

Nach unseren Erfahrungen muß man also bei Verarbeitung von eigenen Messungen folgendermaßen zusammenfassen:

1.) Der Frequenzgang auf Achse wird korrekt simuliert, dabei ist es unerheblich, welche auch vom Messobjekt abweichende Schallwandgröße und Treiberposition gewählt wird.

2.) Auch mit der korrekten Schallwandabmessung des Messobjekts werden Ausser-Winkel Frequenzgänge und somit auch Energiefrequenzgang und Bündelungsverhalten falsch berechnet.

3.) Daraus folgt, daß man dann nicht auf einen Ausser-Achse-Winkel (wie z.B.) 30 Grad optimieren kann, da der Winkel wie auch alle anderen nicht korrekt simuliert wird.

Zusammenfassung: Boxsim ist darauf getrimmt worden, aus nur einer Messung auf Achse, alle Richtungsfrequenzgänge zu simulieren. Mit Messdaten für verschiedene Richtungen kann es nicht wirklich etwas Sinnvolles anfangen.

4.) Die Verwendung des Optimierers in der vorliegenden Form macht bei Projekten mit eigenen Messungen keinen Sinn, da all die umfangreichen Berechnungen eh nicht benötigt werden, falsch sind und völlig unnötige Rechenzeit kosten.

Dazu muss man wissen, dass der Begriff "eigene Messungen" in diesem Fall bedeutet, dass Frequenzgangmessdaten für alle Chassis in alle Richtungen vorliegen. SO pauschal, wie es hier gelesen werden kann, ist das Unfug.

5.) Will man auch auch Winkelmessungen von eigenen Projekten richtig simulieren, dann muß man für jeden Winkel ein eigenes Projekt anlegen und dann die Frequenzweichenbauteile per Hand in jedes einzelne Winkelprojekt übertragen.
Das geht aber selbst mit dem Methusalem Audiocad deutlich schneller und komfortabler.

Für mich folgt daraus, daß die Arbeitsweise des boxsim-Optimierers grundlegend verändert werden sollte. Wie, ist ja im Wesentlichen in entsprechenden Threads auch hier gesagt worden.
Als wichtigstes sollte der reine Optimierungslauf NUR mit dem Achsenfrequenzgang stattfinden und nur nach Abschluß der Optimierung der ganze Wust an anderen Berechnungen EINMALIG gemacht werden, allerdings nicht bei Projekten mit eigenen Messungen, da dann all die anderen Auswertungen eh überflüssig wie ein Kropf sind.
Das würde auch die bisher ätzend lange Laufzeit der Optimierung deutlich beschleunigen.

Zitat der Boxsim-Homepage: "Zielgruppe sind ambitionierte Lautsprecher-Selbstbauer, die bereits über grundlegende Kenntnisse zur Berechnung von Lautsprechern verfügen."
Wenn jemand in der Lage ist, Messdaten seiner eingebauten Chassis für alle Richtungen anzufertigen, dann spielt er für mich nicht mehr in der Hobby-Liga. Dort ist es schon viel, überhaupt eine sinnvolle Messung zustande zu bekommen. Wenn Entwickler Messdaten für alle Richtungen zur Verfügung hätten, wäre das ganze Konzept von Boxsim zu hinterfragen, nicht nur der Optimierer.

[UweG]

Hallo Peter,

vielen Dank für Deinen ausführlichen Beitrag, aber die Aussagen sind z. T. sehr irreführend, weil unter z. T. nur bei genauem Lesen nachvollziehbaren Voraussetzungen verständlich. Eine ausführliche Antwort kommt noch.

Eines vorab: Gemessene Frequenzgänge für Boxsim sind immer auf Achse zu messen und zwar in einer der vier fest definierten Umgebungen. Alles andere ist falsche Bedienung und kein Programmfehler, allenfalls ein Dokumentationsmanko.

[Peter K]

Hallo All und Uwe im Speziellen,

nachdem wir uns in einer regionalen Selbstbaugruppe etwas ausführlicher mit einem selbstgemessenen Probeprojekt (360 Grad gemessen in 30 Grad Schritten sowohl horizontal als auch vertikal) befasst haben und eine Weichenentwicklung sowohl in Audiocad als auch in Boxsim gemacht haben, sind wir übereinstimmend zu folgender Einschätzung gelangt:

Zitat aus einem anderen Forum:

"Wenn Uwe das Programm schon so "deppensicher" angelegt hat, da wäre es sinnvoll, bei der Abfrage mit den eigenen Messungen die Schallwandmaße, Treiberposition, Treibergrößen etc. des Messobjekts abzufragen und genauso wie bei den Visatonchassis auf unendliche Schallwand rückzurechnen und dann bei Gehäuseänderungen umzurechnen.
So, wie es derzeit angelegt ist, sind SÄMTLICHE Berechnungen des Progs ausser dem Achsenfrequenzgang im Original(Mess-)gehäuse und dem Impedanzverlauf, möglicherweise noch der Phase für die Tonne...., sobald man andere Schallwandabmessungen eingibt, als bei der Messung verwendet.
Wahrscheinlich sind auch die Winkelsimulationen im Messgehäuse nicht brauchbar, da vermutlich bestimmte Welligkeiten im Achsenfrequenzgang, die von Kantenreflexionen herrühren, falsch interpretiert werden, da keine Rückrechnung auf unendliche Schallwand stattfindet.
Da dann aber auch weder der Energiefrequenzgang noch das Bündelungsmaß richtig berechnet wird (mach boxsim sowieso falsch), wäre es sinnvoller, bei Verarbeitung von eigenen Messungen alle anderen Berechnungen ausser dem Achsenfrequenzgang abzuschalten....
Wenn du dir mal den HT unter Chassis ansiehst, dann wird das deutlich: Da wird der wellige Frequenzgang der Achsenmessung als Halbraumfrequenzgang "verkauft"."

Dann haben wir mal probeweise andere Schallwandabmessungen im gemeinsamen Aussengehäuse und deutlich andere Treiberanordnungen der gemessenen Treiber eingegeben und sind dann zu folgender Einschätzung gelangt:

Zweites Zitat:

"Ja, war auch zu erwarten, da Summierung im unendlichen stattfindet.
Mit anderen Worten als Nachtrag zu meinem vorherigen Post:
Es ist wohl vollkommen egal, welche Schallwandabmessungen und Treiberpositionen man bei eigenen Messungen verwendet:
Die Achsensimu ist jeweils gleich korrekt, den Rest der Berechnungen incl. Energiefrequenzgang etc. kann man vergessen..."

Drittes Zitat:

"Auch das ist ausgezeichnet zusammengefasst und muss bei Simulationen mit
eigenen Messungen berücksichtigt werden:
Nur der Hauptfrequenzgang (Frequenzgang Gesamtbox) des selbst gemessenen
Lautsprechers ist korrekt und zwar für den Mikrofonmesspunkt.

Ein Schritt weiter:
Würde man ins Boxsim für den Hochtöner und den Tieftöner die 30-Grad Messung einpflegen,
dann würde Boxsim auch diesen Frequenzgang unter Frequenzgang Gesamtbox korrekt darstellen,
denn Boxsim verknüpft die eingelesenen Chassis-Frequenzgänge korrekt.

Für die anderen Winkelmessungen müsste man genauso verfahren.

Für eigene Messungen gilt
(Mikrofon ist während der Messung an einer festen Position):
Man müsste also für jeden Winkel ein Boxsim-Projekt anlegen, wenn man in Boxsim die
korrekten Frequenzgänge unter Winkeln haben möchte."

Nach unseren Erfahrungen muß man also bei Verarbeitung von eigenen Messungen folgendermaßen zusammenfassen:

1.) Der Frequenzgang auf Achse wird korrekt simuliert, dabei ist es unerheblich, welche auch vom Messobjekt abweichende Schallwandgröße und Treiberposition gewählt wird.

2.) Auch mit der korrekten Schallwandabmessung des Messobjekts werden Ausser-Winkel Frequenzgänge und somit auch Energiefrequenzgang und Bündelungsverhalten falsch berechnet.

3.) Daraus folgt, daß man dann nicht auf einen Ausser-Achse-Winkel (wie z.B.) 30 Grad optimieren kann, da der Winkel wie auch alle anderen nicht korrekt simuliert wird.

4.) Die Verwendung des Optimierers in der vorliegenden Form macht bei Projekten mit eigenen Messungen keinen Sinn, da all die umfangreichen Berechnungen eh nicht benötigt werden, falsch sind und völlig unnötige Rechenzeit kosten.

5.) Will man auch auch Winkelmessungen von eigenen Projekten richtig simulieren, dann muß man für jeden Winkel ein eigenes Projekt anlegen und dann die Frequenzweichenbauteile per Hand in jedes einzelne Winkelprojekt übertragen.
Das geht aber selbst mit dem Methusalem Audiocad deutlich schneller und komfortabler.

Für mich folgt daraus, daß die Arbeitsweise des boxsim-Optimierers grundlegend verändert werden sollte. Wie, ist ja im Wesentlichen in entsprechenden Threads auch hier gesagt worden.
Als wichtigstes sollte der reine Optimierungslauf NUR mit dem Achsenfrequenzgang stattfinden und nur nach Abschluß der Optimierung der ganze Wust an anderen Berechnungen EINMALIG gemacht werden, allerdings nicht bei Projekten mit eigenen Messungen, da dann all die anderen Auswertungen eh überflüssig wie ein Kropf sind.
Das würde auch die bisher ätzend lange Laufzeit der Optimierung deutlich beschleunigen.

Viele Grüße
Peter Krips

[Grashopper]

Mal so als allgemeine Frage:
Wie schnell empfindet ihr Boxsim subjektiv bei normaler Rechnung / beim Optimierer?
Mein persönlicher Eindruck ist:
Normale Berechnung könnte einen Deut schneller sein, es stört aber nur wenig.
Der Optimierer ist zwar noch benutzbar, würde aber von einer Beschleunigung deutlich profitieren.

Ich würde es begrüßen wenn die normale Berechnung schneller ablaufen würde. Vielleicht kann man das auch in 3 (2) Threads erledigen. Immerhin wird die normale Berechnung öfter ausgeführt. Subjektiv stört mich das etwas. Mit dem Weichenoptimierer kann ich leben.

[istec1003]

[...]
Mal so als allgemeine Frage:
Wie schnell empfindet ihr Boxsim subjektiv bei normaler Rechnung / beim Optimierer?
Mein persönlicher Eindruck ist:
Normale Berechnung könnte einen Deut schneller sein, es stört aber nur wenig.
Der Optimierer ist zwar noch benutzbar, würde aber von einer Beschleunigung deutlich profitieren.

Sehe ich genauso. Normale Berechnung ist ausreichend schnell, Optimierer würde profitieren.

[UweG]

Boxsim scheint den normalen FG auf einem Kern zu berechnen (~25% Gesamtast) und bietet erst beim Bauteiloptimierer eine Dualcoreunterstützung (~50% Gesamtlast).

Ganz genau. Die normale Berechnung läuft nur in einem Thread, der Optimierer in dreien, wobei einer der drei nur sehr wenig zu tun hat.
Ich habe auch schonmal mit einer 5-Thread-Version des Optimierers experimentiert, die hat sich aber auf einem Dualcore so schlecht bewährt, dass ich annehme, dass sie selbst auf einem Quadcore nur marginal schneller wäre als die jetzige.

Mal so als allgemeine Frage:
Wie schnell empfindet ihr Boxsim subjektiv bei normaler Rechnung / beim Optimierer?
Mein persönlicher Eindruck ist:
Normale Berechnung könnte einen Deut schneller sein, es stört aber nur wenig.
Der Optimierer ist zwar noch benutzbar, würde aber von einer Beschleunigung deutlich profitieren.

[VENTILIERT]

Ich sags Dir, wenn der Optimierer fertig ist (läuft gerade)...
Außerdem ist es nicht immer von VOrteil, wenn man selbst die Werte für die Weichenänderung überprüft. Ich werde nächstes Mal E12 Reihe einstellen.

[Grashopper]

WinXP 32bit mit 4GB Ram
Phenom II 940 @3.4GHz

Wir haben aber keine Abweichungen. Boxsim scheint den normalen FG auf einem Kern zu berechnen (~25% Gesamtast) und bietet erst beim Bauteiloptimierer eine Dualcoreunterstützung (~50% Gesamtlast).
Oder hast du beim reinen FG berechnen eine Auslastung von über 25% ?

[VENTILIERT]

Außerdem stelle ich leichte Darstellungsfehler des Weichenoptimierers bei 1920x1200 fest, falls noch nicht bekannt. Im unteren Bereich des Fensters wären 20 - 50 Pixel mehr Höhe nicht schlecht.
@grashopper: Welches OS verwendest Du? Wieviel RAM hast du verbaut?
Ein Viertel der Rechenzeit wird wahrscheinlich auch nicht möglich sein. Durchschnittlich sind die Kerne bei mir 50 % ausgelastet. Die einzelnen Kerne zwischen 30 u. 90 Prozent, wie gesagt. Ich wundere mich mich nur, warum wir solche Abweichungen haben.
OS Vista 64 SP2
8GByte
4 x 3,2 GHz
??

[VENTILIERT]

Ich meine, wenn ich mir jeden Kern ansehe, dann ist das ersichtlich. Auch beim Gadget CPU Usage ist dies erkennbar......

[Grashopper]

Ja, das macht der Task-Scheduler von Windows. Der teilt die Berechnungen auf 4 Kerne auf, jedoch nicht parallel sondern seriell. 25% Auslastung bedeutet somit nur 1 Kern. Legst du die Zugehörigkeit von Boxsim auf einen Kern hast du dort 100% Auslastung und die restlichen Kerne werden nicht genutzt.
Wirklich nötig wäre ein Mehrkernunterstützung für mich jedoch nicht. Mit 3.4GHz dauert es nun wirklich nicht lange bis die Berechnung fertig ist. Ein Viertel (ca.) der Rechenzeit, die man durch eine Multicore-Unterstützung erhalten würde, wäre jedoch grandios

[VENTILIERT]

Bei meiner Vista 64 Version stelle ich eine (anteilige) Auslastung auf allen Kernen fest