OP2 crash with superelement

[AlejandroStewart]

Hello Steve, I have been trying to extract some data from and OP2 with superelements and I am facing some trouble. Apparently pynastran extracts the data for the first superelement but when the table with the content for the second comes, it crashes.

I have prepared a toy problem replicating the issue.

test_part_SE.zip

I am using latest version on github.

[SteveDoyle2]

Looks like the OP2 wasn't closed properly for whatever reason.

If you throw the post=-4 flag, it'll work.

from pyNastran.op2.op2_geom import OP2Geom
from pyNastran.op2.op2 import OP2
this_op2 = OP2(debug_file='f.txt')
this_op2.post = -4
this_op2.read_op2('big_se.op2')

geom = OP2Geom(make_geom=True, debug=False, log=None, debug_file=None, mode='msc')
geom.post = -4
geom.read_op2('big_se.op2')

[AlejandroStewart]

THANKS X 1000

[AlejandroStewart]

Arj, celebrated too soon, when you do this, you miss a whole superlement with post=-2 (but crashes)

with post=-4 (no superlement :( )

[SteveDoyle2]

Well that's really weird...

I ran the model using MSC 2005 and got 2 superelements in the OP2. I don't think it's a bug on my end. I'd go bug MSC.

[SteveDoyle2]

big_se_msc_2005.zip

[AlejandroStewart]

Thank you!

[SteveDoyle2]

Any idea why the other file didn't work?

[AlejandroStewart]

To be honest I have been very busy and haven't had time to play with it. If I find some time next week I'll do the test with various nastran versions and I'll let you know the outcome.

El vie., 3 abr. 2020 21:40, Steven Doyle notifications@github.com escribió:

Any idea why the other file didn't work?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/SteveDoyle2/pyNastran/issues/595#issuecomment-608623494, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADK2WF3CV6W3H7JYFAAXJELRKY3TDANCNFSM4LNPHODQ .

[AlejandroStewart]

I have finally run some test, interesting results: For versions 2005 (you tested that one), 2008,2012,2013 and 2019 1) 2005 and 2008 work fine 2) Results in f06 are the same and OK for all versions test_part_SE_nast_versions.zip

3) I see this table written after each disp table in th f06 in 2008 but no int 2012,2013 nor 2019

USER INFORMATION MESSAGE 4114 (OUTPX2)
     DATA BLOCK BOUGV1   WRITTEN ON FORTRAN UNI

before results for super=0 end of super = 0 results: end of super =2 results

4) Some data must be missing as the size of the op2 differs according to point 1

[SteveDoyle2]

It looks like you did a try-except and suppressed the error in 2012 and

2013. The 2008 and 2019 decks work fine.

Is it possible your DMAP call is wrong?

On Wed, May 27, 2020 at 4:46 PM Alejandro Stewart notifications@github.com wrote:

I have finally run some test, interesting results: For versions 2005 (you tested that one), 2008,2012,2013 and 2019

1.

2005 and 2008 work fine 2.

Results in f06 are the same and OK for all versions test_part_SE_nast_versions.zip https://github.com/SteveDoyle2/pyNastran/files/4692411/test_part_SE_nast_versions.zip 3.

I see this table written after each disp table in th f06 in 2008 but no int 2012,2013 nor 2019

USER INFORMATION MESSAGE 4114 (OUTPX2) DATA BLOCK BOUGV1 WRITTEN ON FORTRAN UNI

1. Some data must be missing as the size of the op2 differs according to point 1 [image: image] https://user-images.githubusercontent.com/14002967/83082854-e832ec00-a084-11ea-9462-279b355a2b2b.png

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/SteveDoyle2/pyNastran/issues/595#issuecomment-635002682, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAICUWPEZKRRQGOXHPJI56DRTWQ55ANCNFSM4LNPHODQ .

[AlejandroStewart]

No dmap here. 2019 may not crash but when looking at displacements, there is only a set of results, corresponding to super =0 The try statement was there to make sure I looped all the op2's

I am starting to think that I haven't asked properly for the results to be reported but it is weird (again nastran) that it worked in the older versions.

[AlejandroStewart]

OK, so I finally caught it, the thing is that you have to define the PARAMs for each superelement. for some reason 2005 and 2008 managed to propagate the params through all the superelements, but it didn´t work fo the newer versions. The solution was to define param,post,-2 at each bulk.

nastran tip of the day

[SteveDoyle2]

