I’m looking at Mohr Coulomb material model.
I have found this weird behavior (weird to me). Not sure if this could be a bug or if the one doing weird things it’s me.
Mohr material parameters define a Yield surface according to the graph line.
Tension test behaves as expected failing once the Stress State (small circle) touches the Yield Surface.
When testing the model under compression, Mohr Circle reaches the expected size to trigger the failure, but the analysis keeps running there forever.
the value of cohesion seems too low and lead to convergence problem (c<7.5MPa), i guess Abaqus have the same problem also. In this case, a material model of Drucker-Prager or modified MC can be used. The lowest value of cohesion i have tested and successfully converged is about 3.0MPa
Hi Xyont and thanks for taking the time to look at this.
What is curious to me is that the analisys is freeze at the right value!. Seems like someone should say to the algorithm !! Stop man, you’ve already made it !!
My intuition says the convergence struggles in areas of uniaxial tensile or compressive stresses where the minor principal stress is almost zero and is probably messing something. I will try adding some artificial Stress.
I was right. Adding a small artificial tensile stress to the model it behaves as expected and the iteration process ends without issues.
I would suggest Mr.Dhondt to check which is the succes criteria on the Mohr Coulomb algorithm when one of the Principal Stress is almost zero (Uniaxial Stress State).
I will try to apply this to a beam example I have been working with and that has some convergence issues on its ULS.
As I understand it there is no failure case with no principal tension, or rather tensile strain. Like trying to crush fluid. Perhaps I don’t understand though.
You can’t crush a fluid because fluids can’t sustain shear.
Here, ccx can’t decide if the element has crush because in a uniaxial Stress State there is no shear at all.
probably, the problem of convergence is due to value of dilation angle set to zero in these cases. Normally is about 30deg and more for concrete materials, add small and negligible value solved by modified MC, but still not for Mohr-Coulomb.
I think friction angles over 45 deg might be special cases and not consistent with the material model, perhaps requiring just the right dilation angle. 36 or 37 deg might be a more reasonable friction angle for concrete.
36º angle has the same issue. You can try it on my Compression test inp.
The analysis remains running forever close to the right spot.
That seems to support the hypothesis that the problem is a near-zero value of tension in the pure compression test.
Again, the introduction of a small value of tensile stress precipitates the material failure.
Looking at the inp file (assuming this is attempting to model concrete rather than a soil analog):
The dilation angle is set to 0? Seems like for regular (not foamed or very lightweight) concrete it is more like a degree or two.
The strain corresponding to the cohesion should be lower? I know it is perhaps close to 1.0 over a crack width, but i think this is a smeared model and it probably averages .00001 to .0001’/’ strain over the mass in the crack vicintity. (perhaps as much as .03 if the effect of stress field rotation of shear cracking is effectively modeled by the FEM stepping the rather than the material model.
I don’t know if these values would change anything.
This probably has nothing to do with the convergence problem which seems to be perhaps due to the perfection of the loading and the nodes geometry. Seems like this sort of thing might show up on problems that should buckle, but lack that initializing infinitismal, so not a pecularity of this type of material.
Also I see you run this from Mecway 23. I run that too. Could I have a copy of your *.liml file so I can play with it. I don’t work directly from CalculiX.
I have also attached a comparison file for reference using this parameters.
It helps me to have a context . Keep in mind I’m not Civil enginieer and I’m just exploring this material model.
I would say the expected principal Stress @Mcr=89,139 kgf·cm is quite close.
Principal Stress
2.34 Mpa
Expected
2.29 Mpa (*)
Result
(*)Sxx
Deflection calculation for reinforced concrete T-beam.
Calculated in accordance with Eurocode2 (EN1992-l-l:2004).
Section: T-shape.
Load: permanent only.
mostly building codes of reinforced concrete design using lower bound approach, many simplifications already done inside formulation e.g ignoring tension capacity of concrete, compression stress block shape model, steel hardening, triaxiality confinement, etc. Finite element analysis using advanced material model trying to seek actual capacity based on numerical simulation, Probably, the best comparison is toward physical testing instead of analytical hand calculation, so a material parameter values can be provided as normally without modification to adapt of simplification.
I don’t agree. Yours is probably a researcher point of view. Comparisons against experimental data can be very frustrating and do not provide (in my opinion) a consistent methodology to later approach new problems. Mainly because it is almost impossible to identify the source of any discrepancy. Experimental values have dispersion and it is always debatable whether your boundary conditions exactly reproduce the experimental conditions.
It’s a matter of understanding and respect the code underlaying assumptions.
“Learn the rules like a pro, so you can break them like an artist”. Pablo Picasso
i mean code formulation only good as starting point to pre-estimated capacity, not the goal and used as benchmark and comparison of nonlinear FE results. Of course, anyone is freely to do such as tricky in modification the model e.g material parameter and boundary condition to match their hand calculation.
It would appear that there is no code formulation behind FEM. ¿?¿?
I think you haven’t seen what I sent. Code formulation comparison is precisely to avoid that. Anyone can check and compare your results as there is a unique reference. But to do that you need to expose your procedure right.
I would not like to clear my doubts just changing to another material behavior, adding some missing dilatancy or playing with the angle. That’s what we don’t want, right?. I’m trying to understand where the limitation of my actual approach is and discard any possible own error. This material model , without plasticity or dilation match well with code formulation and seems perfectly usable.
Regarding my Mohr parameters, I’m not inventing anything to match the hand calculation if that’s what you are suggesting. They respond to the criteria referenced by article Piratheepan et al. where cohesion and friction angle are derived from first principles. “Parameters estimated from this method could predict the experimental results well in the elastic region but over-predicted the ultimate stress”. Which by the way seems to agree again with my results as when going further I can see deflection shows a discrepancy with the EC-2 (30mm against predicted 37mm).
That provides a consistent approach and defendable material parameters in case the analysis is limited to the Elastic Regime.
I use code whereever it is applicable. The design code I use (AASHTO LRFD… I was a reviewer for parts of the first draft in 1993) has provisions for the use of FEM. Most areas of code are known to be safe in typical situations, but the simplifications in the code make their applicability unknown in other situations. The examples I can think of are load distribution, lateral earth loads, blast, earthquake, impact, shear (especially punching), progressive collapse, skew, dynamics, aerodynamics, cracking, creep, etc. I have also worked on rockfall protection design and the early mechanically stabilized earth structures and would have appreciated access to a general purpose FEM program at the time.
I have sat with code bodies and have an idea of how the sausage is made. Often the only data they have is FEM verified by limited physical testing (sometimes very limited), and they write equations to approximate a range of FEM results. Other times all they have is educated guesses, info from manufacturers or designers with a vested interest, or rules of thumb.
Sometimes the code bodies don’t know what the limits of applicability are because the equations have been around so long and all the authors are dead. The people involved have no god like understanding, though they lead State government bridge design agencies. They get the best advice available to them. Some times the limits are simply because that is how the structure type was used 60 years ago.
One of the FEM programs I use and occasionally update was used to verify the AASHTO code provisions for liveload distribution, which can be very crude outside the range of problems they ran to verify them. The program was written about 1990 to run on an IBM XT. The physical reality trumps all simulations with code equations… or FEM for that matter. Testing of full scale structures often does not closely match code predictions, but more closely matches well modeled FEM runs. Even for ordinary situations a well tuned and understood FEM can reveal insights into structural behavior that go beyond the code.
The problem with FEM is the tendency for engineers to trust “black boxes” that they don’t understand, whether that black box is an FEM model using proprietary software, or an equation that they don’t know the limitations of. Trusting codes fully is only protection from legal liability, not responsible design.
Perhaps, though checking someone elses work would require them to provide documentation on the level of a well documented textbook or research report. Initial investigations can not go into that detail. In fact, checking calculations is dangerous. in practice. Checking results is much more reliable as it does not involve accepting means and methods.
I do not have much, if any, experience using Mohr Columb, but I understand the meaning of the input values, and some of these do not seem to be representative of normal concrete. The method is old and predicts behavior of soils through failure very well, including partially cemented soils approximating concrete in behavior. In particular the dilatency angle would not be 0 deg., but on the order of perhaps 2 degrees. The internal friction angle would not be 55 deg, but on the order of 35-37 deg. though other materials might have these values. In the elastic region it is to be expected that FEM would match testing if the correct elastic modulus is used as no shearing displacement is occuring. It says little about the applicability of the method. Note friction may have different definations, either static or dynamic and a decision might need to be made which is appropriate for a particular analysis. I vote for dynamic simply because I am mostly interested in impact, concrete is always cracked on a microscopic and usually a macroscopic scale in realistic conditions (though some cements and casting methods might not be if done perfectly).
Is it possible that c and Friction Angle could be redefined depending on the Stress State.
Nothing says those parameters must be valid post Mcr.
In fact, Code formulation clearly distinguish pre and post Critical Moment phases introducing a new value for the Young Modulus and nobody has complain when using a Young Modulus 25.1 times smaller.
I have also seen large discrepancies of Friction angle depending on the author or code.
My intuition says the convergence struggles in areas of uniaxial tensile or compressive stresses where the minor principal stress is almost zero and is probably messing something. I will try adding some artificial Stress.
Adding a small artificial tensile stress to the model it behaves as expected and the iteration process ends without issues.
