Tips & Tricks: Tip van de maand december NX CAE NX Nastran: Memory optimalisatie buffsize f06 output

Maat: px

Weergave met pagina beginnen:

Download "Tips & Tricks: Tip van de maand december 2011. NX CAE NX Nastran: Memory optimalisatie buffsize f06 output"

Koenraad Janssens
8 jaren geleden
Aantal bezoeken:

Tips & Tricks: Tip van de maand december 2011 NX CAE NX Nastran: Memory optimalisatie buffsize f06 output Door: Christophe Vandevelde In de techtip van augustus hebben we het gehad over de hardware

1 Tips & Tricks: Tip van de maand december 2011 NX CAE NX Nastran: Memory optimalisatie buffsize f06 output Door: Christophe Vandevelde In de techtip van augustus hebben we het gehad over de hardware optimalisatie en als tweede aandachtspunt kwam de RAM naar voren. Gemakshalve gaven we aan dat hoe meer RAM je ter beschikking hebt hoe beter dit is. De vrije RAM op je systeem zal immers een positieve invloed hebben op de I/O performantie. Het is dus belangrijk om niet al je vrije RAM aan Nastran toe te kennen, zeker niet meer dan 75%. Het heeft echter sowieso geen zin om 75% aan Nastran toe te kennen. Laten we even het volgende voorbeeld beschouwen. Je hebt een Systeem waar 24GB RAM beschikbaar is. Daarvan blijkt 20Gb vrij te zijn, wat zou betekenen dat je 15Gb aan Nastran toe kunt kennen. Maar als Nastran bijvoorbeeld maar 500Mb nodig heeft om een solve te runnen, dan reserveer je 14.5Gb geheugen teveel voor Nastran. Geheugen dat niet vrij is voor je OS, waardoor je I/O minder performant zal zijn. Als je daarentegen maar 500Mb toekent aan Nastran, dan krijgt je systeem er onmiddellijk 14.5Gb bij. Het is belangrijk dat Nastran voldoende geheugen toegewezen krijgt om in core te solven, maar dat je ook niet teveel toekent waardoor je OS een mindere I/O performantie krijgt. Dat brengt ons op de volgende vragen: - Waar stel ik het geheugengebruik van Nastran in? - Hoeveel geheugen heeft Nastran nodig? Als je vanuit NX solved dan is de eerste plek waar gekeken wordt settings. Deze vind je terug onder iedere solution onder de parameters. de NX solver

De vrije RAM op je systeem zal immers een positieve invloed hebben op de I/O performantie. Het is dus belangrijk om niet al je vrije RAM aan Nastran toe te kennen, zeker niet meer dan 75%.

2 In de solver parameters memory, onder Nastran keywords, staat dit al dan niet ingevuld. Indien, zoals hier, niets ingevuld staat, zal Nastran vervolgens kijken in de RCF file. De waarde die hier default komt te staan kun je instellen in de customer defaults:

Indien, zoals hier, niets ingevuld staat, zal Nastran vervolgens

Zoals aangegeven kijkt Nastan in de RCF file als in NX niets is meegegeven (of als je buiten NX de solver opstart) en daar wordt de hoeveelheid geheugen bepaald door Memory= gevolgd door een waarde

3 Zoals aangegeven kijkt Nastan in de RCF file als in NX niets is meegegeven (of als je buiten NX de solver opstart) en daar wordt de hoeveelheid geheugen bepaald door Memory= gevolgd door een waarde of door estimate. Waardes kunnen bijvoorbeeld aangegeven worden door Mb en Gb. Bijvoorbeeld 1024Mb of 1Gb. Met de estimate setting zal Nastran zelf een inschatting maken van de hoeveelheid geheugen die nodig is. Ik heb zelf echter de gewoonte om een vaste waarde in te stellen. Ook omdat ik voldoende geheugen heb in mijn systeem. Dit brengt ons bij de vraag; hoeveel heeft een Nastran solve nodig om in core te solven? In onderstaande voorbeeld laten we sol601/701 even buitenbeschouwing. We gaan ervan uit dat de iteratieve solver niet gebruikt wordt. Bij de iteratieve solver kun je immers de hoeveelheid geheugen makkelijk terugvinden in de f06 file. Startpunt van elk onderzoek is het weten of je de 32bit solver gebruikt, of de 64bit IL-64 of 64 bit ILP64. Elk van die versies hebben echter een ander maximum aan hoeveelheid geheugen die je kunt toekennen en bij de laatste moeten we onze rekenwijze aanpassen naar het geheugen toe. - 32bit Nastran: max memory +/- 1200Mb (4bytes/word) - 64bit Nastran (IP64): max memory 8Gb (4bytes/word) - 64bit Nastran (ILP64): max memory onbeperkt (8bytes/word) Het aantal bytes per word is belangrijk omdat Nastran geheugengebruik in words aangeeft. Als je twijfelt welke Nastran versie je gebruikt en hoeveel bytes per word je hebt, is de log file van Nastran de plaats om dit na te gaan.

