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
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:
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.
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 402653184 words, wat maakt: 402653184 words * 8 bytes/word = 3221225472 bytes 3221225472bytes / 1024 = 3145728 Kb 3145728 Kb / 1024 = 3072 Mb 3072 Mb / 1024 = 3Gb Wat ook teruggevonden wordt in de RCF file in mijn rechts) situatie (zie
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
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: 172 745 000 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. 178 091 683 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.
Buffsize heeft te maken met de grootte van blocks waarmee Nastran communiceert. Voor modellen van meer dan 400000 vrijheidsgraden, wat tegenwoordig bijna alle modellen hebben, stel je dit het beste in op 32769. 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).