Buckling with Inertia Relief

[Senophoe]

I know this question has been asked a few times. I'm sure I checked almost every answer avaiable around. But I'm still having trouble using SOL 105 buckling with inertial relief.

Here's the .nas/.dat Nastran file: https://drive.google.com/file/d/1RrH_hMMeLpE3qEWH_Ea3nuVQBoBBindj/view?usp=drivesdk

Here's the error I'm having in the buckling set, from the f06 file:



I have INREL set to -1 in the Bulk Data:


I also have SUPORT1 defined in the Bulk Data:


And finally I'm running a STATIC SUBCASE with SUPORT1 and then calling it via STATSUB in another SUBCASE for buckling.



What am I doing wrong?

Photos of the setup.

The model is a LAMINATE composite tube with two RBE3, each with a load in the center node. I put the SUPORT1 constraint in a random node restricting 123456 dofs, just for test.

 

[sdm919]

Just a guess: Does your SUPORT1 node have the ability to take moments? The 456 on the support card basically require that point to have that ability.

Does your model have solid elements? Is the SUPORT1 node attached to only solid elements? That might be the problem. Solid elements cannot take concentrated moments., and you cannot support a rigid body about a point that cannot take moments.

I believe the SUPORT card allows you to apply rigid body restraints at different nodes, for example: restrain DOF=123 at one node, DOF=23 at another, and DOF=3 at a third (not all one a line). Then those 6 translational restraints serve to provide rigid body support in all 6 DOFs.

 

[Senophoe]

Just a guess: Does your SUPORT1 node have the ability to take moments? The 456 on the support card basically require that point to have that ability.

I uploaded the .nas/.dat file below. The model is a hollow cylinder. The skin is meshed with LAMINATE elements. I suppose those are capable of taking moments.

I put the SUPORT1 in one node in the skin. I did that just for testing.

Here's the .nas/.dat file with the model and complete analysis setup. Would you kindly help me out figuring out my mistake?

250703_INREL_18.nas

drive.google.com

Does your model have solid elements? Is the SUPORT1 node attached to only solid elements? That might be the problem. Solid elements cannot take concentrated moments., and you cannot support a rigid body about a point that cannot take moments.

I didn't use solid elements. The SUPORT1 node is a single nodal point in the cylinder skin. The structure is a hollow cylinder meshed with LAMINATE elements.

I believe the SUPORT card allows you to apply rigid body restraints at different nodes, for example: restrain DOF=123 at one node, DOF=23 at another, and DOF=3 at a third (not all one a line). Then those 6 translational restraints serve to provide rigid body support in all 6 DOFs.

I'll read Nastran documentation on how to do that using SUPORT1 card tomorrow. It's late night here now.
I suppose I'm allowed to have a single SUPORT1 entry in the Case Control section, which refers to a single SUPORT1 in the Bulk Data section. So I'm guessing I can simply modify my Constraint used as SUPORT1 to have different constraints at three different nodes.

 

[sdm919]

Sorry I don't have the software to look at the model, I can only read the text file. So I am still "only guessing".

If possible, the idea of supporting the model at only translational DOFs at 3 distinct points might work. Note that SUPORT and SUPORT1 are different cards.

My first question should have been: have you checked the model with a simple linear static run? This will ensure there are no other issues before attempting the INREL run. Set up a simple load/BC case and make sure it runs and the deflections and other results look reasonable.

I see you have no solid elements, so my initial guess there was wrong. But CQUAD4 elements cannot take twisting moments normal to the element surface. [Example: If you had a flat plate modeled in the x-y plane, these elements cannot take Mz.] For your cylinder, these elements cannot take moments about the outward normals to the cylindrical surface (might be your global y or z axis or a combination depending on where around the perimeter the point is). If you decide to pursue this, you could add a ring of CBAR elements around the circumference at the location where you currently have your SUPORT1. Since your thickness appears to be 2.4, you could make the bar a square cross-section of dimensions 2.4x2.4. This would add rotational stiffness that the shells do not have - perhaps enough to get the model to run but not enough to seriously affect the results.

But the previous suggestion of supporting 3 nodes translationally is probably the best bet if you can get that to work (and your simple static runs shows no other issues).

If nothing works, another option might be to apply the inertia loads directly rather than using INREL to compute them. From the mass of your model and the known applied loads, you could back out the accelerations and apply them using GRAV and/or RFORCE cards.

 

[Senophoe]

@sdm919 Thank you for your willingness to help.

Note that SUPORT and SUPORT1 are different cards.

The reason I'm using SUPORT1 is because MSC Nastran documentation mentions it's mandatory to use it for buckling with inertia relief, instead of SUPORT.

My first question should have been: have you checked the model with a simple linear static run? This will ensure there are no other issues before attempting the INREL run. Set up a simple load/BC case and make sure it runs and the deflections and other results look reasonable.

I ran 4 different conditions:
-Model runs fine in the constrained linear static solution (number 1 listed below)
-Got a fatal error in run number 2, which is linear static solution with inertia relief, constrained as mentioned in the previous post (one node with 123, another one with 23, and last one with 3)
-Third run is the same as run number 2, except I changed the SUPORT1 constraint. It runs fine.
-Fourth run is the same as third run, except I added the buckling subcase, which calls the third run results using STATSUB.

