Shell [coque_3D] parts joined via tied contacts crashes (?)

Sound_Spinning

jeanpierreaubry
All good for now, I'll keep digesting / investigating.

No probs with an FEA solver logic being different, and it is open source, which I am forever grateful!
The concept of reactions is not preconceived, not FEA either, hand calcs on rigid body diagrams I'm talking about.
I'll keep digging tho.

Sound_Spinning

jeanpierreaubry
I've now modelled NAFEMS shells benchmark LE3, 1/8 of a sphere. It looks good except the mystery of the RBRots modes with DKT. See how COQUE_3D gets closer to the target vs DKT, and don't have the issue in modal.
High-order shells are better for curvature, hence I wanted to use them 1st, but they have a bug with tied contacts on the mid-face node.
This is all solved in V16.5.
Do you know where I can find release notes on new releases, and check if the coque_3D bug with tied contacts may have been fixed in new releases?

Files for the 3 models above here: code_aster_NAFEMS_LE3.zip

AsterO'dactyle

Hello,

The COQUE_3D element is not isoparametric.

On all nodes except the vertex node: DX, DY, DZ, DRX, DRY, DRZ.
On vertex node: DRZ only

I don't understand the bug you seem to find in COQUE_3D. But I remember a recent fix on the subject.

You can find the release notes here:
https://gitlab.com/codeaster/changelog

Sound_Spinning

AsterO'dactyle
Hi there, thanks for the link.
The (possible) bug is in my 1st post in this thread. COQUE_3D with tied contacts (LIAISON_MAIL) causes a crash, see fig below. That NS node is created by code_aster, as it needs a mid-face one for shells (coque_3D) to work; hence the question, it shouldn't crash with the tied contact (?).

Solved in V16.5. Here are the files for this tiny test model: tied_shells.zip

AsterO'dactyle

Hello,

This test is a classic and is found in all publications on shells and plates.
So much so that it already exists in aster 😉

https://codeaster.gitlab.io/doc/docaster/manuals/man_v/v3/v3.03.105/index.html

Sound_Spinning

AsterO'dactyle
Yes, nice, ref NAFEMS benchmark being in the tests.
The mystery is in 'red' in my fig. with results above for the modal with no constraints (a classic quick test). It should always give 6 0Hz rigid body modes, but DKT shells doesn't for modes 4 --> 6 (rotational ones); wouold you know why, it feels like an over-constrain somewhere?

Sound_Spinning

Sound_Spinning
Update:
I found an old thread that also shows DKT shells not getting the rigid body modes at near 0Hz on a free-free modal:
https://forum.code-aster.org/public/d/14253-resolu-frequences-non-nulles-pour-modes-de-corps-rigides-en-rotation

Sound_Spinning

The original issue in this thread: coque_3D & tied contact crash, was addressed long ago in this thread_1 & this thread_2.

One needs to make a copy of the shell elems used in the tied contact before they are converted onto tria7 & quad9; odd.... Here is the fixed model that now solves: fixed_tied_shells.zip

But now, I am confronted with another issue in Paraview as shown below, new mid-shell nodes have disps=zero, as they only handle rots DoF. I tried the fix in PV posted in forum, shown in inset in fig: make that number zero; still no good. How do you plot displaced shapes on a complete assy with shells correctly, any other thoughts?
I assume maybe an interpolation may be needed, does anyone have a working example with an assy and some coque_3D shells working in PV? Thanks.

jonasloenartz

Hi, yes, the problem is, that there are no displacements in the center nodes, only rotations as you have noticed. The way I usually do this, is using the command PROJ_CHAM() to project the displacement-field onto a linear mesh and and then output that as a result. There are multiple steps needed. I hope the .comm file is well structured and you find your way through. It contains a lot of if-else statements to handle both linear and quadratic meshes.

example.bin

23kB

Jonas

Sound_Spinning

jonasloenartz
Nice, I'll give it a shot soon; thanks!

Sound_Spinning

jonasloenartz
Hi again, your deck is very neat and clear to me, learnt a couple of tricks, thanks for sharing!

Since PROJ_CHAMP goes back to using specific elem sets, as discussed in another thread recently, it breaks assemblies in PV; i.e. the nodes involved in couplings (_rbe2, _rbe3), springs, point-masses and/or equations do not appear anymore in the displaced shape.
This is my test model that looks cleaner in PV, with your approach to coque_3D mid-face nodes --> linear mesh: PV_fixed_tied_shells.zip

So, this is the best I got from the last 2 model versions:

I guess you get around these issues by using HyperView (?): one complete mesh with either nodal or elem results where applicable, and it all works on a displaced shape.

On shells I have a question, for VMIS (absolute), does it really matter the top or bottom shell layer, i.e. no need to have results for all 3? VMIS should be the same top vs bottom, unless we have composites and/or a temperature gradient along the thickness? Am asking, not sure I can think of a usual case where I need all results for the 3 layers (shell section points).

Cheers,
Jesus

jonasloenartz

Sound_Spinning No! It absolutely does matter. In very simple cases like a cantilever beam modelled with shells under bending stress this might be true, and the von Mises stresses on top and bottom layers are the same (just as they would be with a solid-model). But if you for example add additional tension or compression in longitudinal direction, stresses will differ between top and bottom layer. Looking at 3 layers might be unneccessary though, because either top or bottom layer von Mises stresses will be higher than the mid-layer. So comparing those two should be enough (at least I can't think of a scenario, where that's NOT the case).

Here is an example with Z1/Z2 being bottom and top layers. The part shown is part of a rectangular tube under bending stress, modelled with shells:

Hyperview can't deal with bi-quadratic elements at all. I treat these elements as their 2nd-order alternative and do not export the results on center nodes (when coverting the result-files).

Sound_Spinning

jonasloenartz
Ah, good pic, brain failure on my behave, of course it matters, thanks for clearing that out!

« Previous Page