Suggestions for handling differences between versions of Nastran

[Steve Doyle]

There are multiple versions of Nastran floating around.  There's MSC, NX, Radioss, and probably more.  Most of the time, a card (e.g. a GRID card) is the same between each version.  However, there are subtle differences.  A few examples include:

    1.  An MSC SET3 card must be split across various lines, but in NX, each SET3 card must be unique.  

    2.  NX supports node/element IDs that overbound the 8-character field and are written in large field format, whereas MSC has a hard cap.

    3.  MPC forces have a table code of 39 for MSC and 3 for NX.  This information is relied on to properly create OP2 result objects and check that data is being parsed correctly.

    4.  The obvious difference in supported cards

I'd like to avoid forcing restrictions on #4 (card usage) as you start to get into the question of MSC Nastran 2010 vs. 2015, but I think there is a need.  I'm thinking of something along the lines of:

model = BDF()

#model.set_as_msc() # the default

model.set_as_nx()

model.read_bdf(bdf_filename)

Does anyone has a better idea?

[Jeff Lyon]

Steve,

I agree that this is an important problem to address. As time goes on, the various codes will continue to diverge. Are you planning on supporting more than the big two (NX and MSC)?

The following ideas could supplement the method you described:

1. add a decoration to the BDF declaring the file to be either NX or MSC compatible (e.g., the first line in the deck $pyNastran: VERSION=MSC). Then if there is a card in the deck incompatible with that version, an exception could be raised (e.g., NastranVersionError)

2. during BDF reading, consider the deck to be version-agnostic until the first version-unique card is found, then set the version attribute (e.g., BDF.__version) accordingly. If other cards are found that are incompatible with that version, raise an exception.

Thanks,

Jeff 

[Steven Doyle]

Jeff,

If I had proper documentation for Radioss and the test problem library in BDF and OP2 form, I'd have no problem supporting it.  It's a popular-ish version of Nastran.  In regards to unpopular versions, no.  If someone wants to write an Abaqus to BDF/OP2 converter, it needs to conform to the standard.  For now, it'll be NX or MSC.

For the BDF, I thing option #1 is possible, but I dislike option #2.  I don't think option #2 reliably addresses things like SET3 cards and grid IDs > 1,000,000 without a lot of extra complexity.

In regards to option #1, I like the syntax because it's very obvious that it's meant for pyNastran.  I'd add that it should probably be the first line if it's going to be defined.  Another option would be to add something like:

PARAM,NASTRAN,MSC

or

PARAM,VERSION,NASTRAN,MSC

or

PARAM,VERSION,MSC

to the case control/bulk data deck.  I tested the first one with an older version of MSC Nastran and it was fine.

The way I'd probably implement the BDF check is read the whole deck and then check to see you don't have MSC/NX specific cards.  Then, when you write it out, you can overwrite that option.

Whatever approach is chosen, it should support the BDF and OP2, so a combination of options (e.g. set_as_nx/set_version('nx') and option #1) with set_as_nx overwriting the value in the model might work.  There does need to be a default though.  I think it has to be MSC as MSC more closely conforms to the standard from 20 years ago.

Steve

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