NASA Software List?

[B-ROB]

Does NASA have a comprehensive list of software programs that are available to the public through open source, user agreement or license?

This lists contains open source projects:  http://ti.arc.nasa.gov/opensource/projects/

However, that list does not seem to be comprehensive, even for open source.  For instance, it lists OpenVSP but does not list "OpenMDAO"?  Why not?

Is there a list for non-open source projects, but the public may use them if there is an agreement in place, such as OverFlow?

I know NASA has some software gems and I'm trying to find them...but it's like a treasure hunt. 

[Steve]

In case this website hasn't pushed it enough, Cart3D is an amazing
Euler CFD code. It's very easy to use and Mike Aftosmis is very
responsive to questions. Make sure you check out the PDAS
http://www.pdas.com/contents15.html software. There are a lot of
public domain NASA programs freely available for download. Also check
out http://code.google.com/p/nasa-cosmic/ which also has quite a few
old programs.

While I'm at it, I might as well put down my open source project.
It's a Nastran BDF/OP2/OP4 parser written in Python. It's pretty
capable and the next version will be even better :) There's also a
simple GUI and I'm adding Cart3d support so you'll be able to export
the model to and from Nastran.
http://code.google.com/p/pynastran/

[Rob McDonald]

Steve,

Thanks for the information. Especially the links to the recovered
COSMIC archive. If you have contact with that group - I'd love to see
more. Resurrecting a complete COSMIC archive would be a great
service.

Rob

[Nathan Alday]

Seconding Rob on resurrecting COSMIC. I hear someone mourning COSMIC at least twice a month.

--Nathan

[Nathan Alday]

There's also http://code.nasa.gov/

While I'm at it, I might as well put down my open source project.
It's a Nastran BDF/OP2/OP4 parser written in Python.  It's pretty
capable and the next version will be even better :)  There's also a
simple GUI and I'm adding Cart3d support so you'll be able to export
the model to and from Nastran.
http://code.google.com/p/pynastran/

Oh, wow. That's amazing. I worked on a Nastran/Abaqus converter in Python in grad school. Never got it really working. Things were nasty.

--Nathan

[Steve]

Nathan,

I've written the converter before; it's really easy because it's not
meant to be one to one. I use Nastran to set the regions (for skin
friction drag and boundary conditions) on my tri model and fix gaps &
normals. Then I just send it to cart3d. It'll use the PSHELL ID as
the region ID, and then have dummy material/thickness data. So only
CTRIA3, GRID, COORDx, PSHELL, and MAT1 cards.

If you still have your Abaqus converter, I'd love to get my hands on
it :) I'd like to write a Calculix converter and I think Abaqus is
the same format...

Everyone else,
There were no additional NASA COSMIC software programs, but I was
pointed to:
http://guide.conecta.it/index.php/Engineering_and_manufacturing