Oh that's is nonsense. You think you've figured it out...

Would you mind making a writeup on superelements and basically things I need to add? You seem to be pretty good at them.

I have a few examples in pyNastran\models\superelements. Those examples all work in the geometry better than Patran 2005 (they work in the GUI), so I thought I had it mostly right. I'm learning new things from you such as:

• you can define the same BDF twice
• duplicate PARAMs
• no nodes in the 0 superelement is allowed

Other things that confuse me about superlements:

• scoping on loads is weird (you can reference nodes in a superelement from superelement 0)
• can materials/properties span superlements (e.g., can the material from superelement 1 be used on superelement 0?)
• I have no idea how to use the SEID field on the GRID card

Maybe it's also that you don't have a main model and that's what's tripping me up.

I also started working on cleaning up skipping of cards to make sure the n value is computed correctly. I've found a few other examples of cards that were dropped.

Steve

On Thu, May 28, 2020 at 1:32 PM Alejandro Stewart notifications@github.com wrote:

OK, so I finally caught it, the thing is that you have to define the PARAMs for each superelement. for some reason 2005 and 2008 managed to propagate the params through all the superelements, but it didn´t work fo the newer versions. The solution was to define param,post,-2 at each bulk.

[image: image] https://user-images.githubusercontent.com/14002967/83190551-e1fb4900-a132-11ea-97bd-360c62a7b89f.png nastran tip of the day

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/SteveDoyle2/pyNastran/issues/595#issuecomment-635591136, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAICUWPDXG5CT4SWF36AU5LRT3C4LANCNFSM4LNPHODQ .

[AlejandroStewart]

Well, Nastran superelements (SE) is a science on its own. To begin with the fact that there are 3 types of them, depending on how you define them. Mi experience is basically with external SE AKA condensed models. You basically tell nastran that you want to focus on a certain area of the structure (lets say fuselage to wing root connection), but keep the effect of the rest. What nastran does is that it crops the matrices at the interfaces with your interest area and reduces the remaining structure to a stiffness/mass/load matrix, making it faster to iterate. It comes with a million options, you can even keep the necesary information in order to see what is happening in the structure you reduced. Usually, you focus on super =0 (residual structure), and thus you don´t have information in the op2 for other SE. Mainly because you normally don't care for it, only want it's stifness there.

This toy problem uses PART SE, wich in practice are similar to List SE. In this case I was trying to apply some kind of symmetry, as if you define a slice of pizza and call it six times but each time the reference frame is rotated. Nastran takes care for the sewing of the slices, and computation wise it is a whole pizza, but you get each slice in a SE. As mentioned before, each slice can have it's own PARAM,loads,etc. What is defined in a SE stays within the SE. and that includes param post....:

Other things that confuse me about superlements:

• scoping on loads is weird (you can reference nodes in a superelement from superelement 0)
• can materials/properties span superlements (e.g., can the material from superelement 1 be used on superelement 0?)
• I have no idea how to use the SEID field on the GRID card

And after that introduction, the anwser is :----> it deppends on the kind of SE

• scoping on loads is weird (you can reference nodes in a superelement from superelement 0)

Yes in List superelements, indeed, you cannot have repeted entities.

• can materials/properties span superlements (e.g., can the material from superelement 1 be used on superelement 0?)

That one in External and Part SE, 100% no, and in list you have to think of it as a normal model that is later cutted, so everything is available.

• I have no idea how to use the SEID field on the GRID card

I have never used it to be honest, but from whatI have read, you can use it to define de SE your node belongs to for a LIST SE.

Maybe it's also that you don't have a main model and that's what's tripping me up.

I think you reffer to super=0, indeed there is, the first call to the include fiele is for the residual structure.

My conclusion here is that Pynastran works fine for PART SE op2 results ( the one in the example). Retrieving geometry from op2 returns only the residual (super=0). But I think it is on MSC roof, as I see no reference to which SE grids belong in BGPDT table.

For List and External SE I will have to test. List type should be easy. I´ll have a look at the examples you have and let you know.

PS: It is awesome being able to access such crazy data format. THANKS! PS1: I gave up on Patran, using Hypermesh. Not going back. ever.

[SteveDoyle2]

Oh that's going to take a while to process. I didn't realize there were 3 types...I thought it was just 1...

I'm working on trying to fix quite a few bugs in the op2 geometry reading associated with miscounting. I just found out that there are actually two different GRID tables. One is the standard 8 fields. Another is in the GEOM1N table and isn't documented in the DMAP guide. It seems to have 11 fields and doesn't follow a clear pattern. Oh Nastran, don't ever change...

