---

Hallo,

Habe heute für meine 64Bit Win7 Maschine (i5-2500 quadcore) 16GB Speicher bekommen (vorher waren es 4gb). Nun habe ich schon einige Test gemacht und habe deutliche Performancegewinne zu verzeichen. Bei statischen Berechnungen von Verformungen infogle eines Temperaturfeldes brauche ich jetzt nur noch 2 statt 5 min. Das ist ja schon mal toll. Allerdings lagert er weithin Daten ins TEMP-Verzeichniss auf die Festpaltte aus. Das bremst bestimmt.

Kann ich dem NX Nastran irgendwo sagen, dass es erst mal den RAM ausnutzen soll bevor es auf die Festplatte schreibt?

Danke
JonkMcCool

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Du solltest in Deinem Profil angeben, mit welcher Version Du arbeitest.

>>Kann ich dem NX Nastran irgendwo sagen, dass es erst mal den RAM ausnutzen soll bevor es auf die Festplatte schreibt?

Such mal in Deiner Online-Hilfe nach "File Mapping" oder "mapio".

Falls Du Deine WS noch weiter nachrüsten darfst - beschaff Dir eine SSD = SolidStateDisk = RAM als Festplatte.
Die Zugriffe auf einen solchen Halbleiterspeicher erfolgen wesentlich schneller als die auf eine klassische Magnetplatte.

------------------
R.Schulze

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Der Umzug des Betriebssystems auf eine SSD ist aber nicht gerade sehr einfach.
Am besten ist sich da noch mal genau einzulesen, ala C't oder vergleichbares.

------------------
Danke und Gruß Robert

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,

danke erst mal für die Hinweise.

1. SSD kommt vielleicht noch. Habe mal eine ausprobiert, allerdings war die so alt, dass sie keinen Vortei gebracht hat, eher Nachteile. Zusatätzlich CPU-Last und z.T. erheblich Verlängerung der Rechenzeit. Hatte dabei (und würde auch bei einer neuen) die SSD nur zum auslagern des TEMP-Verzeichnisses nutzen, nicht das ganze System.

2. Filemapping muss ich noch probieren. Hatte mich zunächst auf etwas anders konzentiert, und zwar:

3. Habe ich unter Solverparameter verschiedene Dinge ausprobiert z.B. scratch ja/nein/mini und auch die Speichergröße 400MB bis 8.000MB. Das ist alles sehr mysteriös, was dann auf der Fesplatte bzw. im Speicher landet und was es für einfluss auf die Rechenzeit hat. Ich berichte noch im Eizelnen.

Bis hain erst mal Gruß
JonkMcCool

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo JonkMcCool

Eine weiter, vielleicht nicht ganz so kostpielige Lösung wie eine SSD wäre eine RAMDISK. Mit der richtigen Software (natürlich gibts die leider nicht umsonst), kannst Du dein Temp und deine Pagefile in eine virtuelle HDD, die sich im RAM befindet, laden. Das hat den Charm, dass die Pagefile nicht fragmentiert und der Temp nach jedem Neustart leer ist.

Gruß Jens :-)

------------------
Bunt ist das Dasein und granatenstark UND volle Kanne Hoschies! (Bill und Ted)

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Jens,

das haben wir auch schon diskutiert, das wäre natürlich super. Gibt aber 2 Probleme:

1. Ich habe hier keine Administratorrechte und somit müsste ich wahrscheinlich jedesmal fragen, wenn ich irgendwas ändern will, Größe oder so.

2. Wenn die Disk dann voll ist, kann man NX leider nicht beibringen, auf eine andere Disk auzuweichen. So ein ähnliches Problem hatte ich schon mal vor längerer Zeit, damals reichte der Platz auf der einen Platte nicht mehr aus und es gab keinen Weg, NX zu sagen: "mach da weiter". http://ww3.cad.de/foren/ubb/Forum4/HTML/008934.shtml

Es gibt aber wohl kostenlose RAMdisk Software. Guck ich noch mal.