What I know about them:
OpenCascade: C++ Geometry Modeling/Meshing API. Useful as a backend
to a larger program.
pyOCC: Python bindings for OpenCascade
Salome: FEA meshing software
Code_Aster: very good FEA code written by the same people who wrote
Salome (developed by the European Defense Agency, documentation mainly
in French). It even supports dynamic mesh refinement similar to
Cart3D
OpenFoam: CFD software
Octave: Matlab-clone. From what I've seen it's as fast (or faster)
that Matlab, but may not work depending on what toolboxes your code
relies on. It's not perfect, but can handle most Matlab code.
However, it's usually worth it to modify your code to not be dependent
on Matlab (e.g. be more careful about not writing floats as strings,
don't define functions inside functions).

While we're on the topic of open-source software:
Calculix: probably the best free FEA software in English (Code_Aster
is better) http://www.calculix.de/
GMsh: another very good mesher http://www.geuz.org/gmsh/
Paraview: another highly parallel viewer http://www.paraview.org/
VISit: a highly parallel viewer for many formats https://wci.llnl.gov/codes/visit/
FreeCAD:

Many of these programs play nice with each other, so OpenCascade,
GMsh, OpenFoam, and Paraview work together. Same with Salome and
Code_Aster.

I'm also very impressed with Python as a programming language for
engineers and strongly recommend it over a program like Matlab. A lot
of people who have no vested interest in it (NASA included) are
pushing Python. I've coded in Perl, Fortran, C++, Matlab, and
Python. Given the choice for a program (large or small), I'm using
Python. It can even link into C, C++, and Fortran to do heavy duty
numerical computations. If you're interested check out numpy.org,
scipy.org, and http://matplotlib.sourceforge.net/ to see some of what
it can do (for free). Then get Python (with all packaged you'd want)
from http://code.google.com/p/pythonxy/ (for Windows ONLY).

Steve


On May 29, 8:46 am, Nathan Alday <n.c.al...@gmail.com> wrote:
> There's alsohttp://code.nasa.gov/

>
> While I'm at it, I might as well put down my open source project.
>
> > It's a Nastran BDF/OP2/OP4 parser written in Python.  It's pretty
> > capable and the next version will be even better :)  There's also a
> > simple GUI and I'm adding Cart3d support so you'll be able to export
> > the model to and from Nastran.
> >http://code.google.com/p/pynastran/
>
> Oh, wow. That's amazing. I worked on a Nastran/Abaqus converter in Python
> in grad school. Never got it really working. Things were nasty.
>
> --Nathan
>
>
>
>
>
>
>
> On Mon, May 28, 2012 at 11:05 PM, Steve <meshe...@gmail.com> wrote:
> > In case this website hasn't pushed it enough, Cart3D is an amazing
> > Euler CFD code.  It's very easy to use and Mike Aftosmis is very
> > responsive to questions.  Make sure you check out the PDAS

> >http://www.pdas.com/contents15.htmlsoftware.  There are a lot of

> > public domain NASA programs freely available for download.  Also check

> > outhttp://code.google.com/p/nasa-cosmic/which also has quite a few

[Nathan Alday]

Steve,

I'll look for it, but I'm not hopeful :(

But I will add a few more tools to your Open Source list (Note: by and large these aren't NASA programs):

BRL-CAD for solid modelling: http://brlcad.org/
Sage Computer Algebra System and Swiss army knife for numerical work tied together with Python: http://www.sagemath.org/
GMAT for space mission analysis and trajectory optimization: http://gmat.gsfc.nasa.gov/
Spyder: Matlab like IDE for Python. Included in the previously mentioned Python(x,y) but is multiplatform: http://code.google.com/p/spyderlib/

And, well, lots of other stuff. I have notes at home. I'll provide more upon request, but I don't want to completely co-opt the OpenVSP list :)

Thanks for the links
--Nathan

[B-ROB]

What is the "COSMIC" collection?

Does anyone know of a good open source aircraft sizing program?  I'm writing my own but I'd really like one to check against.  I hear old versions of ACSYNT are open source, is that true?

So here's my list of tools that I use (or will be using) for aircraft design:

1. Sizing: Currently, my own.
2. Geometry/CAD: VSP, FreeCAD, Rhino
3. Aerodynamics: Vorlax, Cart3D, possibly using a NS solver in OpenFOAM
4. Structures: Calculix
5. Programming: Python(x,y)
6. MDO: OpenMDAO

I'd actually like to wrap all of the programs up into a loop using OpenMDAO, but I don't know how complex that will be.  If you have any suggestions, let me know!

The next step is to get a list of tools that will actually make something.  I was thinking of Makerbot but something bigger, like open source software for CNC machinery. 

[Mark Moore]

No avaunt is definitely not open source and never will be.  I am the only person I know who still uses it

[Rob McDonald]

COSMIC was a NASA software archive run by the University of Georgia
years ago. They provided a place you could go to get lots of diverse
programs for a copying fee -- sometimes in the hundreds of dollars.
COSMIC has been shut down for years. The 'Open Channel Foundation'
still makes some of the COSMIC software available.

There were tons of aircraft sizing programs developed over the years.
Most are probably unavailable. However, most of them were developed
for some specialized application (subsonic transports, general
aviation, supersonic fighters, vstol aircraft, space access,
hypersonics, etc.) What class of vehicle are you interested in
investigating? Building a suite of tools appropriate for all vehicle
classes is infinitely more involved than building a suite of tools for
a particular vehicle class.

Rob

[B-ROB]

Rob: General aviation, but with an emphasis on aerobatics.

Mark: Never heard of "Avaunt."

[Rob McDonald]

I believe Avaunt was Mark's typo version of Acsynt. I know Mark was
involved with the creation of Acsynt, still uses it, and is probably
the last person on earth to do so.

You may be interested in GASP - General Aviation Sizing Program. I do
not believe you will be able to find the source code for it, but there
are some very detailed manuals for it on NTRS. There should be enough
detail there to recreate the parts you may need.

In many ways, a serious aerobatic aircraft does not require
traditional sizing. While you obviously still need to choose the
correct power to weight and wing loading - or engine and wing size -
you don't need to size the vehicle to a mission in the traditional
way. After all, you aren't really concerned about range or long
periods of cruising flight.

Rob

[B-ROB]

Well, Boeing uses ACSYNT all the time.  They got it and the source code (not sure if they got all of it) from AVID  LLC.  It's been modified over time, but they make a lot of use out of it.

 

Yeah, aerobatic planes are a different beast.  I think my main concern is figuring out how it reacts post-stall and so forth. 

On Sunday, June 3, 2012 6:57:44 AM UTC-7, Rob McDonald wrote:

I believe Avaunt was Mark's typo version of Acsynt.  I know Mark was
involved with the creation of Acsynt, still uses it, and is probably
the last person on earth to do so.

You may be interested in GASP - General Aviation Sizing Program.  I do
not believe you will be able to find the source code for it, but there
are some very detailed manuals for it on NTRS.  There should be enough
detail there to recreate the parts you may need.

In many ways, a serious aerobatic aircraft does not require
traditional sizing.  While you obviously still need to choose the
correct power to weight and wing loading - or engine and wing size -
you don't need to size the vehicle to a mission in the traditional
way.  After all, you aren't really concerned about range or long
periods of cruising flight.

Rob

[Mark Moore]

Not quite.  We gave ACSYNT to Boeing as part of the ACSYNT Institute - I was one of the key researchers who set that up.  Boeing then made their own modifications, and kept them for themselves.  Avid is a company started by two ex-NASA employees who were also involved in the ACSYNT Institute.  They tried to get ACSYNT from NASA but couldn't because ACSYNT has a great deal of ITAR related code in it.  Avid then arranged to get a copy of Boeings version of ACSYNT, without NASA authorization.  Avid then made their own modifications and came up with ACS code - which they specifically say is not ACSYNT (otherwise they would have significant legal problems, because they have no right to have it). 

Boeing has not kept in touch with us about ACSYNT, so we have no idea if they are using it - they went their own way.  I should have said that I am the only NASA person who still uses ACSYNT.  It is an excellent sizing code for optimization (especially for fighters and GA aircraft).  But it will NEVER be open sourced.  I programmed up most of the aerodynamics and know that there is a bunch of F-16 aero data in their (as well as much data from other fighters).  There is no way that it could released to the public without a huge effort to locate all ITAR related data, and strip it out.  And no one at NASA would agree to do that.

So you can try to get Boeings version.  It is a total loophole that they can release, and I even question whether it really legal for them to do so.

Good luck.

Mark

[Rob McDonald]

> Yeah, aerobatic planes are a different beast.  I think my main concern is
> figuring out how it reacts post-stall and so forth.
>

Well, none of the tools discussed so far will help with post stall
aerodynamics or flight dynamics.

Frankly, I don't think there is a computational tool I would trust for
post stall aero for an aerobatic propeller plane - especially when
considering the P-effects.

Good luck,

Rob

[B-ROB]

You don't think a RANS solver in OpenFoam will get me trends even?

What would you trust?

[Steve]

from http://en.wikipedia.org/wiki/P-factor

Causes
When an aircraft is in straight and level flight at cruise speed, the
propeller disc will be normal (i. e. perpendicular) to the airflow
vector. As airspeed decreases and wing angle of attack increases, the
engines will begin to point up and airflow will meet the propeller
disc at an increasing angle, such that horizontal propeller blades
moving down will have a greater angle of attack and relative wind
velocity and therefore increased thrust, while horizontal blades
moving up will have a reduced angle of attack and relative wind
velocity and therefore decreased thrust. Vertical blades are not
affected. This asymmetry in thrust displaces the center of thrust of
the propeller disc towards the blade with increased thrust, as if the
engine had moved in or out along the wing.

It sounds like to analyze this properly, you're going to need to have
a code that can simulate movable geometry with the equations of motion
and seriously unsteady flow. FUN3D (NASA unstructured code) might do
it. I would recommend looking into codes that can do store
separation, because you'll need a code of that complexity. The other
problem is codes that can do things like that are not meant for low
speed aerodynamics and propellers.

The other way to do this would just be to go into a tunnel and measure
that stuff.

Ultimately, I'd just recommend simplifying you're problem and not try
to fully characterize post stall for a single engine aircraft. If you
do, you're going to need a nice cluster to run this problem on.

Steve Doyle

[Rob McDonald]

Prediction of 'steady state stall' aerodynamics is a true challenge.
Predicting separation position and thereby angle of attack and
aerodynamic loads is highly dependent on turbulence modeling. These
things are very difficult, but are potentially doable if you are
willing to expend the required resources (fine meshes, grid resolution
studies, etc).

However, that is for a single fixed angle of attack, with no sideslip,
and no influence from the propwash.

An aerodynamic body in somewhat free dynamics is a very hard problem
in its own right. This is essentially the store separation problem
mentioned by Steve. The aerodynamic loads determine the dynamics of
the motion - which determines the angle of attack and sideslip. The
aerodynamics are necessarily unsteady. These problems are usually
attempted through a coupled aerodynamics and dynamics solver.
However, the store separation problem is usually limited to attached
flow. Fortunately, you only have one body, so you don't have to deal
with a moving mesh.

The propeller influences the flow in more complex ways than a jet
engine would. It introduces an asymmetric element to an otherwise
symmetric flow. Depending on the particulars of your problem, you may
be able to treat the propeller in a time-averaged sense as an actuator
disk.

Your problem combines all of these things. Separation and stalled
aerodynamics, unsteady flow, coupled dynamics, p-effects, etc. Worse
yet, that hasn't even included the influence of the pilot. Are all
the controls fixed through the maneuver, or is he swinging the stick
from stop to stop? Which maneuver are you considering? Are you going
to model them all - from all entrance velocities, etc?

So, that is the bad news...

What do you hope to get out of this analysis? If you are sizing the
aircraft, I'll assume it doesn't exist yet and you're considering a
design problem. What result would influence a design decision? What
performance in what maneuver would you deem acceptable? If a
candidate design is unacceptable, what would you change to improve it?

A lot of aerobatic aircraft have been designed over the years without
this kind of sophisticated analysis. Before you undertake this
monumental task, I would try to get a handle on what you hope to get
out of it.

Rob

[B-ROB]

Thanks for the reply, everyone.  Very good information all around.  I appreciate it.  I'm gonna keep working on my math model and when I get further down the road I'm going to come back and revisit all the details in this thread.

[Yoki]

Hi Steve,

I've seen your discussion about pynastran. This was quite long time ago, but I am interested whether you plan to support *.xdb as well? As far as I know *.op2 supports only 2GB of data, wheras *.xdb can keep much more. Why did you decided to use *.op2? I am also looking for the open source converter between Nastran and many other commercial and freely available tools (LS-Dyna, Abaqus, MSC.Marc, CalculiX, Code-Aster etc.). Do you have on your roadmap any support (at least with the basic functionality to transfer the mesh: elements, nodes) between the codes? Did you maybe get the Abaqus converter from Nathan? Can you please provide the complete list of the solvers (incl. what items are supported) already implemented in pynastran? I could not find it in the documentation.

I would be grateful if you or someone else in the group could recommend any open source converter between different open-sourced/commercial programs.Is any initiative already running? At the end of my today post the general question to your list of open source software. Is it still up to date? I am trying to find the answer to the question what is the best freely available meshing tool for the FE analysis. Did something change or still the decision will be between Salome and GMSH? LS-PrePost looks also promising.

Regards,

Yoki

[Steve]

Yoki,

We should take this discussion to https://groups.google.com/forum/#!forum/pynastran-dev

I think it's too specific to be discussed here.