On Thu, May 28, 2020 at 3:20 PM Alejandro Stewart notifications@github.com wrote:

Well, Nastran superelements (SE) is a science on its own. To begin with the fact that there are 3 types of them, depending on how you define them. Mi experience is basically with external SE AKA condensed models. You basically tell nastran that you want to focus on a certain area of the structure (lets say fuselage to wing root connection), but keep the effect of the rest. What nastran does is that it crops the matrices at the interfaces with your interest area and reduces the remaining structure to a stiffness/mass/load matrix, making it faster to iterate. It comes with a million options, you can even keep the necesary information in order to see what is happening in the structure you reduced. Usually, you focus on super =0 (residual structure), and thus you don´t have information in the op2 for other SE. Mainly because you normally don't care for it, only want it's stifness there.

This toy problem uses PART SE, wich in practice are similar to List SE. In this case I was trying to apply some kind of symmetry, as if you define a slice of pizza and call it six times but each time the reference frame is rotated. Nastran takes care for the sewing of the slices, and computation wise it is a whole pizza, but you get each slice in a SE. As mentioned before, each slice can have it's own PARAM,loads,etc. What is defined in a SE stays within the SE. and that includes param post....:

[image: image] https://user-images.githubusercontent.com/14002967/83196205-c5174380-a13b-11ea-8182-8bf7376e2d3f.png

Other things that confuse me about superlements:

• scoping on loads is weird (you can reference nodes in a superelement from superelement 0)
• can materials/properties span superlements (e.g., can the material from superelement 1 be used on superelement 0?)
• I have no idea how to use the SEID field on the GRID card

And after that introduction, the anwser is :----> it deppends on the kind of SE

• scoping on loads is weird (you can reference nodes in a superelement from superelement 0)

Yes in List superelements, indeed, you cannot have repeted entities.

• can materials/properties span superlements (e.g., can the material from superelement 1 be used on superelement 0?)

That one in External and Part SE, 100% no, and in list you have to think of it as a normal model that is later cutted, so everything is available.

• I have no idea how to use the SEID field on the GRID card

I have never used it to be honest, but from whatI have read, you can use it to define de SE your node belongs to for a LIST SE.

Maybe it's also that you don't have a main model and that's what's tripping me up.

I think you reffer to super=0, indeed there is, the first call to the include fiele is for the residual structure.

My conclusion here is that Pynastran works fine for PART SE op2 results ( the one in the example). Retrieving geometry from op2 returns only the residual (super=0). But I think it is on MSC roof, as I see no reference to which SE grids belong in BGPDT table.

For List and External SE I will have to test. List type should be easy. I´ll have a look at the examples you have and let you know.

PS: It is awesome being able to access such crazy data format. THANKS!

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/SteveDoyle2/pyNastran/issues/595#issuecomment-635638934, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAICUWMUJ2HU2H6MRHVIQCDRT3PTLANCNFSM4LNPHODQ .

[AlejandroStewart]

Maybe this helps undestanding the nature of the table:

---

Regarding superelements, I have tried the three types so far and it works like a charm :). A least nastran is consistent here!

[SteveDoyle2]

Glad the supers works :)

I saw that GEOM1N note. It's not particularly helpful. I'd probably have to dig into DMAP to check or just say I think what I have now is probably right.

It looks like they converted the xyz to double precision for nonlinear, but left the others the same...I guess that makes sense. I don't know how you're supposed to know that.

On Fri, May 29, 2020 at 9:00 AM Alejandro Stewart notifications@github.com wrote:

Maybe this helps:

[image: image] https://user-images.githubusercontent.com/14002967/83279499-7a4a0a00-a1d5-11ea-9614-3089c4bb0409.png

[image: image] https://user-images.githubusercontent.com/14002967/83279472-70280b80-a1d5-11ea-8df2-2befdee2f8e6.png

[image: image] https://user-images.githubusercontent.com/14002967/83279348-48d13e80-a1d5-11ea-9b75-8cc85994727c.png

Regarding superelements, I have tried the three types so far and it works like a charm :). A least nastran is consistent here!

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/SteveDoyle2/pyNastran/issues/595#issuecomment-636052013, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAICUWPGYBSEOBHBBDLEEQ3RT7L2DANCNFSM4LNPHODQ .