Arbitrary displacements in beam elements

disla

Hi,

I need some help from you.

I’m working on that known issue related with wrong stresses on beams elements when imposing displacements.
I‘ have found a way to set up the model which in my opinion is the solution but I would like your opinion.

I have prepared a rectangular beam 0.1m x0.1m x 1m oriented in the Global Coordinate System in direction (1,1,1).
The origin (node 1 ) is fixed, and a displacement of 1mm in direction (1,1,1)is applied to node 2 located….. at coordinate (1,1,1).
Pure stretching.

Expected result:

displacement X = 0.5773mm (This is 1mm/sqrt(3))
displacement Y = 0.5773mm (This is 1mm/sqrt(3))
displacement Z = 0.5773mm (This is 1mm/sqrt(3))
displacement magnitude = 1mm

I’m focusing on Linear Static now. Internal and ccx solver.
Mecway shows the red warning to the user regarding possible issues, but It’s ok to me, … I push the run button.

Ccx and the internal solver shows a deviation of the beam from its main axis during the displacement .
There is also a discrepancy in the displacement magnitude and on each direction.

Digging into the inp seems that MECWAY translates the *BOUNDARY and *TRANSFORM cards into a way I can’t fully understand so I have decided to rewrite them with custom cards.

I have attached the files with to different approaches that give in my opinion the expected results.
Each file can be run with the standard BC prepared by MECWAY or…. by suppressing the “SUPPRESS_FOR_CUSTOM” and UNSUPPRESING the custom cards one can see my proposal and run it. It is convenient to keep OUTUP2D.

OPTION 1. (file Arbitrary Displacement on a Node.liml )

Do not apply *TRANSFORM to the beam and apply the displacement directly in the Standard Cartesian coordinate system as:

*BOUNDARY

2,1,,0.0005773502691318907
2,2,,0.0005773502691318907
2,3,,0.0005773502691318907

OPTION 2. (File Arbitrary Displacement on a Node with Transform .liml)

a-*TRANSFORM the coordinate system but TYPE=C (cylindrical) with z aligned with the beam. Seems more natural to me for beams.
b-*TRANSFORM (this should be done internally) the displacement vector from Cartesian to Cylindrical. In this case (1,1,1) - (0,0,1) for this particular beam orientation .
c-Apply the BOUNDARY known that now the first component is R, the second theta and the third is Z.

*TRANSFORM,NSET=T1,TYPE=C
0.,0.,0.,1.,1.,1. (to define a TYPE=C in abeam is just writing the node coordinates)

*BOUNDARY

2,1,,0
2,2,,0
2,3,,0.001

@Victor and for all those users who are more experienced with ccx custom cards I would really like to know your opinion.
I’m convinced that solving arbitrary displacements on beams will open the door to substantial improvements.

disla

HI,

This is OPTION 3 using the rectangular coordinate sistem (as MECWAY likes) that seems to work too.

I’m using a *TRANSFORM TYPE=R (rectangular) custom made and built directly from the beam direction. For direction (1,1,1) it is (-1,1,0)

I would say for some reason the V axis defined previously in *BEAM SECTION is interfering with the new Local coordinate system.
That’s why the beam deviates.

(-0.707106781187,0.707106781186,0) doesn’t work.

@Victor ¿could you please check why if I eliminate the Orientation card in the three my custom model fails.?.It is Supressed.
¿Does MECWAY send to ccx the same file we see in the generated inp?

By other hand I do not have clear why the *BOUNDARY card doesn’t work when I apply the displacement to the new local direction 1. It is supposed to be aligned with the beam.

*BOUNDARY

2,1,,0
2,2,,0.001 Works
2,3,,0


*BOUNDARY

2,1,, 0.001 Fails
2,2,,0
2,3,,0

I think we are close.

Regards

disla

Hi,

The Coordinate system shown in Figure 153 has been removed from the ccx Manual 2.20. I think it is not said but the vector from beam to b point must be orthogonal to the beam and pass through the point a. I have tried other combinations that respect that criterion and also work.

MECWAY INP

*TRANSFORM,NSET=T1

0.7071067811865,-0.7071067811865,0,0.5773502691896,0.5773502691896,0.5773502691896 FAIL

CUSTOM

0.5773502691896,- 0.5773502691896,0,0.5773502691896,0.5773502691896,0.5773502691896 OK
0.7071067811865,- 0.7071067811865,0, 0.7071067811865, 0.7071067811865, 0.7071067811865 OK
1,-1,0,1,1,1 OK

Victor

You can do this without any custom CCX cards. I've attached an example to displace the end of the beam 1mm in the longitudinal direction only.

Nonetheless, the following change to your file works for me. It displaces the node in the (-1,1,0) direction:

*BOUNDARY

2,1,,0.001
2,2,,0
2,3,,0

The .inp file it shows is a copy (via the filesystem) of the file sent to CCX so it's identical.

Victor

Oh, I see what you mean now about "if I eliminate the Orientation card in the three my custom model fails". That's because the custom CCX cards refer to an ELSET (element_orientation_elements) that the orientation card creates.