Met de estimate setting zal Nastran zelf een inschatting maken van de hoeveelheid geheugen die nodig is. Ik heb zelf echter de gewoonte om een vaste waarde in te stellen.

4 De log file van Nastran staat over het algemeen op dezelfde plek als van je Nastran input deck en ook waar je NX files staan. In NX8 kun je via de rechtermuisknop op je solution daar onmiddellijk naar toe browsen. Op de volgende pagina heb je een screendump van de log file met enkele interessante punten die we hier zullen bespreken. We zien dat we een 64bit versie gebruiken met 8bytes/word (dus ILP64) Verder herkennen we de hoeveelheid geheugen die wordt toegekend aan Nastran, in dit geval words, wat maakt: words * 8 bytes/word = bytes bytes / 1024 = Kb Kb / 1024 = 3072 Mb 3072 Mb / 1024 = 3Gb Wat ook teruggevonden wordt in de RCF file in mijn rechts) situatie (zie

Op de volgende pagina heb je een screendump van de log file met enkele interessante punten die we hier zullen bespreken.

5 Is dit nu voldoende geheugen voor de solve die je doet? Dit kun je terugvinden in je F04 file tijdens de solve. Zoek op MEMORY REQR'D TO AVOID SPILL

6 Zorg ervoor dat je ingestelde geheugen zeker wat hoger ligt dan dit. Zo niet, dan zal de solve een stuk trager zijn. In dit geval is de minimale vereiste om in core te solven: words *8bytes/word /1024/1024 = 1318Mb (8b/word voor ILP64 zoniet 4b/w) Indien je ingestelde geheugen lager is, kun je niet in core solven en zal de solve aanzienlijk langzamer lopen. In dit geval kun je de solve beter afbreken en je geheugen verhogen indien je nog geheugen beschikbaar hebt. Na het verlopen van een solve wordt, op het einde van je f06 file, het exacte geheugen dat gebruikt is getoond words *8bytes/word /1024/1024 = 1359Mb Als we een dergelijk model nog eens moeten solven weten we nu dat 3 GB toegekend aan Nastran te veel is en dat we eigenlijk aan 1.5Gb voldoende hebben. Op deze manier is er 1.5Gb extra geheugen vrij voor ons OS. Los van het geheugen geeft de f04 file ook nog interessante informatie over de hoeveelheid plaats op je disk die scratch files nodig hebben: In ons geval een 8Gb in totaal. Indien je voldoende RAM hebt, bijvoorbeeld 24 Gb RAM, dan kun je ervoor kiezen om SMEM in te stellen. Via het keyword SMEM (instellen in Mb) kun je de scratch files op je RAM terecht laten komen. Dit heeft echter uitsluitend zin indien je scratch files binnen je RAM passen. In dit geval stel je Memory=10Gb en SMEM=8500Mb. SMEM maakt immers deel uit van je ingesteld memory en in ons geval willen we 1.5Gb toekennen voor de solve zelf. Let wel dat je hier zal moeten solven met Nastran ILP64, tenzij je meer dan 8Gb toekent aan Nastran. Hierdoor zal de solve nog sneller lopen. Naast memory instellingen in de log file vind je ook nog een aanduiding i.v.m. buffsize (32769) en een parameter prgpst. Deze vind je ook terug in mijn rcf file.

core solven en zal de solve aanzienlijk langzamer lopen. In dit geval kun je de solve beter afbreken en je geheugen verhogen indien je nog geheugen beschikbaar hebt.

7 Buffsize heeft te maken met de grootte van blocks waarmee Nastran communiceert. Voor modellen van meer dan vrijheidsgraden, wat tegenwoordig bijna alle modellen hebben, stel je dit het beste in op Param,prgpst,no is een parameter setting die ervoor zorgt dat in de f06 file de onderdrukte singulariteiten niet gerapporteerd worden. Hierdoor zal de f06 een stuk kleiner zijn, zeker bij modellen met veel 3D elementen waar al de rotaties onderdrukt zijn. Tenslotte zie je in mijn RCF file ook een parallel=4. Dit geeft aan dat ik de 4 cores van mijn CPU wens te gebruiken (zoals besproken in de techtip van augustus en september) Indien je vragen hebt over dit onderwerp, aarzel dan niet om contact op te nemen met onze helpdesk of mij (christophe.vandevelde@siemens.com).

Param,prgpst,no is een parameter setting die ervoor zorgt dat in de f06 file de onderdrukte singulariteiten niet gerapporteerd worden.

Vergelijkbare documenten

Tips & Tricks: Tip van de maand juni 2009. NX CAE: Aanmaken surface contact - vervolg

Tips & Tricks: Tip van de maand juni 2009 NX CAE: Aanmaken surface contact - vervolg Door: Christophe Vandevelde In de tip van de maand januari 2009 (zie website www.siemens.nl/plm) zijn we dieper ingegaan