Stuck? 
support@mecway.com
support@mecway.com
Mecway
FEA
How to incease limit on cutbacks and iterations.
I have a non-linear problem of a reinforced concrete slab and I can't reach a solution. Each step converges, but it wants to start at a small starting % and increment by no more than .4%. Typically quits at about 600 iterations and 39%. Stresses strains and deformations are all reasonable and it was making steady progress.
Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Comments
Note this not one of those problems with huge numbers of nodes, just very slow and steady converrgence. The iterations are pretty fast. First problem with compression only concrete sharing nodes with rebar. I was off this for 9 months due covid putting me in the hospital, and also I sprained my ankle. Getting back to about 80% and the brain fog is going away so I am picking up where I left off.
It sounds like you might not be using quasi-static. I would turn that on so you have more control. For instance, setting a small initial time step so it doesn't need to do cutbacks to find it on its own, and ramping the loads gently, especially around any particular regions where it struggles.
Is it possible that when it fails, it's lost all its ability to support the load so there can't be any solution?
Is it saying there are too many increments? If you set a small time step size, Mecway increases the allowable number of increments (INC parameter on *STEP), but you can increase the limit manually with CCX -> Modify keyword as shown in this picture:
If it's failing from too many cutbacks, reduce the time step size so it doesn't have to go so far back. Sounds like it might have converged at 0.0001 s with linear load ramping (i.e. 0.0001 * load values), so I would start there.
It would really help to be able to see the file.
The nature of reinforced concrete is that as load increases the concrete flexes and reacts the load with flexural stresses, but it also deforms and develops internal compresssive forces and arching, expecially at localized loads. The compressive load and arching are non-linear in geometry effect. These peak at local deflections about .26 of the element thickness. At some point before this peak the concrete begins to crack which causes the stiffness to fall gradually redistributing the load from near the crack. At some point the concrete cracks and the cracks grow in both in length and depth. When the crack depth passes the reinforcement it generates tensile forces which increase with the strain at that point. Peak resistance at an area will be at a deflection of about .26 where the arching peaks but is in addition to load capacity from the moment capacity from the couple between the reinforcement and the compression on the opposite face. At this point additional deflection causes the arching and net compression to fall while flexure is largely constant. The FEM would not converge for loads beyond this point and stepping forced deflections would work, but the deflection pattern would be constantly changing making it difficultto determine the pattern of impressed deflections. Works nice for point load though. At deflections over about .6 of the depth the net compresssion has gone to zero and becomes tension with a catenary supporting effect and the resistance again starts increasing. The arching, cracking and pop through to catenary effects are all highly nonlinear in different ways. The arching effects are dependent on lateral support, and decrease with decreasing elastic modulus of the concrete, with shrinkage and with lower stiffness of lateral support.
Apart from increasing the number of increments as pointed by Victor, *Controls also allows some changes on the iteration parameters.
I also made some tests on reinforced concrete beams. In my experience, all my convergence issues were located at the tensile areas of only compression material.
They showed a very small tolerance to tensile stresses.
The issues were located at:
-Supporting area
-Rebars connection with the concrete
First one I solve it using only compression supports.
Second , I did not merge nodes between concrete and rebars. Instead, I connected them using contact which could be frictionless or equation without enforcing the longitudinal direction so rebars could slip without transferring tensile stress to the surrounding concrete.
My test run is now 19 hours along at near 52% of the input load, near 2000 increments of load running at about 0.02% of the input load per load increase. 2000 is what I put in for the new increment limit so it should be over soon.
I experienced that too.
Victor help me at this point.
"On nodes shared by beams and solids, CCX averages the beam internal forces with the stress components of the solids, making the values meaningless. Mecway discards them to avoid confusion.
Two workarounds:
• Make the nodes separate and connect them with constraint equations - generated somehow.
• Refine the rebar mesh so there are nodes between the solid nodes. However, those new nodes wouldn't be attached to the solids so it might not be accurate. Maybe OK if it's mainly axial stress, not bending?
I wonder if you'd get some insight about why it's slow from the last iterations option: I haven't used it but from the CCX manual:
"use the “last iterations” option on the *NODE FILE or similar card. This
generates a file with the name ResultsForLastIterations.frd with the deformation (for mechanical calculations) and the temperature (for thermal
calculations) for all non-converged iterations starting after the last convergent increment."
I am currently running a smaller model (changed elements to linear from quadratic). issues (worked and working around):
Quasi static will not work because I have several different pressure loads on some areas simultaneously, a no-no for calculix.
This is one problem where Pastix works much better without the single precision. I think it is trying to converge the jitter from the standard precision FP.. on the geometric non-linearty, often on the order of .00001 to .001.
It also seems to be a case where more cores helps because the problem is more in cache so memory bandwidth is not as much of an issue.
I suspect I do have an issue with common nodes. I think perhaps it transfers too much force into the concrete element in too small of an area for the low tensile strength of concrete in this compression only model. I may also share nodes also with crossing bars to eliminate the very small concrete elements between mats tied together. The location of the secondary bars will be off a fraction of an inch, but there will be fewer elements.
There may be an issue with the low concrete tensile strength and shears... don't know yet. Getting a mohr coulomb model of concreete working later may cure this.
For the 2-pressures problem, if you make one of them also a function of position, (e.g. 123*t + 0*x) then it works. That's because position-dependent pressure gets converted to node forces instead of *DSLOAD. But it doesn't adjust for large displacements.
I would like to put weak springs on every node and make it solve quickly and completely, then reduce their stiffness and hopefully there's a point where they aren't carrying significant load but it still solves.