MYSTRAN Forum
NASTRAN-95 vs MYSTRAN - Printable Version

+- MYSTRAN Forum (https://www.mystran.com/forums)
+-- Forum: ComLab and NASTRAN-95 (https://www.mystran.com/forums/forumdisplay.php?fid=10)
+--- Forum: ComLab and NASTRAN-95 (https://www.mystran.com/forums/forumdisplay.php?fid=11)
+--- Thread: NASTRAN-95 vs MYSTRAN (/showthread.php?tid=4)

Pages: 1 2

NASTRAN-95 vs MYSTRAN - Admin - 01-11-2020

It is relevant to compare MYSTRAN to NASTRAN-95 and also discuss the state of NASTRAN-95.

-----------------------------------------------------

NASTRAN-95 (Advantages):
- More developed and includes aero and fluid elements.
- More history of use (more well known)
- The buckling solutions are more developed (MYSTRAN only supports beam elements for Eigen solutions).
- DMAP capability

NASTRAN-95 (Disadvantages):
- The user manual may need updates.
- Some of the element formulations are old (i.e. shells may exhibit shear locking).
- The code may be difficult to develop, but there may be a few developers who can work with it.
- The solver that is used may be outdated by today's standards (considering the solver is at least 25 years old).
- No PSHELL or PCOMP?

NASTRAN-95 (Unknowns):
- There appears to be some nonlinear analysis capability, but the extent is not known. Need to investigate the MATS1.

-----------------------------------------------------

MYSTRAN (Usability)
- A compiled version for Windows exists.
- Complete processes for compiling in Windows using open source tools.

MYSTRAN (Advantages)
- Perhaps the biggest advantage of MYSTRAN is developers should find it more user friendly.
- Created with more modern software and hardware in mind.
- User manual is complete and updated.
- Newer solvers can be incorporated with relative ease.

MYSTRAN (Disadvantages)
- Not as developed (less features) or well known as NASTRAN

Extra info on - borges - 08-13-2020

Based on my previous work with NASTRAN-95, I'd like to bring forward some information you might find useful in some way to keep this comparison correct and up-to-date.

Regarding NASTRAN-95's capabilities:

  • NASTRAN-95 cannot allocate more than 14 million words (56 MB) to its open core. Any value of OCMEM above 14000000 will cause a fatal error to be issued.
    That makes it unable to load larger models, and limits the in-memory database size for medium-sized models, therefore hurting performance.
  • Said limitation indeed makes the solver outdated by today's CPU architectures standards. IBM and COSMIC got it to alloc up to 2 GiB to itself, but that's still not enough for large models with a workable DBMEM... and they never relased the code for that AFAIK.
  • It does, however, have a PSHELL card, but it works differently. Modern NASTRANs (e.g. Autodesk, Simcenter, MSC) use PSHELL for all "shell" elements, like QUAD4 and TRIA3, whereas NASTRAN-95's PSHELL can only be referenced by CQUAD4 cards.
  • NASTRAN-95 does not have a CTRIA3 card. The closest you can get is CTRIA2, or maybe use a CTRSHL (similar to CTRIA6) with points 2-4-6 being merely the midpoints between 1-3-5 respectively. And you'd still have to change the PSHELL referenced by the CTRIA3 card into a PTRIA2/PTRSHL and, in the latter case, add three extra grid points.
  • Due to string-size and encoding limitations, file names that contain special characters, spaces, or are too long (by 80s' standards) will cause crashes or otherwise weird behavior. You're forced to keep file paths mostly alphanumeric and short.
  • Several undocumented error codes. Encountering error N but seeing the manual skip from error #(N-1) to #(N+1) is not uncommon.
  • No BAILOUT parameter -- singularities force exits at NASTRAN's discretion.
  • No BEAM element. Best you can do is convert to CBAR+PBAR and discard intermediate stations.
  • AUTOSPC behaves differently from proprietary NASTRANs' in some warning/edge cases, leading to singularities.
  • Less leniency on bulk data card format requires manual intervention/editing before running models generated by modern (proprietary) CAD/CAE applications.
  • The top "Nastran" cards generated by said applications are completely incompatible. You will have to manually rewrite or comment them to have any hope of getting the model to even load.
Regarding compiling and using NASTRAN-95 in newer platforms:
  • NASTRAN-95 actually can be compiled using open-source tools. There's a even a small toolset to compile, test and invoke it. I managed to get it running under x86_64, both Linux and Windows, and even cross-compile from Linux to Windows.
    Some devs have released compiled binaries for both platforms, but I never tried them -- I'm more comfortable building my own.
  • These tools, however, are not perfect, nor do they work out-of-the-box; actually compiling the thing may require some developer intervention.
  • In fact, all attempts to compile it with gfortran (gcc) versions other than 7 have produced nonworking binaries, and no one knows if it's a gfortran/libgfortran bug or some quirk/undefined behavior in the legacy F77 code.
    With ABI changes and more distros dropping support/packages for gcc-7, it's going to get harder and harder to compile NASTRAN-95 for modern targets, especially Windows.
  • Invoking it is an absolute mess. Most options are passed through environment variables, so you will need a helper program to set up bootstrapping shell scripts.
In the interest of simplicity, I'd condense this information further into the following points:
  • NASTRAN-95 has an open core memory hard limit of 56 MB
  • NASTRAN-95 lacks support for BEAM and TRIA3 elements, and many others
  • NASTRAN-95 has a different behavior for PSHELL cards
  • NASTRAN-95 can be compiled for modern platforms using open-source tools... but it's a complex process, and may break in the near future
  • NASTRAN-95 can be invoked in modern platforms, but you'll need a helper program due to the way it takes parameters
  • NASTRAN-95 lacks or has different behaviors for many parameters
  • NASTRAN-95 crashes on long file paths or special characters (and less leniency when parsing input in general)
  • NASTRAN-95 has outdated behavior for the Nastran top card
  • NASTRAN-95 has poorly or non-documented error codes (and hard-to-find documentation in general)
I hope this information can be useful and/or make this comparison richer.

RE: NASTRAN-95 vs MYSTRAN - Admin - 08-13-2020

Wow, that is great information. I am not sure how you feel about NASTRAN-95, but it seems like a lot of work and it doesn't seem to be able to attract attention from developers (steep learning curve). Harry Schaeffer does have a version called ComLab for $100 ( https://github.com/nasa/NASTRAN-95/issues/5 ). But he is very familiar with the NASTRAN and I think it was a significant effort (and not open source). Some months ago, I talked to someone else who wanted to get serious about NASTRAN-95, but it fizzled out when reality hit.

RE: NASTRAN-95 vs MYSTRAN - ceanwang - 08-15-2020

“NASTRAN-95 cannot allocate more than 14 million words (56 MB) to its open core. Any value of OCMEM above 14000000 will cause a fatal error to be issued.
That makes it unable to load larger models, and limits the in-memory database size for medium-sized models, therefore hurting performance.”


NASTRAN-95 may not has open core more than 14m, but it was designed to solve big case with small machine. It solves, but not in high performance. Especially not fully use today hardware's capacity.

RE: NASTRAN-95 vs MYSTRAN - borges - 08-15-2020

(08-15-2020, 02:11 PM)ceanwang Wrote: NASTRAN-95 may not has open core more than 14m, but it was designed to solve big case with small machine. It solves, but not in high performance. Especially not fully use today hardware's capacity.

Well, as long as NASTRAN-95 can load the model (such as by setting low values for DBMEM, hurting performance), it'll sure solve it. But that was not my point.

I was talking about how the 14 Mword (56 MB) OCMEM limit creates an upper limit for loadable model size (as in nº of elements).

There are several "model checking" subroutines (e.g. CIDCK) that that are run before other pre-solve steps (e.g. BANDIT) and they do operations which require allocating memory (e.g. some kinds of sorting). Since for some of these subroutines the amount of required memory grows monotonically with respect to how many of a card you have in the bulk data block, there is an upper limit to how many of that card you can have. And since that happens for rather common cards (e.g. GRID), the memory upper bound creates a model scale upper limit.

In practice, this means there are models used today that cannot, by any means, be run by NASTRAN-95, because the memory required for running basic pre-solving subroutines on them exceeds the upper bound on open core memory. In order to run them, you must either edit the model (make it coarser?) or change NASTRAN's code so either the involved subroutines use up less memory or there's more memory to begin with.

RE: NASTRAN-95 vs MYSTRAN - Admin - 08-15-2020

Speaking of solving, one of other issues with NASTRAN-95 is that I believe it has a very old sparse solver. We removed the old Intel sparse solver from MYSTRAN because it was not robust (it still has LAPACK banded solver though). But it would be really good to add the PaStiX sparse solve to MYSTRAN. I will try to get more information about that. CalculiX recently added it and I think it is a really good option.

RE: NASTRAN-95 vs MYSTRAN - ceanwang - 08-15-2020

(08-15-2020, 07:02 PM)borges Wrote: I was talking about how the 14 Mword (56 MB) OCMEM limit creates an upper limit for loadable model size (as in nº of elements).

You buy a 4g ram PC, you can load some models. When you want to load bigger model, maybe you need to open the PC to expand the ram to 8g. 
It is the same as the OCMEM. You need to edit the program to increase it. 

RE: NASTRAN-95 vs MYSTRAN - borges - 08-16-2020

(08-15-2020, 11:29 PM)ceanwang Wrote: You buy a 4g ram PC, you can load some models. When you want to load bigger model, maybe you need to open the PC to expand the ram to 8g. 
It is the same as the OCMEM. You need to edit the program to increase it. 

It doesn't matter how many RAM your PC has. Mine has about 16 GB.

However, none of that matters: OCMEM is an environment variable that you pass to the NASTRAN-95 executable to tell it how many (four-byte) words it should attempt to allocate for its open core. You can set it to any positive integer value equal to or less than 14000000, representing 56 MB of open core. Setting it to any value outside of that set (e.g. "14000001", "-5", "2.71828", "donuts"), regardless of file validity or model scale, will cause a fatal message to be issued:

Code:
  LARGEST VALUE FOR OPEN CORE ALLOWED IS:    14000000
  ERRTRC CALLED
  NAME=WRTMSG 
  IVAL=         100




                                        * * * END OF JOB * * *
1
JOB TITLE =                                                                     
DATE:  0/ 0/ 0
END TIME: 21:35:48
TOTAL WALL CLOCK TIME      0 SEC.

That's the entirety of an .f06 file I just produced by calling NASTRAN-95 with a good model while having set OCMEM=14000001.

No matter how much memory your PC has, NASTRAN-95 will never allocate more than 56 MB for its open core, thus creating an upper bound on loadable model size.

Furthermore, even if you changed the code to let NASTRAN-95 use all of its open core address space (like IBM did), you'd still be limited by the fact it most likely uses 32-bit integers to address the open core, so even then you'd be limited to around 2 (or 4 if unsigned) GB, which is nice, but way below large production-scale models in use with modern NASTRANs such as Simcenter's.

RE: NASTRAN-95 vs MYSTRAN - ceanwang - 08-17-2020

(08-16-2020, 01:12 AM)borges Wrote: However, none of that matters: OCMEM is an environment variable that you pass to the NASTRAN-95 executable to tell it how many (four-byte) words it should attempt to allocate for its open core. You can set it to any positive integer value equal to or less than 14000000, representing 56 MB of open core. Setting it to any value outside of that set (e.g. "14000001", "-5", "2.71828", "donuts"), regardless of file validity or model scale, will cause a fatal message to be issued.

The program set the largest number at 14000000, you ask more than that, sure you will get a warring.

You need to raise that largest number in the program.

RE: NASTRAN-95 vs MYSTRAN - borges - 08-17-2020

(08-17-2020, 02:28 AM)ceanwang Wrote: The program set the largest number at 14000000, you ask more than that, sure you will get a warring.

You need to raise that largest number in the program.

I'm somewhat skeptical of the meaning of "just change the max value" -- they must've set it at 14 M for some reason. Keep in mind the doc where they claim to have gotten it to alloc 2 GB also mentions it having been "a lot of work".

But even if you DID change the max value and that didn't break NASTRAN-95's memory management strategy outright (which I find unlikely), you'd still be limited to 2-4 GB max, which is still not enough for commercial-scale models. Keep in mind those models require more than twice that to even pass the checks, and are often alloc'd several dozens of gigabytes' worth of in-memory database in order to run in reasonable amounts of time.

All in all, rewriting the memory management code seems like so much of a hassle... It pretty much sums up how I feel about NASTRAN-95 as a whole: it's an outdated program; it can't run models output from modern CAD software, and even after converting unsupported elements (lossily so), it still has hard limitations on scale, run time, and output quality. It's good, in the name of science, legacy and all that, that we got it to compile and run on modern machines, but we shouldn't put any effort into trying to improve it. Well, I certainly won't.

We should keep good docs on this amazing piece of legacy software, let it inspire us when possible, but focus actual work on more modern OSS solutions like MYSTRAN.