I guess it's surprising that it still creates that ELSET even when it's suppressed, but it wouldn't have any effect when nothing refers to it. If you want to refer to an ELSET using custom CCX cards, it's safer to define it explicitly as a named selection instead of using the automatically generated ones.

disla

Hi, Victor and Thanks for your reply,

Thats ok for 1 Beam but we couldn't solve the attached file as it would over constrain the model.

The most general case is important as it involves dandelions (spiders).

I think my method could solve it correctly. I think I could also solve it with OPTION 2 and 3 too. See file

EDITED: You have additionally contriant rotation of the base wich makes it rigid.

Victor

You can do that here too, but it's easier because there's no transformation. See attachment. It's not over-constrained because each of the 3 displacement constraints only constrains the displacement in one direction. The 3 together fully constrain the node.

disla

I would better like to find the way to impose an arbitrary displacement on beams without having to decompose the vector.
I guess now the question is ¿why it works when it is imposed only in one cartesian coordinate without showing let’s call it free rigid body motion. It may help us to find the solution.

disla

@Victor

"Oh, I see what you mean now about "if I eliminate the Orientation card in the three my custom model fails". That's because the custom CCX cards refer to an ELSET (element_orientation_elements) that the orientation card creates"

The Orientation is Suppressed. It’s like it's not in the game. By “Eliminate” I mean I “Erase” it. ¿Shouldn’t be the same model.?

Victor

Yes, suppressed should be "acts like it's been deleted" but here's a place where it does have some side effect. It's not ideal and perhaps I'll change it but it doesn't affect the solution so I think it's harmless. Only a problem for hacking the CCX file.

I added a rotation constraint because the beam was spinning around its axis and didn't show the 1 mm displacement clearly. You don't need it, especially not with OUTPUT=2D like you have.

Victor

"¿why it works when it is imposed only in one cartesian coordinate without showing let’s call it free rigid body motion"

It's some undefined behavior of the matrix solver when its underconstrained. There are no guarantees about what happens to the unconstrained degrees of freedom. The Spooles solver does cause a lateral displacement of one of the beams but Pardiso doesn't.

Victor

To avoid decomposing the vector, you could use frictionless supports like this. It's not exactly the same since it also adds some rotational constraints though.

disla

Hi,

After a long debate, Victor has helped me to identify the origin of the discrepancy between my results and MECWAY.

It has turned out that the starting hypotheses in the statement of my post was wrong. Precisely the one "displacement of 1mm in direction (1,1,1)is applied" .
I will try to explain which is the right way of reading the MECWAY Displacement Window as some Steel Design Comercial softwares differs substantially on how this is implemented.


WRONG. The displacement is understood as a "Placement". The node is constrained to move along the line defined by the vector a certain distance (displacement).
The displacement direction is prescribed such that displacement in the two orthogonal directions is not allowed.
I have translated this as three *BOUNDARY cards, one for the displacement and two to constrain the orthogonal directions.

*BOUNDARY

2,1,,0
2,2,,0.001
2,3,,0

The Displacement Magnitude result is the same as the Displacement value input in the BC Window.
The direction in which the point moves in the results window is the direction input in the BC window.


MECWAY . The vector defined by the three components in the displacement window define the normal direction of a plane in which the point will be constrained to move. This plane is located at a distance from the point = Displacement.
I personally read it now like a frictionless support on the exposed front face of the beam but with an offset = displacement value.
MECWAY translates this as just one *BOUNDARY card.

*BOUNDARY
2,2,,0.001

The Displacement Magnitude result is not necessary the Displacement value input in the BC Window.
The direction in which the point moves in the results window is not necessary the direction input in the BC window.

Thanks Victor for your support and patience. Let me know if you agree with the explanation.

EDIT: FRICTIONLESS SUPPORT on the exposed face of the beam is not the same. It adds Homogeneous Conditions for rotations outside the STEP block. That changes completely the Mecway behavior.

From MECWAY MANUAL: "On shells and the end faces of beams, frictionless support also constrains node rotation about any of the axes in the plane of the surface."

Victor

That's very clear. Thanks for bringing this up. It took me a while to understand and it's not something I realized was a problem before. Now I see the input box is extremely ambiguous or wrong. I'll see about adding a description of what those X, Y, Z inputs mean.

disla

Thanks Victor,

I’m working on that old problem with pure shells and large rigid body rotations, and I have already identified two issues. The first is related with the shell losing its axis of rotation. That’s fixed and was caused by a wrong understanding from my side of the displacement window. The ROT node was entering into orthogonal directions inducing rotations on the other two axis.
The second one I’m looking to find a workaround to fix it. It’s an exciting challenge. If’ I find the solution I will let you know to implement it.

Regards.

Victor

Sorry about that. There are probably other people who've used it that way unaware too. I appreciate you bring this up.

disla

Confronting ideas politely is always worth. I would like to use the result of this discussion as example to encourage more users to participate in the forum.
The fruits are already beginning to be seen.
Eight revolutions in Total CalculiX Time: 16.647096 sec
Just shells . No beams ,no solids, no ref nodes or root nodes.
I need some days to digest, polish and test on curved shells and other directions.


Tricky level: God.