Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
NASTRAN-95 vs MYSTRAN
#11
(08-17-2020, 11:43 AM)borges Wrote: 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.

I have to agree. Some years ago Bill converted MYSTRAN to a free program (it was a commercial program before that). However, it was put on a NASA server (and only compiled with Lahey Fortran), missing documents, etc. While I was familiar with NASTRAN-95, I still thought MYSTRAN was a better long term solution, so we have been working to upgrade everything. About a year ago, NASTRAN-95 received more attention. At that point, the question was whether effort should be put into NASTRAN-95 or MYSTRAN. I decided we should pursue parallel paths and let things fall out naturally. I talked with some developers who were serious about NASTRAN-95 and getting it "up to speed". But it fizzled out and I could not find developers interested enough in taking on this massive challenge. It seems that MYSTRAN is much more workable and that it is a better long term platform for the community. There has been sufficient interest in it to continue on (unlike NASTRAN-95, at least for now).

Harry Schaeffer created ComLab, which is based on NASTRAN-95. I have a copy, but have not used it much. But Harry has been working with NASTRAN since the early stages and is very familiar with it. I doubt there will be anyone even close to as familiar with it as him. And since he does not work much on the open source side, I don't see NASTRAN-95 going anywhere (at least currently). Here is the manual to Harry's ComLab program (he sells the program for $100). He said I can post it here.

https://www.mystran.com/other/CML.pdf
Reply
#12
(08-17-2020, 11:43 AM)borges Wrote:  they must've set it at 14 M for some reason

Maybe it is a SPARC machine, and 14M suit that machine. The exe was compiled for SPARC machine.

You have a different machine, you could set at a different value to suit.

Need test cases to see how big could be loaded.

(08-17-2020, 10:02 PM)Admin Wrote: https://www.mystran.com/other/CML.pdf

Interesting, he wrote a plt2ps program. The plt1 is a text file which is easy to read and understand. 

plt2 is the binary version, NastPlot still work, can take in both plt1 or plt2 file. Just the ps result is not good compare to pdf.

see: https://github.com/nasa/NASTRAN-95/issues/17
Reply
#13
(08-17-2020, 02:28 AM)ceanwang Wrote:
(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.

You are right; it needs recompiling as explained in NASINFO file:

"AN IN-MEMORY DATA BASE IS AVAILABLE FOR ALL PLATFORMS.  THE IN-MEMORY
DATA BASE ELIMINATES I/O TO DISK.  LOGIC EXISTS TO AUTOMATICALLY WRITE
FILES TO DISK AFTER THE IN-MEMORY DATA BASE SPACE IS EXHAUSTED.  THE COMMON
/ZZZZZZ/ IS USED FOR ALLOCATING OPEN CORE AND SPACE FOR THE IN-MEMORY
DATA BASE.  THE SIZE OF COMMON /ZZZZZZ/ IS DEFINED IN ./MDS/NASTRN.F
(SEE ARRAY "IZ" AND VARIABLE "LENOPC"). "

"USERS ARE ENCOURAGED TO RECOMPILE "NASTRN.F" WITH A LARGER ALLOCATION
FOR COMMON /ZZZZZZ/ IF THEIR PLATFORM SUPPORTS A LARGER MEMORY ALLOCATION. 
A LARGER ALLOCATION OF COMMON /ZZZZZZ/ PROVIDES FOR MORE SPACE FOR THE
IN-MEMORY DATA BASE AND ALLOWS FOR MORE FILES TO BE MAINTAINED WITHIN
THE IN-MEMORY DATA BASE.  USERS SHOULD ALWAYS ALLOCATE SUFFICIENT
OPEN CORE TO PREVENT SPILL LOGIC (E.G., SEE USER INFORMATION MESSAGE
3023)."

In fact it is compiled to a maximum of 400000000 not 140000000 as you can easily check changing OCMEM environment variable to any value bigger than it (Ubuntu version).

and CTRIA3 is available, check latest User Manual file (in TXT file format, the PDF are outdated):

"CTRIA3 - Triangular Element Connection

Description

Defines a triangular plate element (CTRIA3) of the structural model. This is
an isoparametric membrane-bending element, with variable element thickness,
layered composite material, and thermal analysis capabilities.

Format and Example"


Attached Files
.txt   NASINFO.txt (Size: 16.85 KB / Downloads: 1)
Reply
#14
It's glad to see that so many people are still working on Nastran95. I recently wrote a finite element program framework in Python to complete the DKT Element. During the work, the Nastran-95 gave me a lot of useful information.
Currently, I am developing the beam element. There is only Bar element in Nastran-95, whose shear center coincides with centroid.
I want to know if there is any way to derive the beam element matrix with flexure torsion longitudinal uncoupled matrix?
Thanks for your reply.
Reply
#15
(09-27-2020, 10:35 PM)Civibelieve Wrote: It's glad to see that so many people are still working on Nastran95. I recently wrote a finite element program framework in Python to complete the DKT Element. During the work, the Nastran-95 gave me a lot of useful information.
Currently, I am developing the beam element. There is only Bar element in Nastran-95, whose shear center coincides with centroid.
I want to know if there is any way to derive the beam element matrix with flexure torsion longitudinal uncoupled matrix?
Thanks for your reply.

Curious...do you have any interest in adding the CBEAM element to MYSTRAN? If so, I can ask Bill to help out with that.
Reply
#16
(09-28-2020, 07:22 PM)Admin Wrote:
(09-27-2020, 10:35 PM)Civibelieve Wrote: It's glad to see that so many people are still working on Nastran95. I recently wrote a finite element program framework in Python to complete the DKT Element. During the work, the Nastran-95 gave me a lot of useful information.
Currently, I am developing the beam element. There is only Bar element in Nastran-95, whose shear center coincides with centroid.
I want to know if there is any way to derive the beam element matrix with flexure torsion longitudinal uncoupled matrix?
Thanks for your reply.

Curious...do you have any interest in adding the CBEAM element to MYSTRAN? If so, I can ask Bill to help out with that.

Thanks for your help. I think I can try to add CBEAM to Mystran.

I have already tested the bar with a round shape and a rectangular shape in my program. I analyze its mode shapes and natural frequencies. But when I applied the bar element to the beam section like a T shape. The first frequency of the beam is far higher than the result of the true one. I haven't found out why this occurs.  Do you have any information about CBEAM in Nastran? I can sort out my results and send them to Bill.
Reply
#17
I will touch base with Bill about it and he can work on a write up for what files would need to be added/modified. I will touch base again after we look into that.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)