cancel
Showing results for 
Search instead for 
Did you mean: 

SOL111: crashes because of memory issue

Phenom
Phenom

To all,

 

I am doing some testing with SOL111 with a view to only get the rms stress using the option: NASTRAN FREQVM=1

 

The analysis crashed because it ran out of memory. Doing some tests, I noticed that Nastran appears to be using most of the ram available (~130Gb) !

 

I therefore did a test by only requested the accelerations of 3 nodes but still failed miserably.

I even tried on RESTART as I wasn’t sure if the issue was with the nmodes calculation/extraction but same issue.

 

Can anyone advice on what might be the problem? To be clear I only want to do a “1-off run” to get the rms stress in the entire model

 

Thanks

Regards

Production: NX9.0.3.4, NX10.0.2.6
Development: VB.NET (amateur level !)
27 REPLIES

Re: SOL111: crashes because of memory issue

Legend
Legend

I just launched one with NXN 11.01 for a semi-big model, which as you know is excruciating slow in SOL111 (takes ~5h to compute) to see when it'll fall flat on its face... I didn't even realize FREQVM=1 was there to disable VM calcs!  I gave it 64GB RAM to see...  Are you doing XYOUT or straight plot to op2?

Re: SOL111: crashes because of memory issue

Phenom
Phenom

Thanks TentechLLC for the reply. Suspected you would Smiley Happy

 

No XYOUT used, jsut a straight plot is all I am after. From the test I did ages ago one can get all the rms stress (at freq 0Hz) in the op2 file.

 

I don't know what is the slowest NX resp .sim or SOL111? I know that for the test I am trying to do Nx resp. sim will get nowehere even in N11 (fast rms solve). No sure about SOL111. If only I had thw maya tool....

 

Look like I need to dboule check the set up for FREQVM. I may have got it wrong

Production: NX9.0.3.4, NX10.0.2.6
Development: VB.NET (amateur level !)

Re: SOL111: crashes because of memory issue

Legend
Legend

OK, plot to op2 is just a typical STRESS(PLOT,RMS,VONMISES) entry...  From reading the QRG, FREQVM=1 turns it off (counter-intuitive a bit, but that's OK).

 

As far as SOL111 vs. Response Sim, I think SOL111 still wins.  Last time I tried was NX11 beta, fast RMS was crashing then, so I used the standard algorithm...  SOL111 is slow, but Response Sim is VERY slow.  Terrible for large models.  

 

MAYA SATK on the other hand was incredibly fast.  First time we tried it I thought it had crashed has it did 3 random vibe cases in 15 minutes, vs. 5-6h/axis in SOL111 (and 8-9h/axis with Response Sim)!

 

BTW, it's not a dig at NX Nastran, MSC Nastran is in the same boat...  MAYA SATK works well with MSC Nastran too :-)  And as far as Abaqus, it's even more laugheable: they don't store RMS VM, they recalculate "on the fly" (this could be a long flight!) every time the model is open in Abaqus/CAE!  You can imagine the numerous repercussions, including the inability to archive results for flight hardware for instance...

Re: SOL111: crashes because of memory issue

Phenom
Phenom

Ok. looks like I confused my self when copying-pasting nastran cards. Will check that

As I am only after the stress, that 's the card I used and referecing a set (rather than (=all) ).

I also need to check my old test as I may have run with 1 excitation point where I have 2 now

 

so what could cause sol111 to crash? I think sol111 crashed even when I did'st ask for stress output!

 

no tested personally N11 fast rms yet, but believe will see an time inprovment. Still a few hours for a large set of elements

 

MAYA SATK was simply astonishing when I tested it earlier this year. I do regonise the time quoted!

Production: NX9.0.3.4, NX10.0.2.6
Development: VB.NET (amateur level !)

Re: SOL111: crashes because of memory issue

Legend
Legend

MAYA SATK was simply astonishing when I tested it earlier this year. I do regonise the time quoted!


We even have a success story about it: MAYA SATK TEN TECH LLC Case Study

 

Re: SOL111: crashes because of memory issue

Legend
Legend

No particular differences in solution time (a miserable 4h to calculate RMS stresses on a 3M dof model with less than 50 modes), op2 is the same size, and results are still in the op2...  Didn't crash though :-)

Re: SOL111: crashes because of memory issue

Phenom
Phenom

Just lifted some of the key inputs (PSD, damping, etc) from my real analysis and plugged them in an old sol111 test I had – The test run is seconds, output all the stress just fine (~200elms) and the input appears to be correct.

 

It seems that there is something that nastran doesn’t like about calculating rms stress for a large set of elements (~200,000)

 

Furthermore re-reading the doc it seems that FREQVM does not process 2nd order solid CHEXA20 and TET10 !

 

Production: NX9.0.3.4, NX10.0.2.6
Development: VB.NET (amateur level !)

Re: SOL111: crashes because of memory issue

Pioneer
Pioneer

Hi

I have been folllowing your thread.

 

"Furthermore re-reading the doc it seems that FREQVM does not process 2nd order solid CHEXA20 and TET10 !"

 

Which document states this?

I too am battling with a random analysis of a large model, which has TET10s, but I have skinned it with CTRIA6 membrane elements and only asking output for these membrane elements. However, I haven't managed to get results yet . My model is 2.5M DoF with 551 modes, 2000 frequency recovery points.

 

Thanks

Re: SOL111: crashes because of memory issue

Phenom
Phenom

Welcome to the club

 

I found in on the on-line doc, search for FREQVM adn there is a table of elements being supported. It seems that my memory issue is realted to the calculation of the VM stress. The modes are calculated just fine

 

My model is of the same size but I only have 230modes

 

if you skin youe teta elemtwna what sort of thickness do you use then?

 

Thanks

Regards

Production: NX9.0.3.4, NX10.0.2.6
Development: VB.NET (amateur level !)