pyNastran project

[steve]

I'm the main developer of pyNastran. It's currenlty a fairly complete
open-source (LGPL) Python reader/writer of the various Nastran file
formats (BDF, OP2 currently; OP4 is on the way). There are ~150 BDF
cards and ~40 OP2 results (the op2 number is not as easy to estimate),
as well as a simple GUI in the v0.3 release.

I've seen your code a bit a was wondering if you'd be interested in
helping at all. I'm most interested in your Patran XDB work. I've
had a few requests so far for that capability and was hoping that
you'd be interested in working on it in pyNastran. Of course, if
there's anything else you'd like to contribute instead or if there's
something I can help you with, let me know. I'm very interested to
see how we can better to work together.

http://code.google.com/p/pynastran/

Steve

[FeResPost]

Hi everybody,

I know that some of you are interested in Python programming and
would
probably use a FeResPost extension in Python. This proposition might
be
an approtunity to start a collaborative project.

What do you think ?

Renaud.

[Yoki]

Hello together,

Do we have any comparison table about the functionalities of both projects? It would help a lot to better recognize which project to entry. In general I think the both very useful (thanks!) initiatives should join together. I do not know throughout both projects, but suspect there are identical parts on each side, which slows the development (both sides) doing the things double.

Do you think, that we can have in the future only one project or the architectural differences are to big?

Regards,

Yoki

[Steven Doyle]

Yoki/Renaud,

I'm the main developer of pyNastran.  Unfortunately, I don't have that list of differences.  PyNastran is a Python-only library to read the BDF input file, the OP4 matrix file, the OP2 results, as well as a GUI.  PyNastran is a very capable library, though because it's written in Python, the BDF reading/manipulation is a lot slower.  Due to vectorization of data, the OP2/OP4 are more than fast enough (you can read a 2 GB OP2 in ~4 seconds).

The main goal of the pyNastran project is to read everything in the BDF/OP2.  For the BDF, this includes comments, unlimited INCLUDE files, and unicode, as well as MSC/NX Nastran decks. There aren't that many differences regarding MSC vs. NX, but there are a few. I'm not sure where FeResPost stands on these topics.  Regarding results, pyNastran won't read the XDB (like FeResPost), but as long as you don't do random analysis, it's unlikely that you'll run into data you cannot read.  This includes real/complex results with superelements and SOL 200..

PyNastran only supports Python (FeResPost supports Ruby, C#, Java, Python), but pyNastran will work on Linux and Mac unlike FeResPost.

If you've ever worked with Python, you'll know it's easy to develop for, though you sacrifice quite a bit on the speed end.  I'm OK with that given the convenience.  I don't know C/Java/Ruby and honestly getting pyNastran setup is hard enough for other people that use the code.  This Python-only desire imposes requirements (e.g. doesn't work in C#) that I suspect Renaud requires.  Unfortunately given that, I don't really think there's a way to unify the projects unless Renaud would consider switching to Python :)

Steve

--
You received this message because you are subscribed to the Google Groups "FeResPost" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ferespost+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Renaud Sizaire]

Hello everybody,

I try here to summarize some information about FeResPost, and compare to what I know of pyNastran (see mail of Steven, below):

•  With FeResPost, models can be read from BDF and OP2 files. (BDF reading is recommended though.)
• Results can be read from OP2 and XDB, but not from OP4. It also seems to be slower than with pyNastran. Generally, the reading from XDB is recommended: random access is allowed, complex results can be read,... SOL200 results are only partially supported.
  
• There is no GUI in FeResPost. (It is meant to be used to write post-processing scripts or programs.)
• Some tests have been done with NX/Nastran, and it seems to work. But the NX cards or results that differ significantly between NX and MSC might lead to problem. (No development specific to NX has been done in FeResPost.)
• FeResPost is distributed as a Ruby extension, .NET component and COM component:
• Ruby extensions are distributed on LINUX and Windows.
• .NET component can be used with C++.NET, VB.Net, C#... Generally on windows, even though it seems that C# compiler is also available on LINUX.
• COM is specific to Windows OS. It allows FeResPost to be used with many programming languages on Windows (C, C++, VBA, RUBY, PYTHON...). Examples with COM/excel are provided with the program.
• You do not need C# to use a ruby extension or COM component.
  
