Problem reading CBAR geometry from OP2 files

[pmoseley]

Hey Steve,

I'm trying to read an OP2 file (attached) which has a CBAR in it, using the following code:

model = read_op2(args.inp_file, build_dataframe=False, load_geometry=True, combine=True, debug=True)
model.write_op2(args.out_file)

And I'm getting the following error:

File "D:\DATA_SLOW\TOOLS\FATIGUE_CALCULATOR\python-3.7.7.amd64\lib\site-packages\pynastran-1.4.0+dev.4de9ca4a1-py3.7.egg\pyNastran\op2\tables\geom\geom2.py", line 595, in _read_cbar
assert f == fe, 'f=%s type(f)=%s fe=%s\n%s' % (f, type(f), fe, elem)
AssertionError: f=1 type(f)=<class 'int'> fe=65
CBAR         401       3    2217      81.2769987-.931498-.235759

If I create the same model without the CBAR (also attached), the read_op2 command completes without error.

The test models are really small. I've included OP2 versions from Nastran 2021.1 and Nastran 2019.1. I'm using the latest pyNastran from git. test_files.zip

[pmoseley]

Strangely, if I edit the commands to add "subcases=[1]", it runs without error:

model = read_op2(args.inp_file, subcases=[1], build_dataframe=False, load_geometry=True, combine=True, debug=True)
model.write_op2(args.out_file)

Not sure why this should affect the reading of the geometry. Seems like if you filter the subcases, the load_geometry doesn't actually work?

[SteveDoyle2]

Nastran doesn't crash on that? Why am I not surprised?

Your OFFT value is B. What does that mean?

[pmoseley]

I'm able to open the OP2 files in Patran without any problems, so they don't seem corrupted.

No error messages in the F06 file (attached) while running with Nastran, although there are some warnings. simple_plates--cbar.f06.log

The pyNastran error also occurs with my other models which have CBARs, so it doesn't seem like these test files are "abnormal" (from Nastran's point of view anyway...)

I'm not sure what the OFFT value is referring to, so unfortunately I don't have an answer for that...

[SteveDoyle2]

I fixed the subcase suppression issue dropping geometry.

[SteveDoyle2]

OFFT is a 3 letter word (B/G, B/G/O, B/G/O/A), which define how to interpret the x, wa and wb-vectors. The x-vector defines the y-axis and z-axes of the bar/beam. I think I got those letters right, but GGG is the default for NX (NX only has GGG and it must be blank) and MSC. The names for each letter are O, A, so O defines the origin, A defines node A (node 1) of the bar, respectively. Also, B refers to the basic frame (coord 0), while G refers to the displacement coordinate system of node A (node 1).

Regardless, you get 3 letters, so GGG, GOO, BOO, BOA are fine, but B is undefined.

[pmoseley]

Thanks for the explaination. The CBAR card allows for an OFFT parameter. In these examples, the OFFT parameter wasn't set in the BDF, so it should have been the default (GGG). Definitely strange that it would show up as "B" in the output OP2 file.

In my specific case, I'd be happy if pyNastran just treated these kind of exceptions as "pass-through" cases, and doesn't do anything with the CBAR. I don't need pyNastran to parse the CBAR parameters, I just want to be able to write that geometry back out to a new OP2 file exactly as it was read in.

[SteveDoyle2]

There is no requirement to write things exactly the same if they mean the same thing. MSC obviously means something, so I'd ask MSC what it means. From what i can tell, it doesn't make sense, so it can't interpret what the g0/x vector is. As of now, it's an error.

On Mon, May 3, 2021 at 12:07 AM pmoseley @.***> wrote:

Thanks for the explaination. The CBAR card allows for an OFFT parameter. In these examples, the OFFT parameter wasn't set in the BDF, so it should have been the default (GGG). Definitely strange that it would show up as "B" in the output OP2 file.

In my specific case, I'd be happy if pyNastran just treated these kind of exceptions as "pass-through" cases, and doesn't do anything with the CBAR. I don't need pyNastran to parse the CBAR parameters, I just want to be able to write that geometry back out to a new OP2 file exactly as it was read in.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SteveDoyle2/pyNastran/issues/645#issuecomment-831067332, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAICUWKYJDZPE2T2FIQF4ZLTLZDSXANCNFSM43U3ZQDA .

[pmoseley]

I've filed a bug with MSC regarding the OFFT parameter. I'll let you know their response.

My main interest in re-writing output exactly as the input is compatibility. When I do read_op2/write_op2 with pyNastran and load_geometry=True, I lose data (the new file is smaller) and some aspects are changing internally (e.g., CBARs?). And then the output file is not fully compatible with the MSC tools (MSC Apex, Patran, SimXpert). It's more the subject for another discussion, and we're still investigating, but it seems like even without CBAR issues the pyNastran OP2 can't be imported directly into Patran as geometry+results, you need to import the BDF for geometry and then import the pyNastran OP2 as results only. Whereas my original OP2 files contain all the necessary data (geometry+results) to plot results directly, no BDF file needed.

Regardless, we very much appreciate your work on this tool. It's been very useful for us to automate some of our postprocessing. Thank you!

[SteveDoyle2]

I take that back :/

The following are undocumented options: GGE, BGE, GEG, BEG, GEE, BEE, GGB, BGB, GBG, BBG, GBB, BBB, B

[SteveDoyle2]

Slightly less bad...all E's are the same as O (so GEE=GOO) and B is a shorthand way to write BGG.

[pmoseley]

MSC filed this issue as bugs for both Apex (which generated the BDF) and Nastran (which ran it without giving an error message).

They additionally state:

This is a bug related to IFP start processing. Probably if you could run with NASTRAN IFPSTAR=NO at the top of input file, it would give a proper error. But in your case it is not possible since you are using contacts which need the IFPSTAR=YES.

We do not know as of now which options it chooses when you run with just ‘B”. I guess it could be verified by running with the different options BGG/BGO/BOG/BOO and see which one matches “B”. This will get fixed in coming release to avoid incorrect use of the OFFT value.

I guess that is what you've already done to determine "B" is short for "BGG"?

In any case, I guess it's debatable whether or not it's worth adding support for these "buggy"/undocumented values. Maybe the best is no support, but a more graceful failure (data is ignored?).

[SteveDoyle2]

That's odd. The error message (if you set the value as A or something) is quite clear that B is an option. It just lists all the options. It sounds like that's more documenting what the options are, rather than documenting the correct options and making sure they're all correct.

What I did was simply make a test of all the options in their list and seeing what their f values are (an integer flag in the op2). From that, I created a map, so I can recover if it's say BGG vs. BGO. B and BGG have the same flag, so that's why I guessed that. It's a little more complicated than that though as BGG and GGG have the same flag (as do all other B/G-X-X combinations).

On Wed, May 12, 2021 at 4:56 AM pmoseley @.***> wrote:

MSC filed this issue as bugs for both Apex (which generated the BDF) and Nastran (which ran it without giving an error message).

They additionally state:

This is a bug related to IFP start processing. Probably if you could run with NASTRAN IFPSTAR=NO at the top of input file, it would give a proper error. But in your case it is not possible since you are using contacts which need the IFPSTAR=YES.

We do not know as of now which options it chooses when you run with just ‘B”. I guess it could be verified by running with the different options BGG/BGO/BOG/BOO and see which one matches “B”. This will get fixed in coming release to avoid incorrect use of the OFFT value.

I guess that is what you've already done to determine "B" is short for "BGG"?

In any case, I guess it's debatable whether or not it's worth adding support for these "buggy"/undocumented values. Maybe the best is no support, but a more graceful failure (data is ignored?).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SteveDoyle2/pyNastran/issues/645#issuecomment-839711396, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAICUWKHVL7LKDSEADVBBOTTNJUHFANCNFSM43U3ZQDA .

[SteveDoyle2]

That stuff's been pushed and I think it's fixed as much as it can be....