This is similar to the result I was getting with CalculiX/Abaqus for that initial geometry - around 0.08 mm and 14 MPa.
Based on my proposed numbers my Hoop is in good agreement and small changes in the BC on top and bottom doesn’t change too much the result.
I’m finding that Hoop Stress in the bellow is not symmetric. Internal curve is in tension while external is in compression. I’m pretty sure about this result.
Above model with axisymmetric SEG3 elements analyzed with Code-Aster. Results are similar to the 1/4 section shell model I posted above. Deformed plot is with amplification 1000 and the zoom to the right shows the “boundary effect” at the end. The leftmost plot of Von Mises indicates the maximum is at radius 0.065m or thereabout.on the outer face. A similar plot (not included) plot for the inner face indicates maximum Von Mises of 12.8 MPa around radius 0.095m.
Yeah, but the problem is that my original geometry may not be optimal considering the assumptions of the analytical solution. That’s why I’m now trying with the new one proposed by Disla here.
Btw. good to know Code_Aster has axisymmetric shells like Abaqus (I assume those SEG3 are equivalent elements).
This is my best shot so far in Abaqus when it comes to displacement:
Hoop stress is not ideal, though:
Here’s what it looks like with CalculiX (the same model as in Abaqus including the S8R mesh):
This includes BCs on all rotational DOFs - risky for CalculiX. But without them, the max displacement is 13.77 mm. The max hoop stress doesn’t change apart from better distribution at the top and bottom:
Even with 4-layer composite shell section, the hoop stress is still 123 MPa. I guess it turns out CalculiX’s fake shells are just not suitable for cases like this when accurate stresses are needed.
can this input files provided? it shown large discrepancy compared to Abaqus and probably due to edge restraint assigned to global not local.
Of course: Dropbox
But the stress should be ok far from the BCs. Especially since there’s the same discrepancy even without the rotational BCs.
Code-Aster:
a=0.840m, b=0.040m+t/2, t=0.0003m, n=5
Stretch: 13,1mm, Roark formula: 11,6mm
Figure: Stresses on upper side (i.e. t/2 away from midsurface) as function of longitudinal position of one “wave”. “Wave” shown aligned underneath, rotated so the axis is above.
SEG3 is a linear element with middle node.
my understanding a solid element is the most accurate to modeling since it considers stress in all three directions. Classical beam and shell element actually is faking solids by straight and plane approach, there’s many theories inside i.e thin, thick, flat/straight, curved, taper and semi-solid. CalculiX does converting directly to solid and represent as is without any assumption and approach. Previously shown true shell element can be failed in some condition, e.g Raasch (BMW, 1990) and pre-twisted beam.
when hand calculation or external solver with true shell element show discrepancy with CalculiX fake shell element, it suspected some condition and assumtion did not fullfiled since it’s the most accurate to full solid models.
Thanks. The stresses shown are principal stresses, right ? Btw. too bad there’s no stress linearization in ParaView (only Salome-Meca seems to have it) and it can’t transform the results to cylindrical coordinates without custom formulas in the Calculator filter.
Yeah, my S8R mesh becomes one layer of C3D20R elements. One layer may not be sufficient, but it’s a bit surprising that 4 layers yield the same result. True shells in Abaqus handled it much better than solids in CalculiX.
If the thickness was higher, I would use axial symmetry (like with my original geometry) to have as many elements as possible through the thickness.
Speaking about the Raasch Challenge, here’s how Abaqus handles it:
SC8R are continuum shell elements (with 3D solid shape and only translational DOFs plus they can be stacked, but they are using shell-like formulation).
When comparing with analytical results one must fulfill all the assumptions of the formula. Comparison is not only useful to check the software or elements performance but to check the set-up trustability and even the analyst skills.
One could use the discrepancy between formula and FEA as a criterion to evaluate the trustability of your set up and aconfidence margin for similar models.
In some cases, like this one, the analytical result that is willing to serve as calibration reference contain many approximations and becomes very restrictive on its usability .
Note that when I say “Assumption” I’m not only referring to the BC or geometric parameters. It also extends to how you should read the result s.
When you read things like :
-only the ’ term is retained in form ula…
-neglecting terms in X…
Means the author is neglecting some of the contributions to the over all s tress.
For Example: In the derivation of the formula for the torus, one can read :
![]()
In the bellow formulas, Mtheta is disregarded no matter the Poisson rat io value.
“as far as maximum stresses are concerned, only NTheta and MPhi , are si gnificant”
That means the Direct Stress in the circumferential direction (Hoop Stress) in FEA has a component due to bending moment not foreseen in t he formula.
If you measure the Hoop far from the neutral fiber (Aprox Mid layer of the shell if available) the Hoop Stress value wil l not match.
You could set up Poisson ratio =0 to make things easier. You should get a uniform Hoop no matter on which face you are looking at. For Nu=0 Hoop expected value shou ld be 85 MPa.
By other hand, author only focus on the external curve of the bellow when results is not symmetric.
I wouldn’t follow with the comparison because this is one of those problems in which FEA can contribute providing more accurate results but without an accurate calibra tion reference.
Good point. Keeping in mind this:
If OUTPUT=2D the fields in the expanded elements are averaged to obtain the values in the nodes of the original 1d and 2d elements. In particular, averaging removes the bending stresses in beams and shells.
I’ve tried with OUTPUT=2D and the hoop stress is much closer:
I just can’t get the meridional bending component and von Mises stress from both of them now.
“as far as maximum stresses are concerned, only NTheta and MPhi , are significant”
Maybe direct bending stress form formula has similarly disregard the pure tensile part due to Nphi component too?
I would try to substract OUTPUT 2D from OUTPUT 3D in my FEA.
Stresses in LSYS will be easier
Transformed to cylinder coordinates. Hoop(thick lines)/bending(thin lines) stresses in three layers: bottom(Inf), middle(Moy and top(Sup). x=0.12-0.20 is the inward corrugation, x=0.20-0.28 is the outward corrugation. Still code_aster with 1D axisymmetric analysis, posted just so you have a comparison. Also the same cut-out of a larger model with n=5 as in previous post.
For a calculation of this kind I dont think that transformation will have any effect, or rather I think that results are already in cylinder coordinates as this has to be part of the “built-in” in the stiffness matrix generation for anything to make sense.
For the bellow, a cylindrical coordinate system only fully matches with the Local CSYS in the HOOP direction (Theta). For the Longuitudinal component (phi) they only match at the Point O (Sigma_R in Cylindrical) and points (A and B) (sigma_Z in cylindrical). None of them are the points of interest. Maximum values are at intermediate points

To split the Direct Stress into Tensile/Compressive + Bending you need the values expressed in local CSYS. Mecway can do that with a good preparation of the orientations.
Interesting, @Disla, thanks.
Thanks, that indeed made it much better:
Expected: u = 12.26 mm, σ_h = -84.24 MPa, σ_m = 148.44 MPa, σ_VM = 204.04 MPa
FEA:
This is with 1-layer shell and OUTPUT=3D.
I also included global S11 and S33 (axes in the plane of the tube’s base) because they appear close to σ_m (maybe just by coincidence, though). But the other values seem to confirm a good match.
In Abaqus, shells use the projection of the global CSYS on their surface by default, so the actual local directions of the stress components are not what they would be for solids. Interestingly, CalculiX also does it even though it expands shells to solids.

Be sure to have a good control of your orientations and that you can visualize them. My main problem in Prepomax is that I can’t see the shell elements orientations when postprocesing. Where are the local element orientations pointing? You know for sure the normal but what about the other two? You don’t know where S11 points when EL FILE GLOBAL NO is requested.GLOBAL YES as in this case is usless.
One could say, well, look at Principal Stresses.Smaller but same problem. A priori one knows they always constitute an orthogonal system. Ok, that helps…. You also know they are oriented in such a way that Shear Stress will be zero in principal directions. Ok. Here intuition says one “should” point in the circumferencial direction. But what about the other too?. Which one is the longuitudinal?.Even worst. Is there one PS aligned with the the longuitudinal?. Is principal stresses 1 on TOP, MID and BOTTOM Pointing in the same direction? I don’t think so. Top can be in tension and bottom in compression so principal stress 1 direction on top is not the same as Principal Stress 1 direction on bottom. Principal stresses number is assigned by value not by direction.
About 149.3 MPa : ¿Are you in GLOBAL YES or GLOBAL NO?. Where is your S11 Pointing?
Right, visualization of shell orientations would be very helpful (but would require symbol plots in general). They should be the same as in Abaqus, though (the projection seems to be done with the same rules):
It’s a global CSYS. The *EL FILE, GLOBAL setting doesn’t apply to shells - local directions are always used for them. The axes are shown in the middle of the tube (I created local CSYS aligned with the global one to show it at the origin). But taking into account the transformation, S11 is mostly just a projection of the X axis onto the surface (global Z axis is projected instead only if global X is within 0.1 deg of being normal to the surface). Then local 2 direction is added in such a way that together with the normal direction (3) they form a right-handed set.
Not sure if I read your image properly but there seems to be a glich or some error in the orientations in your pictures.
First image sems oriented vertically. If that’s the case all arrows tagged as “1-axis” should be aligned with the horizontal axis (Hoop direction") and now there is a mess.
I don’t think so.Check it your self with a simple shell example sloped 45º.
I’m not sure what view would show it better, but here I disabled the 2-axis (yellow), reduced the symbol density and applied transparency:
At least some misaligned cases might be the ones where the global Z axis was projected instead.
I haven’t checked it yet, but I meant this sentence from the manual:
Default value for the GLOBAL parameter is GLOBAL=YES, which means that the results are stored in the global system (the only exception to this is for the shell stresses SNEG, SMID and SPOS, which are always stored in the shell local system).
























