HI,
¿Could someone provide a simple two cube example of MORTAR contact working in Prepomax?
Thanks
There are some examples within the CalculiX test cases (e.g. contact4_mortar.inp):
contact4_mortar.inp (3.6 KB)
But I attached an example made in PrePoMax too:
Mortar contact.pmx (304.9 KB)
1 Like
Sorry for any machine translation errors.
Below are analytical calculations for the example “Mortar contact.pmx” submitted by “FEAnalyst” based on Hooke’s law for compression. This is the simplest example of applying force.
Yeah, we don’t doubt its accuracy - this type of contact uses Lagrange multipliers and doesn’t have small penetrations unlike penalty contact so it can be very accurate. However, its problem is really poor convergence (at least in most of my tests).
Also, the usual way to check if contact behaves as expected is to examine the CPRESS output. If it’s uniform and the values are correct then contact is working fine (at least in the normal direction).
Is there something wrong with PrePoMax 2.4 for Windows 10?
After every calculation, I get a strange message.
When I click “Result,” I get the following error message:
This happens with every calculation.
I made an example to learn how to express force using deformations.
It is much more difficult when there is a complex bending element with a contact when you want to provide someone with the limit force, e.g. for some connection for a catalogue.
Another way can be to rearrange Hertz formulas - Roark’s book provides them for displacement too. So you can get contact stress from prescribed displacement.
But I guess the original question originates from this discussion where we (once again) talked about the usefulness of Mortar contact: Contact issues in Visco analysis - Analysis issues - CalculiX (official versions are on www.calculix.de, the official GitHub repository is at https://github.com/Dhondtguido/CalculiX).
A more accurate result of compressive stresses is obtained after unlocking the sideways movement of the base in the X and Y directions. I do not analyze contact stresses.
S33 = 10.63 MPa
One could also apply symmetry BCs on two sides here. Cubes are really nice for such simplified (single-element or with more elements) testing.
Here’s what is used in Abaqus documentation to compare node to surface and surface to surface contact (they check if CPRESS shows the same uniform pressure):
They have an example of sphere on surface contact too and they compare CPRESS distributions.
1 Like
It is very rare in practice to use symmetry conditions, so not all verifications can be constructed using symmetry.
Depends on the industry, quite some analyses still benefit from symmetry or even 2D (although much less frequently). However, I was rather thinking about verifications of various software features where you can use models as simple as single elements (especially common when verifying advanced material models including subroutines) and cubes.
You’re right, but you can’t just learn symmetry. You have to learn to solve the problem differently.
Things may indeed become tricky when the model appears symmetric, but we can’t use such BCs for some reason (e.g. buckling) or when we need to figure out more sophisticated approach to balance under- and overconstraint because the model doesn’t really meet the criteria for the use of symmetry BCs. In CalculiX, there’s also an issue with symmetry on curved shell edges.
Speaking about symmetry, there’s a nice article from FEA guru Tony Abbey: Simplify FEA Simulation Models Using Planar Symmetry - Digital Engineering 24/7
1 Like
I don’t have such simple elements
In your hand calculation the material is free to expand in the XY-plane for all values of Z which isn’t the case for the simulation where XY-plane are locked at both top and bottom.
Instead of you could release the XY-plane by define your boundary condition as shown where only the symmetri lines are locked for movement in the XY-plane. This will give you values between 10.4899-10.4890 MPa and an error of 0.1%
1 Like
Symmetry planes should work too, that’s why I suggested their use for such simple test models in the first place.
1 Like
Thanks for the files @FEAnalyst.
After some testing seems there is a bug in ccx. Mortar convergence depends on the unit system used to do the analysis which should not. Maybe a round off error. Same analysis executed using mm works fine, but if node coordinates are expressed in m it terminates without explanation.
I will post in ccx forum to see if there is any explanation or error in my set up before reporting on Github.
When done in mm accuracy is perfect. Zero clearance and perfect contact pressure.
Regards
Please do so, I will also notify Guido if he doesn’t react anytime soon once the GitHub issue is posted.
I almost always use the SI(mm) system, and I had convergence issues with Mortar contact in several cases, but it might be another problem - probably poor convergence of the Lagrange multipliers in general, combined with worse optimization than e.g. in Abaqus.
Still, I will look for some examples too and maybe we can help Guido further improve the Mortar contact algorithm.
1 Like