How to incease limit on cutbacks and iterations.

MikeMcMullen

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.

Victor

Lots of possible reasons, especially if there's contact, rotations of 90 degrees or more, or if it's buckling or has plastic material. Could you attach the file or email it to me privately?

MikeMcMullen

I don't expect a quick convergence. As the load increases the depth of the cracks in the concrete increases and the length too, and this changes the stiffness which changes deflection, and loads the rebar as the crackiing passes the rebar but eferything is going the right way. I managed to get up to 87% by stiffening the elastic supports, but I want to get up to a significant part of the load so I can look at the stresses in it the bars and see what needs to be strengthened and adjusted. The cutbacks are that it starts at 100%, then 25%, then 6.25% etc and exceeds the cutbacks before it gets to a value of somewhere between .01% and .4% then steadily walks up with steps of between .1%, and 1%. and then reaches either a true lack of convergence (bars yeilding) or more commonly maxes out the number of iterations while still making progress, usually between 500 and 600 iterations.
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.

Victor

Oh cracks opening makes sense why it would be slow. What are you using as a material model? If the stress-strain curve has a sharp knee in it, that's certainly something it can struggle with.

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?

MikeMcMullen

It seems to go the same with quasi static reguardless of the values I input. It does ramp the loads gently with or without quasi static, just runs out of allowed iterations at varying points for the same input. I think the one that went to 87% may have lost ability to support so I cut the loads some to see if it would do better. I think it just needs 1000 or 2000 iterations and only gets to do 500 or 600. Could maybe change the convergence limits, but the forces seem to be what closes last and take many sub iterations, starting far from closuer closing many orders of magnitude each iteration... but very consistantly. Note the bars do not connect at every node, so the matrix will have connectivity to nodes not very nearby. The analysis type page looks like there is more control available for the limits, just possibly not implemented in Mecway so it may be possible to change the limits on iterations or cutbacks with Calculix cards?

Victor

With quasi-static, you have to ramp the loads yourself (eg. "123 * t" for linear ramping or "123 * t^2" for gentler quadratic ramping), otherwise they're immediately on which is bad for convergence.

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.

MikeMcMullen

Not in good enough shape yet. I think the above may do the trick. Bit of effort to make the loads "time" dependent. Thank you. I was sure you had an answer.

JohnM

if you have a lot of loads manipulate, this might be a time to open up notepad2 and find a way to do a change all to add the *t. can't hurt to try, just make a copy of that thing!

MikeMcMullen

I have done that before, but I don't think it would help much in this case as the increment quickly gets down to 1% or so then starts working up slowly gradually getting more slow as the stiffness falls and non-linearity increase. Still would need a lot of iterations. Current run is chugging towards its ultimate solution or non convergence due to true lack of strength. Just getting there slowly with increments of about .3% , gradually getting smaller as the stiffness falls, with about 7 major iterations of 50 to 80 minor iterations each increment so far. I am using 4 cores for this so I can even do another problem in parallel if I want. Currently at about 360 iterations and 3 and a half hours run time.

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.

disla

Glad to hear you have recovered. Of course, a little mecway can be a good rehab exercise to get you back

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.

MikeMcMullen

Both areas of concern for me. Once I get a run far enough for significant stresses, maybe at least touching yeilding I can look close at the output. My supports are not compression only, but elastic. This will tell me about any uplift issues when I get to look at the output. I don't understand contact that well, but have heard it can effect convergence, and don't understand it well. Some of my models are very large and contact would greatly increase the number of nodes and degrees of freedom. My bigest problem with my first small tests, is that the color coding of the bar stresses does not show up well on the screen.

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.

disla

My bigest problem with my first small tests, is that the color coding of the bar stresses does not show up well on the screen.

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?

MikeMcMullen

My problem was simpler than that. The black solid lines at the edges of the bars overwhelmed the colored interior when not zoomed in, and with a regular grid of bars top and bottom it is hard to keep orientated with what you are looking at. I. e. when zoomed out to orient on a 30 ft x 40ft slab the color scheme on the stresses/strains does not show up when the bar is only a few pixels wide and has a black line each side. I changed the line weights and it helped some. Probably neen a big 4K monitor, but manipulating the image is already slow, and I don't have the desk space for it. Cataracts don't help either.

Victor

I don't understand the black lines problems but in case they are the edges of solid expanded beam elements, you can turn that off by requesting axial force in the solution and it outputs line elements for beams. They'll still have uncolored parts where they connect to solids, as Disla explained though.

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."

MikeMcMullen

What would be the specific instruction to get this "last iteration thing". I was out of the house and it seems to have erased all the output and closed mecway when it finally stopped when I was gone. (doesn't always do this) and I could not find saved output. It is slow because the increments get to be very small, .02% to .03% last I saw as the load increases resulting in a lot! of major iterations, about 2300 when I had to leave.. convergence is slow in the forces, not the deformations. Note these are the first medium sized problems with both compression only for the concrete and reinforcing steel bars with shared nodes at the bar centers nodes. I can try making the problem smaller by going back to linear elements, so I have ways to speed things up. Note down near 0% the increments are an order of magnitude larger.

Victor

Sorry about the crash. It should have left behind the temporary folder with the CCX solution in a .frd file you can open. It would prompt you about this next time you started Mecway.

MikeMcMullen

Other runs have not crashed.
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.

MikeMcMullen

Got a model to run to 100% (attached screenshot). I increased the Tension limit 10% on the Compression only concrete material and it ran to completion. Previous run had only gone to 65% before it failed to converge. I had thought a problem at the common nodes would be tension capacity sensitive and ran this is a check. Tension capacity is perhaps 200% of what I should be using.

MikeMcMullen

Never mind. Concrete cracking never got to the rebar with the tension capacity.

Victor

For last iterations, add a Modify keyword item to the CCX branch with keyword *NODE FILE, parameter name LAST ITERATIONS and no value. However, I notice the .frd file it generates can't be read by Mecway. You can open it in Prepomax though.

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.