| | | SPS |
Autor
|
Thema: Performance verbessern/ausnutzen ... (7913 mal gelesen)
|
R. Frank Moderator Dipl-Ing. (BA) Masch.-Bau
Beiträge: 1287 Registriert: 11.10.2004 Windows 7 Professional - 8 GB RAM SWX 2012 SP 4.0 64 bit PDMWorks 2012 FlowSimulation 2012 SP 4.0 - 64 bit Simulation 2012 - 64 bit
|
erstellt am: 17. Sep. 2007 19:50 <-- editieren / zitieren --> Unities abgeben:
Hallo Forumsmitglieder. Hallo Mitleser. Hallo Simulanten. Inspiriert durch mehrere Beiträge möchte ich in diesem Thread mal mein Wissen über die Systemperformance und mögliche Verbesserungen bzw. Optimierungen für Simulationen zur Verfügung stellen. Dieser Beitrag erhebt weder Anspruch auf Richtigkeit oder Vollständigkeit. Er spiegelt lediglich meinen momentanen Wissensstand wieder. Es würde mich freuen, wenn es Rückmeldungen/Ergänzungen und evtl. Erfahrungsberichte von anderen Usern gäbe. Ich gehe bei meinen Empfehlungen von einem System aus, das momentan Standard zu sein scheint. Als Betriebssystem wird Windows XP Professional in der 32-bit-Variante verwendet. Meine Erfahrungen entstanden auf einem System mit Single-CPU (2,0 GHz). Generell ist zu sagen, daß mit den "Standardeinstellungen" Windows XP einen Task (zu ersehen im Taskmanager) mit maximal 1,6 GB RAM verwalten kann. Sobald der Task mehr als diesen Speicherbedarf dynamisch anspricht, stürzt Windows ab. Windows XP kann nicht mehr als 2 GB RAM verwalten, deshalb macht es keinen Sinn, mehr als dies einzubauen (meine persönliche Meinung). Viele User berichten, daß durch den Einsatz des 3GB-Switches eine Verbesserung erzielt werden kann (unabhängig davon, wieviel GB RAM tatsächlich verbaut sind), da dadurch dem Task mehr Adressraum (Speicher) zugewiesen wird. Mehr Informationen gibt es hier: http://ww3.cad.de/foren/ubb/Forum2/HTML/009899.shtml#00001 Möglicherweise kann auch ein 64-bit-System die Situation verbessern. Ein Speichedefragmentierer (siehe Punkt 5.) bringt KEINE Verbesserung. 1.) Systemeinstellungen - Generell Windows kann maximal ein Swapfile von 4 GB verwalten. Es sollte darauf geachtet werden, daß das Swapfile auf einer ausreichend großen Partition liegt und nicht fragmentiert ist, sonst kann dies zu Performance-Einbußen und schlimmstenfalls zu Abstürzen führen. Die besten Erfahrungen habe ich bisher mit einem statischen Swapfile von 4GB gemacht (also Anfangs- und Endwert auf 4096 gestellt). Möglicherweise ist dieser Faktor auf einem schnelleren System mit DualCore-Prozessor und/oder einer schnellen Festplatte nur noch von geringem Gewicht. 2.) Systemeinstellungen - Performance generell Windows XP wird generell mit vielen bunten Gimmicks ausgeliefert (Windows Vista noch viel mehr). Diese schlucken Leistung und sollten abgestellt werden. So ist zu empfehlen, über die Systemsteuerung den "Active Desktop" abzuschalten (System für "optimale Leistung anpassen"). Ebenso sollten die Prozessorzeitplanung und die Speichernutzung "für Programme" aktiviert sein. 3.) Dienste abschalten (generell) Nicht alle Dienste unter Windows XP sind lebenswichtig. Abhängig davon, ob ein Netzwerk vorhanden ist oder nicht und welcher Virenscanner oder welche Firewall verwendet wird, kann man durch entsprechende Konfiguraton durchaus auf einen Speicherverbrauch von ca. 300 -340 MB kommen (einsehbar im Taskmanager). Mehr Informationen gibt es z.B. hier: http://www.windows-tweaks.info/html/dienste.html Aber IMMER große Vorsicht walten lassen. Im Zweifelsfall Finger weg! 4.) Dienste abschalten speziell (speicherresidente Programme) Auch hier gilt, daß z.B. meine stets im Hintergrund geladene "Enzyklopedia Britannica" zwar recht nett und hilfreich ist, aber wohl sehr wahrscheinlich nicht gerade unwesentlich Speicher schluckt. Ich persönlich kicke gerne vor der Simulation über den Taskmanager einige Prozesse (alle diejenigen, bei denen unter "Benutzername" der aktuelle User steht, kommen dafür prinzipiell in Frage). Meine perönlichen "Favoriten" sind so Prozesse wie z.B.: - Outlook (ca. 135 MB Speicher) - Acrobat Reader - InCD - XPhone (Telefonnummernverwaltung und interaktives Wählssystem für die Telefonanalage) Wer will, kann auch das Wallpaper rausschmeißen, das bringt ca. 2 MB mehr freien Speicher. Ich rate davon ab, an Virenscanner und Firewall Hand anzulegen. Die Gründe liegen wohl hoffentlich auf der Hand. 5.) Speicher defragmentieren (Zusatztools) Hewlett Packard liefert z.B. mit seinen fertig vorkonfigurierten Workstations für den Buissinessbereich unter anderem mit einer Software für Verwaltung/Tuning aus. Dort gibt es die Möglichkeit, ein kleines Tool ständig im Hintergrund zu halten, das den Speicher wohl laufend defragmentiert und optimiert. Ich habe den Haken gesetzt und kann bisher zumindest nichts Nachteiliges darüber berichten. Die TuneUp-Utilities (www.tuneup.de) bieten, soweit ich weiß, z.B. einen Mem-Optimizer an. Diese Programme bieten keine MESSBAREN Vorteile. Sie schlucken Performance und Speicher. Wenn es ungünstig läuft kollidieren Sie sogar mit dem Simulations-Task. Es ist vom Einsatz eher abzuraten.
6.) Pflege/Wartung Es versteht sich wohl von selbst, daß das System von Zeit zu Zeit (vielleicht Task-gesteuert z.B. ein Mal im Monat ?) die Festplatte überprüft und defragmentiert. 7.) Backup/Datensicherung Gehört hier zwar nur sehr am Rande dazu, aber man sollte sich Gedanken machen, ob man nicht mindestens einen DVD-Brenner installiert und in angemessenen Zeitabständen ein Backup durchführt. Z.B. CosmosFloWorks erzeugt pro Studie bis zu 500 MB an Daten (die Dateien "r_000000.fld" in den Verzeichnissen sind allerdings überflüssig und können manuell über den Explorer wieder gelöscht werden). Bei Cosmosexpress sind es je nach Vernetzungsgrad pro Studie bis zu 100 MB. Über CosmosWorks selber kann ich leider nichts sagen, da ich es nicht im Einsatz habe. Jedoch könnte ich mir vorstellen, daß es in einem ähnlichen Bereich liegt wie CosmosFloWorks. Gerne darf ich zum Thema Backup eines meiner Lieblingszitate anführen. Es stammt aus der "readme.txt" zum Computerspiel "Kommander Keen 5 - Goodbye Galaxy" und lautet: Save your game. Often. You'll be glad you did. (Speichere Dein Spiel - Oft - Du wirst froh sein, es getan zu haben ...) In Sachen Optimierung sei hier auch noch dieser Artikel gerne genannt: http://www.chip.de/artikel/c1_artikel_22057974.html?tid1=&tid2= Wenn man die Erkenntnisse kurz zusammen fassen will: - "Active Desktop" deaktivieren - in Abständen defragmentieren - unnötige speicherresidente Programme (Add-In's) deaktivieren bringt am Meisten. Die anderen Punkte sind untergeordnet bzw. teilweise unnötig. Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
R. Frank Moderator Dipl-Ing. (BA) Masch.-Bau
Beiträge: 1287 Registriert: 11.10.2004 Windows 7 Professional - 8 GB RAM SWX 2012 SP 4.0 64 bit PDMWorks 2012 FlowSimulation 2012 SP 4.0 - 64 bit Simulation 2012 - 64 bit
|
erstellt am: 17. Sep. 2007 19:54 <-- editieren / zitieren --> Unities abgeben:
Hier nun der 2. Teil meiner "Trickkiste".Die Tipps sind teilweise offensichtlich und stehen großteils auch in den entsprechenden Handbüchern. Trotzdem kann es nicht schaden, diese Punkte hier noch einmal geordnet anzusprechen. 1.) Solidworks/Cosmos-Performance (bzw. Speicherbedarf) Es empfiehlt sich, unter den Zusatzanwendungen in SolidWorks alles abzuhaken bis auf CosmosWorks bzw. CosmosFloWorks. Eventuell hilft auch ein Reboot, bevor man dann die Simulation startet. Wer weiß, ob nicht noch irgendwelche "halblebendige" Tasks im Speicher rumhängen und Speicherbereich belegen/blockieren. Obwohl SolidWorks nur im Hintergrund mitläuft, um quasi die CAD-Geometrie bereitzustellen, hat auch SolidWorks einige Punkte/Optionen, die zum Teil erheblichen Einfluss auf die Performance haben. An dieser Stelle sei auf den Vortrag "Performance, woher nehmen" von Stefan Berlitz hingewiesen, den man unter dieser Adresse als PDF herunterladen kann: http://solidworks.cad.de/knowhow.htm Abteilung Allgemeine Artikel, 9. Punkt (Performance, Performance, Performance ... nur woher nehmen?) CosmosFloWorks Es gehört noch erwähnt, daß Solidworks dazu verwendet wird, die Geometrie bereitzustellen, und mithilfe des meshers ein Netz reingelegt wird. Dann wird an den FloWorks-Solver übergeben. Da während der Simulation im Taskmanager bei dem Solidworks-Prozess 0% CPU-Auslastung angezeigt wird, hätte ich vermutet, daß sich die in Solidworks eingestellten Optionen wohl kaum auf die Performance auswirken. Ausschlaggebend scheint hier der Solver zu sein und wie er den Speicher anspricht/verwaltet. Cosmosexpress/Cosmos Auch hier wird unter Solidworks die Geometrie bereitgestellt und vernetzt. Anschließend wird an den FFEStar-Solver übergeben, der dann die Berechnung durchführt. Beim Beobachten des Task-Managers unter Cosmosexpress habe ich allerdings bisher zumindest den Eindruck gewonnen, daß die Verzahnung zwischen Solidworks und FFEStar-Solver etwas stärker ausgeprägt zu sein sein. Es kann auf jeden Fall nicht schaden, sich mal mit den "Performance-Optionen" von Solidworks auseinander zu setzen. 2.) Modellaufbau für die Simulationen Es ist natürlich wichtig, die Modelle, wo es möglich ist, zu vereinfachen. Dazu gehören Unterdrückung/Weglassen von Fasen, Radien. Auch kann man sowohl bei Cosmos als auch bei CosmosFloWorks Symmetrien ausnutzen. Bei CosmosFloWorks nicht vergessen, die boundary condition "ideal wall" auf die entstandenen Begrenzungsflächen zu legen ... Neben der Überlegung, ein Ersatzmodell zu verwenden, kann man natürlich auch darüber nachdenken, evtl. Teile miteinander zu verschmelzen. CosmosFloWorks-Special - Ich speichere gerne die Baugruppe als Teil ab, kombiniere dann im Einzelteil die Volumenkörper, exportiere als Parasolid V12 und re-importiere das Ganze. Dadurch erhalte ich ein einziges "dummes" Einzelteil (also ohne editierbare Features). Ich sehe auch dadurch, ob alle Flächen sich berühren, ob das Modell an sich ok ist. Ich büsse allerdings in der "Oberflächengenauigkeit" ein, sprich ich erhalte also etwas weniger partial cells beim Vernetzen als wenn ich die Original-SolidWorks-Baugruppe vernetzen würde. Bei Luftströmungen und aufwändigen Blechteilen würde ich daher eher von solchen Operationen abraten, in meinen Simulationen sind es oft recht einfache Drehteile von Wasser durch- strömt, daher macht das bei meinen Simulationen nicht sehr viel an Genauigkeit aus ... Außerdem passiert es häufig, daß ich bei umflossenen inneren Teilen Taschen habe, die z.B. bei Gewindesacklöchern oder Freistichen entstehen. Diese Taschen liegen zwar innerhalb der computional domain, es findet jedoch kein flow in Ihnen statt. CosmosFloWorks hat zwar eine standardmäßig aktivierte (angehakte) Option "exclude cavities without flow conditions" aber das hat schon mit Floworks 2001 nie so recht hingehauen, und ich bin auf jeden Fall auf der sicheren Seite damit. Ich bekomme häufig den Eindruck, daß trotz allem diese Taschen ja bei der Berechnung "mitgeschleppt" werden müssen, also Performance schlucken, und wenn so eine Vereinfachung als zulässig angesehen werden kann, warum nicht ... Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
R. Frank Moderator Dipl-Ing. (BA) Masch.-Bau
Beiträge: 1287 Registriert: 11.10.2004 Windows 7 Professional - 8 GB RAM SWX 2012 SP 4.0 64 bit PDMWorks 2012 FlowSimulation 2012 SP 4.0 - 64 bit Simulation 2012 - 64 bit
|
erstellt am: 17. Sep. 2007 19:58 <-- editieren / zitieren --> Unities abgeben:
Jetzt kommen wir zum 3. und schwierigsten Teil der "Trickkiste".Wir beschäftigen uns sinngemäß mit der Frage "Ich habe ähnliche Simulationen, jedoch brauchen die Simulationen teilweise extrem unterschiedlich viel Zeit, woran liegt das ?" Wenn ich davon ausgehe, daß kein Hintergrunddienst (Aktualisierung von Windows, Virenscanner, Indexierung der Festplatte o.Ä.) die Simulation stört, kann man Folgendes sagen: Bei einer Simulation gibt es im Prinzip stets folgende Schritte: 1.) ich stelle die (CAD-)Geometrie zur Verfügung (SolidWorks) 2.) ich sage dem System, welche Netzgenauigkeit ich haben möchte (das übernimmt dann der sogenannte "mesher"). 3.) ich sage dem System, welche Eingangsgrößen ich kennne, und welche Ausgangsgrößen mich interessieren. In FloWorks kann man dann noch unterscheiden, ob diese Ausgangsgrößen auch noch konvergiert sein müssen oder "nur protokolliert" werden. 4.) nun rechnet der Solver mathematisch alles aus Ich habe also zwei Größen, die sich teilweise widersprechen. Zum Einen die Netzgenauigkeit und zum Anderen die Konvergenz, also wie (mathematisch) "genau" die Vorhersage sein soll. Ein Beispiel aus der Praxis (STARK übertieben). - Uns interessiert der Volumenstrom durch eine Art Rohr - vorsichtig geschätzt, liegt dieser wohl im Bereich von, sagen wir mal, ca. 20 m3/h Es hat nun wenig Sinn, zu sagen, mit einem Netz von fünf Zellen will ich auf 0,001 m3/h genau den Volumenstrom ausgerechnet haben. Es hat ebenso wenig Sinn, ein Netz von 500.000 Zellen reinzulegen und zu sagen, daß eine Genauigkeit von 5,0 m3/h ausreicht (ca. 20% vom zu erwartenden Wert !). CosmosFloWorks bietet z.B. mit Hilfe der Option "Local initial mesh" die Möglichkeit, daß Netz nur an ganz bestimmten (interessanten) Stellen zu verfeinern. Auch die Option "advanced narrow channel refinement" spielt da mit hinein. Das Refinement lässt sich auch noch an anderen Stellen wesentlich verfeinern/verändern. Hauptsächlich über die "calculation control options" lassen sich die Konvergenzkriterien beeinflussen. Der gewählte Level beinflusst, wie das Delta gebildet wird. Das criterion lässt sich auch manuell festlegen. Sobald das Delta kleiner ist wie das criterion wird die Simulation beendet. Über den goal Plot im Solver kann man diesen Vorgang verfolgen. Cosmos bietet auch genügend Möglichkeiten (z.B mit Schalenelementen), Einfluß auf die Netzgenauigkeit zu nehmen. Man kann auch sein Modell mit Trennlinien in einzelne Bereiche unterteilen und diese dann jeweils entsprechend vernetzen (sollte funktionieren). Einfluß auf die Konvergenz kann man z.B. durch Veränderung des treshold-Wertes nehmen. Fazit: Um die Simulationszeiten zu optimieren bzw. um beurteilen zu können, wie gut bzw. realistisch die Simulation ist, muss man mehrere Parameter betrachten und gegeneinander abwägen. Ich hoffe, man verzeiht mir, wenn ich etwas salopp formuliere: Ich kann jemandem innerhalb kürzester Zeit das Radfahren beibringen, aber um ein guter Radfahrer zu werden muss man sich mit der Technik des Rades und den Verkehrsregeln auseinander setzen und viele Testkilometer fahren. Ich hoffe, ich habe die Leser des Beitrages nicht gerade mit all zu viel Text erschlagen. Über jede Art von Rückmeldung würde ich mich freuen. Roland Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Jörg H. Mitglied Ingenieur Sondermaschinenbau
Beiträge: 376 Registriert: 11.03.2005 Core2Duo@3.2GHz 3,93 GB RAM Quadro FX1500 XP x64 SWX 2007 x64 Ansys 11
|
erstellt am: 26. Okt. 2007 15:57 <-- editieren / zitieren --> Unities abgeben: Nur für R. Frank
Hallo, sehr schöner Beitrag, der auch weniger versierten PC-Usern garantiert zu mehr Performance verhilft. Gruß Jörg ------------------ Gruß Jörg PS: Ich freu mich immer über Gästebucheinträge [Diese Nachricht wurde von Jörg H. am 26. Okt. 2007 editiert.] [Diese Nachricht wurde von Jörg H. am 26. Okt. 2007 editiert.] [Diese Nachricht wurde von Jörg H. am 26. Okt. 2007 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Piet Mitglied Konstruktionsleiter & Konstrukteur
Beiträge: 661 Registriert: 20.11.2001
|
erstellt am: 13. Dez. 2007 11:52 <-- editieren / zitieren --> Unities abgeben: Nur für R. Frank
|
reflow Mitglied Dipl. Ing. Maschinenbau
Beiträge: 443 Registriert: 27.10.2005 SWX 2013 SP 3.0 mit SolidWorks Flow Simulation, TopsWorks, SPI SheetmetalWorks, Vista 64 Bit Intel Q9400, 8GB RAM
|
erstellt am: 26. Dez. 2007 18:40 <-- editieren / zitieren --> Unities abgeben: Nur für R. Frank
So zu Weihnachten hab' ich auch noch einen ganz kleinen Trick beizusteuern: FWX PE setzte ich voraus sonst bringt (und funktioniert) die Kiste nix. Wenn ich größere lokale Bereiche verfeinern muß, entsteht oft das Problem, daß z.B. Refinement "3" noch immer zu grob ist, Refinement "4" aber viel zu fein, um in endlicher Zeit zu einem Ergebnis zu kommen. Mit der Anzahl der Zellen steigt ja nicht zur Speicherbedarf und Zeit pro Iteration, sondern auch die erforderliche Anzahl der Iterationen bis zur Konvergenz. Da ich mit automatischen adaptiven Refinements eigentlich noch nie so richtig Glück hatte, habe ich davon weitgehend Abstand genommen. Ich mach aber zwei andere Dinge: 1. Ich verfeinere erst eine Stufe zu grob. Wenn lt. visueller Vorschau eine hinreichende Konvergenz erreicht ist, verfeinere ich eine Stufe mehr und rechne über die alten Ergebnisse nochmal drüber. Im Prinzip mach' ich das adaptive mesh refinement damit von Hand. 2. Wichtiger is eine andere Eigenschaft des meshers: Die Stufung des "basic mesh" ist erheblich feiner als die des "local mesh", das ja nur vorhandene Stufen halbieren kann (macht aus einer "alten" Zelle immerhin acht neue). Auch wenn mein Modell fast ausschließlich aus lokal vernetzten Bereichen besteht, vernetze ich das Grundmodell eins gröber und setze das local entsprechend eins feiner (geht auch umgekehrt). Damit läßt sich die Netzauflösung insgesamt recht gut und schnell anpassen. Vom Ergebnis profitiert nicht nur der Solver, sondern auch alle nachfolgenden Schritte. Gruß Ron
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
| Anzeige.:
Anzeige: (Infos zum Werbeplatz >>)
|