Kostspielig ist dass alles nicht, 16GB RAM 70€, 60GB SSD 80€. Nur sinnvoll muss es sein. Das gilt vor allem für das Anschaffen von größeren Maschinen, da sollte das Geld an der richtigen Stelle ausgegeben werden. Deshalb test ich das auch gerade durch, mit komischen Ergebnissen, ich komme noch dazu.

Danke erst mal!
Gruß
JonkMcCool

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

NXNastran_Solver_Param.JPG

Moin,

das Verhalten hat mich auch schon lange genervt - obwohl in meinem aktuellen Rechner eine SSD werkelt...  

Das Problem ist scheinbar, dass sich dem NX-Nastran-Solver nicht mehr als 8GB zuweisen lassen.
Das kann an grundsätzlich mehreren Stellen gesteuert werden:
- In der nast6.rcf ("Memory=..."), im Verzeichnis ...\NXNASTRAN\conf
- In den Anwenderstandards
- In den Solver-Parametern für jede Lösung
Ich hatte damit mal herumexperimentiert und festgestellt, dass ein zugewiesener Speicher >8192MB grundsätzlich zum Solverabbruch führt.

Anfang letzer Woche habe ich von Siemens ein SFB Summary bekommen und bin über die Beschreibung dieser Symptomatik gestolpert.
Im uganswer ist folgendes Solution Document zu finden: 002-7003789

Kurzfassung:
Es gibt drei Solver-Ausprägungen, nur eine davon nutzt alle Möglichkeiten der 64Bit-Umgebung.
Wird NX Nastran aus NX Advanced Simulation heraus gestartet, läuft der Solver per Default (logisch!   ) nicht als echter 64Bit-Prozess.

Durch Eintragung folgender Solver-Parameter kann man das aber hinkriegen - siehe Bild.

Ich hab das bei mir durch Setzen entsprechender userabhängiger Umgebungvariablen getestet, dann muss man das nicht für jede Lösung einzeln machen.
Was soll ich sagen: es funktioniert - die Scratch-Dateien werden zwar erzeugt, aber nix reingeschrieben, bisher hatte ich je nach Szenario ca. drei Dateien in der Größe mehrerer GB.

Der zusätzliche Witz ist, dass ich so aus unserer NX6-Produktivumgebung das NX Nastran 8.1 aus meiner Testinstallation einbinden kann - Nastran 7 (in NX7.5, NX7 hab ich nicht) funktioniert analog.
Die nastran64L.exe fehlt in der NX6-Umgebung noch...

Hinweis: Wird der Speicher (wie im Bild) größer 0,8*physischer Speicher zugewiesen, regelt Nastran die Zuweisung automatisch runter.

Viel Spaß beim Testen!

------------------
Hoffeeinehilfegewesenzusein  

Gruß
Ralf

Improvisieren ist nur dann eine Kunst, wenn man nicht unvorbereitet aussieht...