• No binaries are distributed for MAC, but I presume that the ruby extensions can be compiled on MAC too. (I am not  very familiar with MAC OS.)

Now the question of unification of FeResPost and pyNastran is interesting, but I see difficulties:

• It might take a lot of time to evaluate only the feasibility to merge the projects. A major problem might be the programming languages that are used: FeResPost is programmed in C++ and pyNastran in Python.
• If one decides to start a common project, it becomes practically very constraining. Practically, it would probably mean to start a new project from scratch.
  

In my opinion it would have a chance to work only if a significantly larger community of developers works on the subject. Two or three would not be enough.

Regards,

Renaud.

[Jeffrey Ratcliffe]

On 29 February 2016 at 19:04, Renaud Sizaire

<renaud....@ferespost.be> wrote:
> It might take a lot of time to evaluate only the feasibility to merge the
> projects. A major problem might be the programming languages that are used:
> FeResPost is programmed in C++ and pyNastran in Python.

There are also Python (and Perl) bindings for FeResPost (or at least
the C++ part of it).

I don't know pyNastran well enough to know how easy it would be to
convert pyNastran objects into the FeResPost C++ objects and vice
versa.

Regards

Jeff

[Steven Doyle]

PyNastran uses numpy for almost everything, but there is an option for pandas DataFrames, which are useful in the Jupyter/iPython notebook.  

I took a look at the source for FeResPost the other day and it looks as if it reads about 15-20 different result types from the OP2.  PyNastran reads many more (though to be fair XDB is the preferred method).  What wasn't clear to me was what the data structure actually was.  

PyNastran uses a dictionary to store OP2 results, where the key is a tuple of (subcase ID, subtitle, optimization step, a few other things) and the value is a Python class (e.g. DisplacementArray, RealRodForceArray).  The extra key parameters are required for things like superelements and SOL 200 and single subcase buckling.  Static and transient results (or multiple superelements) can have the same subcase ID.  Without the extra keys in the tuple, data will be lost/mangled.  For simple cases, it's possible to reduce that key down to a single subcase ID, which is the default.  Regarding the RealRodForceArray class, that stores a numpy 1d array of elements and a numpy 3d array of data, where the data is [ntimes, nelements, nresults] in shape. Additionally, OP2 parameters (e.g. table name, analysis code, format code, etc.) are dynamically associated with the class.  All other result classes follow that style and all OP2 results can write an F06.

Regarding the BDF, 267 cards are supported using a Python class for each card object typically in a dictionary.  I'm not sure what FeResPost does.

My guess is it would be a lot of work to create the data in C++ and it's beyond my skill level.  The pandas work was also beyond me, but some people made a few good examples and I was able to add it for the other classes pretty quickly, so there's always that option.

Steve

[Jeffrey Ratcliffe]

Even further off-topic:

Has anyone tried to use Paraview to plot Nastran results?

Regards

Jeff

[Steven Doyle]

pyNastran is able to convert simple models to Paraview.  Basic elements are supported and static displacement results.

That said, any converter is going to have to deal with the problem of how do you represent a PSHELL vs. a PCOMP vs. a PSHEAR vs. whatever.  That conversion steps loses a significant amount of information.  I work with a lot of Nastran aero results, so how would CAERO cards or SPOINTs be represented?  The pyNastran GUI works with the data directly and while you can't do everything, you can plot fringe results, plot user-defined fringe results, plot deflected geometry, pick points, and do custom scripting from within/outside the GUI.  Paraview is great and I use it for CFD results, but it just seems too limited to display Nastran geometry/results properly.

Regards

Jeff

[Renaud Sizaire]

I never heard of Paraview before. I will have a look.

Regards,

Renaud.

[Siva Aero]

Hi.. I have calculate displacement and stress results, then how to write op2 file by using pyNastran... can u tell me pls...

[Steven Doyle]

This is an FeResPost forum.  This is not the right place to have that discussion.

--