limiting number of elements

[kris222]

Hi,
I have been using Nastran to analyse plates.
It seems to work below 11000 elements,
When I use mesh sizes where I reach 11000 elements and I have single subcase, Nastran does not show in output file all supports results, and internal forces seem also to be wrong.
If I have two subcases, then Nastran does not show any results.
I am assuming this is related to number of elements or size for output file.
Is there any flag or way I can change max elements number limit ?
The same plate with eg. 10000 elements works fine (the same size, loads, supports)
Regards,
Kris

[JuanP74]

Hi, maybe a bit late...I do not know if you found a solution but I think I got a workaround. If you send all output requests to the punch file (DISP (PUNCH) = ALL in case control deck for example) then it works. I attach an example for 14800 QUAD4 shells and 2 static subcases (not yet checked modes or buckling solutions). Output can as well be requested using alter and sent to .op2 file which is very convenient if you use pyNASTRAN or other software. Please, try to further test it with more elements and element types and more subcases.
I believe the issue is with the OFP (Output File Processor, in file .../mis/ofp.f

pp01.bdf.txt

BR,
JP.

PS: How do you deal with drilling degrees of freedom in flat plates modeled with QUAD4 shells in COSMIC/NASTRAN?

[JuanP74]

I checked that the output produced, even if it does not lead to error messages it is wrong. This does not happen for small problems like the following.

pp01_medium.bdf.txt

[ghost]

pp01.bdf.txt

It reads another file which is missing.

READFILE COSOUT2

[JuanP74]

Hi, the file is available in op2 file thread, issue #6 here: #6 (comment)

[ghost]

Hi, the file is available in op2 file thread, issue #6 here: #6 (comment)

So, it only useful if you want to output OP2 file. Which one is it? The F12?

[JuanP74]

yes, in fact COSOUT2 is only useful to output op2 for SOL 1. For other SOLs I have created similar alters also in that thread (alters are incomplete, they only request the outputs I was most interested when created them).
I used Fortran unit 12 since it's the usual in MSC Nastran but I think COSMIC user's considered FTN11. It does not matter at all. If you have the wrong assingment in nastran script op2 file will be created with the name "none" in Ubuntu installations.
I attach my modified script (remove .txt extension).

nastran.txt

[ghost]

I used Fortran unit 12 since it's the usual in MSC Nastran

I am under Windows. I got a F12 file. It is binary, but I tried to load it with pyNASTRAN, the program crashed.

[ghost]

I changed to ECHO = SORT, the program stopped very quickly after printing out the GRID info.
If ECHO = NONE, the program will do the solving process for a while and has the result.
Strange.

[JuanP74]

add MAXLINES = 999999 in case control deck, by default printed output is limited to 20000 lines.

[JuanP74]

I used Fortran unit 12 since it's the usual in MSC Nastran

I am under Windows. I got a F12 file. It is binary, but I tried to load it with pyNASTRAN, the program crashed.

check here and if not found report a new issue https://github.com/SteveDoyle2/pynastran/issues

otherwise you can try http://www.m3dfea.com/nastran-support.html, however I think m3d has some issues with QUAD4 elements even if cosmic nastran op2 was written with MSC format

[ghost]

That line 'MAXLINES = 999999' was comment out before.
After remove $, I got GRID & Result. Why you think the result is wrong?

[JuanP74]

check the pp01 example, pp01.bdf is a flat panel (very fine mesh) with a reinforced hole and compression along the 2 vertical edges. It is in equilibrium and SPCFORCES should be zero (almost, in real world) but they are not. Look at results: grids 478 and 576; however if you look at pp01_medium.bdf (exactly same problem with a coarser mesh) the results are as expected (grids 193 and 231).
for the 1/8 hollow sphere just look at the deformation, it does not have physical sense. Also you can check the results with mystran: https://www.mystran.com/

[ghost]

Here is my result. Looks all right.
`pp01_medium
193 G 4.545096E-13 -6.405712E-09 1.346937E-19 0.0 0.0 0.0
231 G 0.0 6.405960E-09 -2.271464E-17 0.0 0.0 0.0

pp01
478 G 0.0 0.0 1.180063E-15 0.0 0.0 0.0
576 G 0.0 0.0 2.409683E-15 0.0 0.0 0.0 `

[JuanP74]

well, this is what I got. I am using the nastran version in ubuntu, which one are you using?

pp01.f06.txt

[ghost]

I am using one I compiled by myself on windows.

[JuanP74]

That's very interesting. However I am surprised about your results for pp01. At node 576 there are 2 SPCs, for dof 2 and 3 however you get exactly zero (0.0) at SPCFORCE for dof 2 which I think is almost impossible, since this is the result of solving K*u=P and due to numerical accuracy at least a small non-zero number (like the one you get for pp01_medium) should result. Have you check the epsilon messages like the following?

0*** USER INFORMATION MESSAGE 3035
     FOR SUBCASE NUMBER     1, EPSILON SUB E =  -4.7602169E-02
0*** USER WARNING  MESSAGE  3058
0EPSILON IS LARGER THAN  1.0000000E-03 FOR SUBCASE    1

the large values of epsilon are also a hint of wrong reults (at least in my case), compare to the message in pp01_medium (only information message is present):

0*** USER INFORMATION MESSAGE 3035
     FOR SUBCASE NUMBER     1, EPSILON SUB E =  -2.6615990E-15

Also , please, check the deformed shape to see if it is the same as for pp01_medium

If finally we can confirm your results are OK would be nice to know what is different in your build.

[ghost]

`0*** USER INFORMATION MESSAGE 3035
FOR SUBCASE NUMBER 1, EPSILON SUB E = -1.3568911E-13

0*** USER INFORMATION MESSAGE 3035
FOR SUBCASE NUMBER 2, EPSILON SUB E = -1.3568911E-13`

[JuanP74]

well, cleary your version works, and the one in ubuntu doesn't. In your case the SPC's for pp01 file are in nodes 1 and 3, not 576 and 478, this is the reason for the 0.0; hence your results for nodes 1 and 3 are correct.
Have you tried to solve the pp01 for buckling (SOL 5)? Does it work?

[ghost]

Yes. nodes 1 and 3.
`30012- SPC 1 1 23 0.

30013- SPC 1 2 3 0.

30014- SPC 1 3 123 0.

30015- SPC 1 4 3 0. `

Uploaded sol5 result.

`0*** USER INFORMATION MESSAGE 3035
FOR SUBCASE NUMBER 1, EPSILON SUB E = -1.9316044E-02
0*** USER WARNING MESSAGE 3058
0EPSILON IS LARGER THAN 1.0000000E-03 FOR SUBCASE 1

0*** USER INFORMATION MESSAGE 3035
FOR SUBCASE NUMBER 2, EPSILON SUB E = -1.9316044E-02
0*** USER WARNING MESSAGE 3058
0EPSILON IS LARGER THAN 1.0000000E-03 FOR SUBCASE 2`

and this:

0*** USER FATAL MESSAGE 3032 0UNABLE TO FIND SELECTED SET ( 0) IN TABLE (EED ) IN SUBROUTINE (REIG). ERRTRC CALLED

What this mean? Need anything more in inp file?

Is there any difference between SOL 5 and SOL 5,0 and SOL 5,1?

[JuanP74]

Not sure. How did you change the inp file to run the buckling solution? May you post the executive and case control decks?

[JuanP74]

Is there any difference between SOL 5 and SOL 5,0 and SOL 5,1?

Check /um/EXEC.TXT it is explained there. ,1 removes loops in rigid format Sol 5. Not sure what the consequences are...

[ghost]

I only changed SOL 1 to SOL 5. You can see it in the D E C K E C H O.

If you check D05 test cases, seems enough cards.

DOL k1,k2
k2 default=0
so SOL 5 = SOL 5,0

[ghost]

Table (EED)

Enter DICTIONARY word or STOP, or terminate current text file(^):
eed
EED DBT Eigenvalue Extraction Data table (D-3, D-5, D-7, D-10, D-
11, D-12, D-13, D-15, A-10, A-11).

[JuanP74]

you have to change the case control deck to run sol 5:
now you have:

SUBCASE 2                                                                       
LOAD = 2                                                                      
$SUBCASE 2                                                                      
$  LABEL = BUCKLING CASE                                                   
$  METHOD = 1 

you need to have:

$SUBCASE 2                                                                       
$LOAD = 2                                                                      
SUBCASE 2                                                                      
  LABEL = BUCKLING CASE                                                   
  METHOD = 1 

subcase 1 loads are used for buckling, method=1 is the eigenvalue extraction method.

[JuanP74]

if you want to get the op2 results use the following alter (attached file, remove.txt extension)

cosmic_nastran_sol5_op2.alter.txt

[ghost]

Uploaded.

0*** USER FATAL MESSAGE 3181, ATTEMPT TO PERFORM CHOLESKY DECOMPOSITION ON A NEGATIVE DEFINITE MATRIX IN SUBROUTINE SMCOMP. NEGATIVE DIAGONAL TERM FOUND ON COLUMN 4733 ERRTRC CALLED

Maybe need to change a Method.

[ghost]

` INV Inverse power method, symmetric matrix operations

        DET   Determinant method, symmetric matrix operations

        FEER  Tridiagonal reduction method, symmetric matrix operations

        UINV  Inverse power method, unsymmetric matrix operations

        UDET  Determinant method, unsymmetric matrix operations`

Now is FEER

[JuanP74]

Uploaded.

0*** USER FATAL MESSAGE 3181, ATTEMPT TO PERFORM CHOLESKY DECOMPOSITION ON A NEGATIVE DEFINITE MATRIX IN SUBROUTINE SMCOMP. NEGATIVE DIAGONAL TERM FOUND ON COLUMN 4733 ERRTRC CALLED

Maybe need to change a Method.

Check param, autospc,1 is present, not commented.

Feer method is best in general for eigenvalue extraction. Sometimes not so good for eigenvectors

[ghost]

30008- PARAM AUTOSPC 1 30009- PARAM GRDPNT 0

not commented.

[JuanP74]

the static solution is wrong:

0*** USER INFORMATION MESSAGE 3035
     FOR SUBCASE NUMBER     1, EPSILON SUB E =  -1.9316044E-02
0*** USER WARNING  MESSAGE  3058

you may check the deformed shape for static subcase 1.
There still something wrong in the software. You may compare with same analysis for pp01_medium, for the small problem it works. The issue is not in the model.
You may try removing the printed output changing all case control deck request to DISPLACEMENT (NOPRINT) = ALL, STRESS (NOPRINT) = ALL , except for the SPCFORCES, also ECHO = NONE to check if still the issue is related with the OFP.
Have a look at the .log file, maybe there is some clue there, I have no more ideas, my opinion is that the issue is in the software.

[ghost]

Updated. You have to unzip the F06 result. There is a limit of 25M for upload.

[JuanP74]

Yes. This one looks OK. What did you do? Input deck is the same...

[JuanP74]

I think I found out.

The issues with big analysis are related to available memory.

If the run has enough open core to run completely in the open core there is no issue. If it exceedes the open core capacity it is suposed to spill and start writing in the scratch files but for some reason it doesn't work properly or sometimes fail. I do not know why and how yet.
Ubuntu version is compiled to a maximum allocatable open core of 400 Mw (=1.6GB) through variable LENOPC (hard coded) to be shared between open core and in-memory database using env vars OCMEM and DBMEM in /usr/bin/nastran launch script.
For the time being I would recommend recompiling to 2000 or 4000 Mw (LENOPC) for top applications and a typical script in /usr/bin/nastran with OCMEM=50000000 (200MB) and DBMEM=100000000 (400MB) for typical applications (better explain requirements in README file).

More things need to be checked. It's surprising no error message is reported when there is such an error in the run...

In particular for buckling and mode analysis FEER method requires a lot more open core than INV method for example, this is the reason why above examples failed.

[JuanP74]

I've finally found out. In file unpack.f following line has to be modified to increase the problem size:

DATA LARGE / 65536 /

I have tested this: DATA LARGE / 1048576 / and seems to work well. Sometimes OCMEM environment variable needs to be increased to at least 300 Mw (LENOPC is set to 480Mw in my compilation) otherwise the problem will run without errors but solution isn't good. NOticeable in SOL 1 using EPS warning message.

0*** USER INFORMATION MESSAGE 3035
     FOR SUBCASE NUMBER     1, EPSILON SUB E =   1.3947010E-12

pp01.bdf now runs OK (OCMEM set to 300 Mw) and same for large_problem3.bdf (see issue #18 ).