[Diese Nachricht wurde von Hightower205 am 19. Apr. 2012 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Andere Alternative:

Wäre eine Grafikkarte, die geeignet ist für diese FEM-Berechnungen nicht eine bessere Lösung?

Gruß
Andreas

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von JonkMcCool :
...

Es gibt aber wohl kostenlose RAMdisk Software. Guck ich noch mal.

...

---

Würde an deiner Stelle diesen Ansatz weiterverfolgen. Bei einer SSD bleibt immer noch der SATA-/SAS Bus als limitierender Faktor, beim anlegen einer "RAMdisk" im Arbeitsspeicher entfällt dies logischerweise. Dafür müsste aber dieser gegebenenfalls noch weiter vergrößert werden.

Wenn dann dein TEMP und auch der Virtuelle Arbeitsspeicher auf der RAMdisk liegen müsste das Kätzchen nur noch so schnurren...   

------------------
Schneller und effizienter – Ihr Mehrwert mit DPS!

Optimieren Sie Ihren Produktentwicklungsprozess

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

process_explorer.jpg

Hallo

Vielen Dank Hightower für deinen Beitrag. Ich habe mittlerweile ne Menge über das Speichermanagement herrausgefunden. Das ist allerdings etwas aufwendiger zu erklären, muss ich noch machen.

Daher erst mal noch ein paar Fragen und Hinweise zu deiner Variante:
Ich habe hier noch NX 7 und da gibt es keine nastran64L.exe. Bei mir gibt’s nur nastran.exe, nastranw.exe, nastran64.exe und nastran64w.exe. Ich habe versucht an der Stelle wo man auf die nastran.exe verweisen kann mal was einzugeben. Allerdings wird das einfach ignoriert. Ich kann da eingeben was ich will, sogar einen völlig falschen Pfad, gestartet wird trotzdem die ganz normale nastran.exe.

Ich kann das mit dem ProcessExplorer (siehe Bild) sehen. Ich kann den allen NX-Nutzern nur empfehlen. Neben der CPU- und Speicherauslastung kann man den wunderbar verwenden, um den ganzen Dingen die da ablaufen auf die Schliche zu kommen:

- dort sieht man die Struktur der Prozesse, wer welchen aufgerufen hat und dass es nastran.exe gleich zweimal gibt.
- man kann sehen, dass die eigentliche Arbeit von analysis.exe gemacht wird und dass die und die übergeordnete nastran.exe in einem Ordner namens \NASTRAN\nx6p1 steckt
- man erkennen, dass ich 8GB zugewiesen habe nur ca 2.2GB verwendet
- man kann sehen, wo überall auf der Festplatte geschrieben wird
- man kann sehen mit welchen zusätzlichen Parametern die nastran.exe aufgerufen wird

Schaut man jetzt noch in das Temp-Verzeichnis, dann sieht man, dass trotz 8GB zugewiesenen und unausgenutzen Speichers noch 2GB auf die Festplatte ausgelagert werden. Die Lösung, wie versprochen, in einem extra Beitrag!

Im Übrigen hat die Option Scratch=no nicht etwa zu Folge, dass weniger auf die Festplatte geschrieben wird, sondern nur, dass dazu nicht das vorgegebene Temp-Verzeichnis genutzt wird, sondern alles in dem Verzeichnis in dem die .sim-Datei liegt. Wer seine Daten auf einem Netzlaufwerk hat, sollte hier vorsichtig sein.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

ohne_SMEM.jpg mit_SMEM.jpg Einstellung_SMEM.jpg

Hallo Liebe Gemeinde,

Erst mal Vorab: Das Zauberwort heißt: SMEM (oder SMEMORY)! Mit diesem Befehl kann man angeben, wie viel Speicher, also RAM, für das Auslagern benutzt werden soll.

Ich will jetzt nicht zu sehr auf Buffers, Words, Buffzsize usw. eingehen, nur soviel: Die Standardeinstellung für SMEM liegt bei 100 Buffers. Das sind dann bei einer Standardbuffersize von 8193 gerade mal 3MB. Das liegt meiner Meinung nach daran, dass die Ursprünge des Nastran-Solvers weit in der Vergangenheit liegen, als Speicher noch wirklich knapp war. Damals hat man sicherlich versucht, so viel wie möglich Speicher für das Ausführen des Solvers freizuhalten. Wer schon mal ein großes Modell erstellt hat uns es nicht durchlief hat hier sicherlich Speicherprobleme gehabt, also nicht der Platz für Auslagern sondern der Platz, den der Solver tatsächlich zum Rechnen braucht. Dem Nastran-Solver kann man hier sicherlich keinen Vorwurf machen, den Kollegen von NX allerdings schon. Sie könnten ohne weiteres optimierte Einstellungen an den Nastran-Solver übergeben und somit das enorme Optimierungspotential auch ausnutzen. Ich habe hier eine Beispielrechung für Euch angefügt bei der mit einfachsten Einstellungen die Rechenzeit auf meinem Rechner von 16min 16sek auf 10min 53sek verringert wird, was einer Verkürzung der Rechenzeit um 33% entspricht.

Ich versuche das jetzt möglichst einfach zu erklären:
Wer Genaueres wissen will schaue bitte in das Nastran-Manual von MSC-NASTRAN auf Seite 141 (Seite 157 in PDF) unter folgendem Link: http://www.mscsoftware.com/support/prod_support/nastran/documentation/cog_2005.pdf

Grob gesagt kann man mit dem Befehl MEMORY (z.B. MEMORY=4000MB) den gesamten für Nastran verfügbaren Speicher definieren. Mit dem Befehl SMEM (z.B. SMEM=3500MB) kann man den Platz für die Auslagerung (Scratch Memory) festlegen. Durch das Benutzen des Speichers fürs Auslagern kann man das Schreiben auf die Festplatte minimieren, was zu erheblichen Verbesserungen führt (je nach Geschwindigkeit der Festplatte, RAM und CPU). Natürlich hängt das auch von der Art der Berechnung ab. Vor allem bei nichtlinearer Statik oder z.B. Kontaktelementen, wo viel hin und her geschrieben wird ist das sehr deutlich spürbar. Wer ein sehr großes Modell hat und das nur mit dem linearen Solver löst hat vielleicht nicht so viel davon, da hier 8GB ratz fatz voll sind und dann doch ausgelagert werden muss. Sehr aussagekräftig hierfür ist die die Datei .f04. Dort steht ganz am Ende eine sehr aufschlussreiche Übersicht mit dem Titel:

*** DATABASE USAGE STATISTICS ***

Hier interessieren uns vor allem zwei Werte: Zum einen die letzte Spalte I/O TRANSFERRED, dort steht unter TOTAL die Menge an Daten die auf der Festplatte hin und her geschrieben wurden. In meinem kleinen Beispiel sind das bei mir 613GB!!! Die andere interessante Zahl ist in der Spalte zuvor unter HIWATER zu finden. Hier steht, wie groß die Auslagerungsdatei (bzw. der benutzte Speicher) während der Berechnung maximal war. Im meinem Beispiel sind das bei Auslagerung ca. 138MB bzw. beim Verbleib im Speicher ca. 143MB. Das Beispiel mit den Kontaktelementen ist natürlich bewusst so gewählt, dass die Größe der Auslagerungsdatei möglichst gering ist und sogar die 400MB Standard genügen um noch 250MB SMEM zur Verfügung zu stellen. Wenn man größere Modelle hat muss man hier natürlich andere Werte eingeben. Da mein Nastran nicht mehr als 8GB Speicher verwenden kann sind meine Einstellungen meistens MEMORY=8000MB und SMEM=6500MB. Das müsst ihr vielleicht selber herausfinden was für Eure Berechung und für Eure Hardware das Beste ist. Den Befehl SMEM=6500MB gibt man einfach unter der Option Solver-Parameter  in der Zeile „zusätzliche Schlüsselwörter“ ein.

Ich habe auch mal zwei Bilder von der CPU-Auslastung gemacht. Hier kann man ganz deutlich den Unterschied erkennen: die CPU wartet durch das Auslagern auf die Festplatte seht oft, wenn man SMEM verwendet wartet die CPU nicht. Ein weiterer, sehr positiver Effekt: Dadurch, dass die ganze Berechnung nur noch im RAM stattfindet kann man mit dem Rechner weiterarbeiten als würde er noch sonst nix machen. Bisher habe ich das ständige Auslagern auf die Festplatte ganz deutlich gemerkt, indem das System sehr träge reagiert hat und ich selbst mit Word nicht mehr arbeiten konnte. Jetzt ist das ganz anders.

Ich hoffe ich konnte Euch damit helfen. Hardwarehändler werden diesen Beitrag wohl nicht so mögen, denn das Aufschwatzen von dicken, viel-kernigen und teuren XEONs wird nun erst mal ein Ende haben. Was nutzen einem 16GB RAM wenn unser geliebtes NX standardmäßig nur 3MB davon zur Auslagerung nutzt. 70€ für 16GB RAM und das Zauberwort SMEM bringen ganz viel mehr!

Ich würde Euch bitten, mal die Beispielrechungen durchlaufen zu lassen und hier die Zeiten mit und ohne SMEM zu Posten (im .log file ganz unten). Ich musste es erst mit rar und dann mit zip packen, sonst hätte ich es nicht hier hochladen können.

Core i5 2500
16GB RAM
NX7 64Bit
Ohne SMEM: 16:16min
Mit SMEM: 10:53min
Ersparnis: 33%

Core 2 Duo E6750
4GB RAM
NX7 32Bit
Ohne SMEM: 35:13min
Mit SMEM: 26:45min
Ersparnis: 24%

Grüße
JonkMcCool

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Kontaktbeispiel_NX_Forum.zip

Hallo,

hier noch mal der Versch, die zip-datei anzuhängen.

Gruß JonkMcCool

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Vorbildlich - hier wird echte Grundlagenforschung betrieben!

Ich melde mich, sobald ich die Zeit gefunden habe, das Beispiel zu rechnen...

Gruß
Ralf

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Da fällt mir gerade auf:

Zitat:

---

Original erstellt von JonkMcCool :
[...]
- man kann sehen, dass die eigentliche Arbeit von analysis.exe gemacht wird und dass die und die übergeordnete nastran.exe [b][i]in einem Ordner namens \NASTRAN\nx6p1 steckt [/b
[...][/i]

---

Wenn das so stimmt, wird als Solver NX Nastran 6.1 verwendet - das heißt, NX7 verwendet noch den Solver aus NX6...
In meiner (lange nicht aktualisierten) NX7-Installation (32Bit) ist das auch so.

Auszug aus den UG Solutions:

Zitat:

---

Currently there are three types of executables built for NX Nastran:

ILP-32 - 32 bit executables with 32 bit Integers, Longs and Pointers
LP-64  - 64 bit executables with 32 bit Integers and 64 bit Longs and Pointers
ILP-64 - 64 bit executables 64 bit Integers, Longs and Pointers

The two "flavors" with 32 bit integers both have 4 byte words. It is only the
ILP-64 executables that have 8 byte words and can address more than 8GB RAM for
a nastran job. The ILP-64 executables can address many terabytes of
memory.

---

Die ILP-64 ist wohl gleichbedeutend mit der nastran64L.exe, diese finde ich erstmalig in meiner NX7.5-Installation.

------------------
Hoffeeinehilfegewesenzusein 

Gruß
Ralf

Improvisieren ist nur dann eine Kunst, wenn man nicht unvorbereitet aussieht...

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

The ILP-64 executables can address many terabytes of memory.

---

Das ist ja prima. Da lohnt es sich dann auch mehr als 8GB RAM zu haben. Ich hoffe ich bekomme demnächst mein NX8.

In diesem Zusammenhang: Ich hatte beim Austesten der Speicherbefehle mit sehr großen Modellen zu tun. Nachdem meine ca.7GB SMEM voll waren gings auf der Festplatte weiter. Da allerdings nur bis 32GB. Als die Auslagerungsdatei die Größe von 32.000MB erreicht hatte, rechnete Nastran einfach nicht mehr weiter, gab aber auch keine Fehlermedung. Hat jemand schon mal diese Erfahrung gemacht und ev. ne Lösung dazu? Ist das vielleciht ne Windows-Barriere?

Gruß
JonkMcCool

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Hightower, und die anderen vielleicht auch!

Nur noch mal zu Erinnerung: Es würde mich schon interessieren mit welchen Rechenzeiten die Beispiele auf unterschiedlichen Systemen durchgerechnet werden. Würde mich freuen wenn Ihr das hier posten könntet.

Danke
JonkMcCool

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hi Jonk,

ich hab mich jetzt endlich mal hingesetzt und Dein Beispiel durchlaufen lassen:

Xeon E3-1270
16GB RAM
NX8 Win7, 64Bit (Nastran V6.1, ist mein "Produktivsolver")
Ohne SMEM: 14:42min
Mit SMEM: 10:53min
Ersparnis: 26% - ich habe eine SSD...

Etwas enttäuschend - die CPU dümpelt während der Kontaktanalyse-Konvergenz relativ viel auf 25% dahin - kann man irgendwo noch tunen?
parallel=4 und nproc=4 in der nast6.rcf bzw. nast8.rcf sind gesetzt.

Immerhin:
NX8 Win7, 64Bit (Nastran V8.1)
Ohne SMEM: 04:49min
Mit SMEM: 04:30min
Ersparnis: 7% - ich habe eine SSD...

Ein aktueller Solver bringt doch was...

Dennoch, wenn man der Disk die unnötigen I/OŽs ersparen will macht die Einstellung SMEM=... in jedem Fall Sinn.
Es ist ja auch nicht jedes Beispiel so einfach... 

------------------
Hoffeeinehilfegewesenzusein 

Gruß
Ralf

Improvisieren ist nur dann eine Kunst, wenn man nicht unvorbereitet aussieht...

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Hightower,

vielen Dank erst mal, dass Du das nun endlich mal geschafft hast!

Zur Vergleichbarkeit muss ich aber folgendes sagen:

1. Ja, ich habe auch festegestellt, dass der neue Solver etwas schneller rechnet. Also noch der ganz normale 64Bit-Solver und nicht der mit TB Speicherraum, den habe ich noch gar nicht probiert.

2. Das Beispiel was ich erstellt hatte, verwendet Kontaktelemente und hier rechnet der neue Solver nicht nur schneller sondern auch anders. Es kommen andere Verformungen raus und er ist mit weniger Iterationen fertig. Letzteres wäre ja nicht so schlimm, aber das jetzt komplett andere Ergebnisse herauskommen schon! Entweder war früher alles falsch oder eben jetzt. Ich bin noch nicht ganz sicher woran das liegt, kann an den Kontakelement-Einstellungen liegen. Das Beispiel hatte ich ursprünglich so gewählt, weil es mit wenig Arbeitsspeicher bzw. Festplattenspeicher auskommt und trotzdem lange dauert und dabei Unmengen auf die Festplatte schreibt, ließt und wieder überschreibt. Ich werde bei Gelegenheit mal was Neues erfinden.

Zu Deiner Frage:

Zitat:

---

Etwas enttäuschend - die CPU dümpelt während der Kontaktanalyse-Konvergenz relativ viel auf 25% dahin - kann man irgendwo noch tunen?
parallel=4 und nproc=4 in der nast6.rcf bzw. nast8.rcf sind gesetzt.

---

Ich glaube das liegt daran das der Kontaktalgorithmus eine wirklich iterative Sache ist die sich einfach nicht parallelisieren lässt. Zwischendurch beim Matrix solven gehts ja hoch auf 100% und das ist ja gut. In einem neuen BSP werde ich mal was machen was die CPUs ausnutzt.

Übrigens: Wenn man sich die Zeiten von deinem 6.1 Solver anschaut (Ich glaube das ist der von NX7) kann man sehen, das mit SMEM mein Core i5 und dein Xeon genau gleich schnell sind, ohne SMEM aber deine SSD bisschen was rausholt.

Gruß
JonkMcCool

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von JonkMcCool :
Übrigens: Wenn man sich die Zeiten von deinem 6.1 Solver anschaut (Ich glaube das ist der von NX7) kann man sehen, das mit SMEM mein Core i5 und dein Xeon genau gleich schnell sind, ohne SMEM aber deine SSD bisschen was rausholt.

---

Eben - enttäuschend... 

Na ja, ich habe weniger Kontaktprobleme als vielmehr viele Knoten am Haken - da ist mit Parallel schon mehr los...

Gruß
Ralf

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Was ist denn jetzt so enttäuschend, dass der teue Xeon nicht schneller ist als der Core i5, oder dass die SSD immer noch viel langsamer ist als der RAM?

Wer viele Knoten hat (und wer überhaupt sein NX pimpen will), dem würde ich nach allem was wir von einander in diesem Thread gelernt haben empfehlen:

1. parallel=4 und nproc=4 in die nast6.rcf bzw. nast8.rcf schreiben (bzw. eben die Anzahl der CPU-Kerne)
2. SMEM verwenden, so viel wie geht.
3. TEMP-Pfad auf eine aktuelle SSD legen (Achtung beim 6.1 Solver bei 32GB Auslagerung Schluss).
4. Noch mehr RAM kaufen und den neuen ILP-64 Solver, nastran64L.exe verwenden (muss ich noch ausprobieren).
5. Erst wenn das alles ausgereizt ist über neuen Rechner mit dickeren CPUs nachdenken. Den RAM und die SSD gibts ja im Vergleich dazu sehr günstig und die richtigen Einstellungen (bringen am meisten) sind sogar für Umme!

Gruß
JonkMcCool

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP