Pretension Section. Lenght adjustment without Amplitude.

disla

Hi Victor

I’m finding some unexpected behaviors in the pretension section. Not sure if this Mecway or ccx.
I request RF and U for the Pretension REF node (*Node Print) and Pretension section (*Section Print) to check.

SET UP 1

I’m Preloading with force=60KN
At the end of INCREMENT 5 (t=1s) I get :
REF NODE U=5.931434E-05 m (Later Used)
REF NODE RF=5.764179E+02 N (Unexpected)
SOF (Pretension Section)= 6.001718E+04 (Expected)

SET UP 2

I’m Preloading with displacement using REF NODE U results from SET UP 1 with an amplitude (5.931434E-05*t)
At the end of INCREMENT 5 (t=1s) I get :
REF NODE U=5.931434E-05 m (Expected)
REF NODE RF=5.763721E+02 N (Unexpected)
SOF (Pretension Section)= 6.001334E+04 (Expected)

SET UP 3 (!!)

Now if I preload with displacement but it is not ramped with Amplitude (I’m still using the same length adjustment value of SET UP 2)
At the end of INCREMENT 1 (t=0.1s) I get :
REF NODE U= 5.931434E-05 (?¿?)
REF NODE RF= 5.761326E+02 N (?¿?)
SOF (Pretension Section)= 5.999219E+04 (?¿? but agreement with REF NODE U value)

At the end of INCREMENT 5 I get :
REF NODE U=5.931434E-05 (Expected)
REF NODE RF=1.603347E+03 N (Unexpected)
SOF (Pretension Section)= 1.642456E+05 (Unexpected)

Seems like the length adjustment without amplitude has been or incorrectly ramped or keep constant while internally the value is changing.
Final result of SET UP 3 is larger SOF and huge final Von Misses in the prestressed area.

Regards

disla

File for reference. All three set ups for pretension section loads are ready. Just activate and deactivate the one you need.

Victor

Hello Disla, always a doozy when you find a problem!

I didn't look at the SOL and reaction force results which I'd say aren't really part of Mecway, but the displacements changing with time isn't supposed to happen.

I made a simpler model without contacts and found it does some strange deformation in the first 2 time steps then ends up with a layer of elements on the split surface inverted which results in a wrong displacement for the rest of the model but correct for the nodes on the split surface.


When I set a smaller length adjustment (eg. 1e-5), it behaves properly with no time dependence and the correct displacement everywhere.




I suspect it's to do with the thin layer of elements that Mecway inserts at the cut surface. In this case, they are 5.2e-5 m thick which is the same order of magnitude as the length adjustment (5.931434E-05 m) so it might be deforming them to much in a single step. I hadn't thought of this possibility and not sure how to prevent it. For now, if you have such a big adjustment, you'd have to ramp it. Even with native CCX, you wouldn't be able to do a big non-ramped adjustment with a very fine mesh.

Fatmac

I have been playing around with contact analysis of late so had a look at this analysis. I have seen some situations where the same analysis run in quasi nonlinear with a nice steady time based displacement have trouble converging where as if i just do the same analysis with no ramp as a non quasi nonlinear analysis the model converges no problem. In this case if u run the problemed case with no quasi static option the solution takes only a few seconds and provides more believable solution. I have been wondering if the quasi-static set up some times causes some issue. Incidentally I wonder if the parts in your model some how collide - if u run the analysis with no load it makes me feel there is a clash - also exporting the model into rhino as a .stp file also make me feel this may be the case

Victor

Quasi-static with contact sometimes converges worse than non-quasi-static because of the extra *STEP section Mecway inserts to prevent CCX from adjusting the contact stiffness (probably to help convergence!). During this extra step, the solver panel in the corner shows iteration numbers instead of time values so you can see if it's getting stuck there. If you don't mind the contact stiffness changing automatically with time, add no extra contact step in the CCX branch.

disla

Thanks for the comments .

There are still some things I don't fully understand.
Apart from the mesh and length adjustment possible incompatibility.

1-I'have been thinking for a long time that when analysis is performed with Automatic time stepping, by default, the load is ramped from 0 at time 0 to 100 % at end time automatically too. There was no need to multiply by time in the formula.

"Amplitude definition is needed only when you want to use non-default load/BC time variation (linear ramp in static )....". This is from another forum which I'm not sure now i did understood correctly.

Actually, without introducing the time (t) in the formula one would be wasting his time as result is fully introduced in the first increment. ¿Is that right?

2- Do you think the REf NODE RF could be a ccx BUG?. It should be RF= Pretension section Load resultant.
In Fact, when one preload with force, it is translated to a *CLOAD on that node. Why RF is not delivering the same value.?

Thanks

disla

It should be RF= Pretension section Load resultant.

This is not right sorry.
As RF contains the sum of external forces RF should be Zero. In any case the value is unnexpected.

Victor

1-I'have been thinking for a long time that when analysis is performed with Automatic time stepping, by default, the load is ramped from 0 at time 0 to 100 % at end time automatically too. There was no need to multiply by time in the formula.

That's the default for CCX but Mecway sets AMPLITUDE=STEP for quasi-static so you have to control any ramping yourself.

Actually, without introducing the time (t) in the formula one would be wasting his time as result is fully introduced in the first increment. ¿Is that right?

Yes.

2- Do you think the REf NODE RF could be a ccx BUG?. It should be RF= Pretension section Load resultant.

I don't think we can really expect anything from the reaction force there because that node is too special. When you apply a force to it, it's supposed to cause zero net force (pair of opposite forces), so already it's not behaving like an ordinary node. Maybe the external force should be zero though?

disla

Thanks Victor.
I will pay more attention to the ramp.

Regarding the Pretension Ref Node I will also ask in the Calculix forum to see if someone has a clue of why RF value doesn't match.

disla

HI,

Have you noticed that Contact State doesn't give a solution when the quasiestatic option is active. There is a message of unknown reason.

Victor

Sorry, contact state for elastic contacts doesn't work with quasi-static. I'll make the error message clearer.

disla

Regarding RF on the REF node , there is a bug in 2.22 that has been fixed in the last ccx version 2.23.

https://calculix.discourse.group/t/ref-node-of-pretension-section-reaction-force/3759