Run number 1: Using linear static analysis SOL 101. Cylindrical shell completely fixed at the bottom. The constraint is applied directly at the nodes of the cylindrical surface. The white squares are the RBE3 legs I'm using to apply an axial load at the center. There's another load at the top pointing towards +Y which causes bending of the structure.

Constraint

Load at the top


Run number 2: Also linear static analysis SOL 101 like run number 1, but using manual inertia relief INREL -1. Instead of running as default, I set up a subcase in the Case Control section. The subcase calls SUPORT1 = 77 (I put a picture of the .nas file below in the Run number 3 part).

Constraint 77, which is used as SUPORT1: one node is 123, second node is 23 (this node is in line with +Z), and third node is 3 (this node is aligned with +Y). For some reason this gave me the exact same fatal error 9050.



Run number 3: Exact same condition as run number 2, except I changed the SUPORT1 constraint as shown below. Doing this solved the fatal error. But I'm still trying to figure out why.

Constraint used as SUPORT1 has one node with 12 (in line with+Z), one node with 13 (in line with +Y), and another node with 23 (rotated 45 degrees from the main axis).

Laminate failure index contour:

Picture of the .nas file showing SUPORT1 in the subcase. INREL and SUPORT1 are defined in the Bulk Data.


Run number 4: Using the exact same configuration as run number 3, I tried running buckling SOL 105. The only thing I did was include a new SUBCASE, which calls for the results of the linear static run using STATSUB. But despite the linear static case running perfectly fine, when I include the buckling subcase I get the fatal error again.

I see you have no solid elements, so my initial guess there was wrong. But CQUAD4 elements cannot take twisting moments normal to the element surface. [Example: If you had a flat plate modeled in the x-y plane, these elements cannot take Mz.] For your cylinder, these elements cannot take moments about the outward normals to the cylindrical surface (might be your global y or z axis or a combination depending on where around the perimeter the point is). If you decide to pursue this, you could add a ring of CBAR elements around the circumference at the location where you currently have your SUPORT1. Since your thickness appears to be 2.4, you could make the bar a square cross-section of dimensions 2.4x2.4. This would add rotational stiffness that the shells do not have - perhaps enough to get the model to run but not enough to seriously affect the results.

But the previous suggestion of supporting 3 nodes translationally is probably the best bet if you can get that to work (and your simple static runs shows no other issues).

Considering run number 3 worked above, the way I'm understanding the problem is inertia relief works fine with the SUPORT1 constraint used. Linear static SOL101 works fine and because of that I'm making an assumption inertia relief is working fine. The CBAR element around the circunference solution is interesting and I'll try it as soon as I can. But considering run number 3 worked, it's not necessary to use the CBAR. Do you agree?

For some reason buckling SOL 105 crashes with Fatal Message 9050 even if the linear static subcase with inertia relief is working fine. I'm wondering if there's anything different that should be done with SUPORT1 for the buckling subcase to work. But I don't thin that makes a lot of sense, since the way I undertand Nastran, because I'm using STATSUB, the buckling subcase is only using the results from the linear static subcase, which ran perfectly fine.

Do you have any idea what could be happening here?

If nothing works, another option might be to apply the inertia loads directly rather than using INREL to compute them. From the mass of your model and the known applied loads, you could back out the accelerations and apply them using GRAV and/or RFORCE cards.

I agree this could be done. But consider the cylinder shell structure is a rocket, which is actually what I'm trying to simulate... I'm wondering how to constraint the structure to simulate flight condition. Inertia relief seems to be the right way to do so. Maybe constraining at the CG could be another option.

 

[sdm919]

Glad to hear your static runs with inertia relief are running. I am not sure why the buckling run does not work. I can only suggest more tests.

As you found, the test case with a ring of CBARs is not necessary for the static run, but it still might be a worthwhile test to see if it helps the buckling run. Yes, the buckling run is getting the loads from the static SUBCASE, but it is still dealing with the system stiffness matrix and that is apparently where something is going wrong.

I wonder if is the RBE3s. As another test, you could try replacing the RBE3s with multiple CBARs from the center point to the perimeter. Or just get rid of the "wagon wheels" totally. Your nodes are nicely spaced, so you could simply distribute the concentrated FORCEs evenly to the perimeter nodes yourself.

Regarding applying the inertia loads yourself: in this case you would replace the SUPORT card(s) with SPC cards to support the model. The assumption is that the applied loads are exactly in balance with the inertia loads, so the resultant is zero. Then you support the model in a statically determinant manner using SPC cards (again, 6 translational DOFs spread among 3 nodes). Then do a static run (without INREL). You should verify that the reactions at the SPCs are zero. Choosing different SPC points only changes the displacements. It is relative, not absolute, displacements that cause stresses/strains. The stresses/strains will be the same even if you choose different SPC points (as long as they make a statically determinate set). This is a common way to run free body models. Try on a simple model to convince yourself.

One more alternative comes to mind. It is cumbersome but doable. Separate your analysis process into 2 separate runs (not 2 SUBCASEs within a single run). Here are the steps: (1) run inertia relief, print or punch the OLOAD vector (which will contain all the applied loads, both external and the inertia loads at nodes as computed by Nastran). (2) read the OLOAD vector (either from the f06 file of the PUNCH file) and reformat them into FORCE and MOMENT cards. (3) run a static run with those FORCE/MOMENT cards (which should be balanced due to coming out of inertia relief) with the model supported statically determinately as described in the previous paragraph. I have done this quite a bit and wrote a Fortran program to automate it.

After that, I'm running out of ideas!