Ccx 18. Beam under compresion Static 3D

disla

Hi,

I'have observed weird results on a beam under compression.
When calculating with the internal solver everything is smooth and the beam behaves as expected.
When using calculix_2.18\ccx_dynamic.exe both pardiso and PAstix gives weird results.
¿May i have some missing dll. Does it happen to someone else?.





Thanks

disla

Edited.

I have also posted in the ccx forum as it clearly seems a ccx issue.

Victor

Element properties -> Truss is set so they're not really beams.

However, CCX beams do have a bunch of problems. From the Mecway manual:

"The CCX solver (2.17) has some bugs with beam elements. Non-zero displacement constraints on beams can cause incorrect stress, and constrained rotational DOFs can cause incorrect external force. Mecway will show a warning in the outline tree if the conditions for these bugs are met."

disla

Thanks Victor,

prop_design

i can confirm what you are seeing in the file and what victor is saying seems to be true. if you turn off truss the results are better. however, the beam starts rotating instead of compressing. so it seems the ccx expansion is the problem here. the load at one node isn't getting applied to the expanded nodes correctly. that would be my guess at least.

looking at the results more, though, shows the fixed bc isn't applied right either. one end of the expanded elements is free to rotate. it doesn't look like any bc was applied to some of the nodes. even weirder is animating the results. then it looks like the fixed displacement was moved to the middle and the ends were free to rotate. however, there are no nodes at the middle. so this is really weird. it still makes you wonder what it did to the force load. seems like a lot of issues with the shell expansion and bc application.

ps; tested with version ccx 2.18. also, it's odd how the pardiso and pastix results are different in this case. they seem to be different whether truss is on or not. i attached your file with slight changes for debugging. mecway solver has the same result whether truss is on or not. also, the mecway result also seems to make sense, for the load applied.

note; i'm not sure if the elements were expanded to shells or solids. i said shell above, thinking of taking beams to shells. however, ccx might have went from beams to solids. i didn't see a way of checking what the final elements were.

prop_design

so it gets even weirder, if i apply the suggestion from the ccx forum. they say use a truss element with just two nodes. that seems much better. however, the pardiso result seems more accurate than the pastix result. if you use beam elements, there are still problems with pardiso and pastix results. as with before, the mecway result seems fine. attached are the files, from one of my previous posts, with the ccx forum recommendation.

update; if you use a beam element and change your constraint to a fixed bc, then all the solvers get close to the same result. that may be the way to go here.

cwharpe

I agree with the more rigorous application of the constraints. Back in the day with NASTRAN entry software we used as students, you couldn't solve the flagpole-in-compression scenario without first 1) fixing the base rotations or 2) guiding the free-end.

That said, it's a curiosity the internal solver produces the same results with only 3-displacements constrained that CCX does with a fully fixed base.

Confirm the two-node truss elements also. Any further resolution between endpoints yields weird graphical zig-zags, although the reaction forces remain correct.

disla

Thanks prop_design and cwharpe,

I have also receive response from the Calculix forum.

"above example are for truss element, so it does not required mesh to be refined. only use one element mesh betwen each joint of connected members. Spliting and refining mesh may cause stability problem and spurious movement since each element end nodes become hinged".

That's in line with the Mecway Manual that says truss do not have bending (each node only has translational degrees of freedom) . By refining I was doing things worst.

By other hand. I have build and refine a truss with a mass at the end expecting it to behave as a pendulumm (chain) but it fails. Also changing the force direction on the previous file aslo fails so it should not be exactly a hinged connection.

Victor

You shouldn't have any unconstrained degrees of freedom in static analysis. So no pendulums or chains. Either use dynamic response for that or nonlinear static and lower it into equilibrium position in a quasi-static manner such as by constraining it with weak springs and ramping up the strength of gravity.