combination of quasi-static, plastic material and losing contact causes problems

DRQDRQ
Hi,

I expect the answer to this is that I've missed something that should be obvious but I can't see it, yet.

I've got an non-linear analysis that seems to work with any two of the following three:
- Centrifugal force
- quasi-static (cut down to Time period 1 second & Automatic time stepping)
- plastic material properties ("Bilinear isotropic hardening")
The convergence plots on the CCX solver window show the "Displacement correction" and "Residual force" trending toward some non-zero value:

The "Contact elements" is looking about right, this is meant to be a simulation of the least contact case so I expect there to be less contact.
I have tried waiting for longer, but with no more success.
I'd like to use quasi-static and plastic material because I'm trying to look at what contact there will be after the parts have been through some other load cases, which may include plastic deformation. I've done this, I think, with some other simulations but this particular one is not working out.

If I eliminate any one of the three options above, or reduce the speed for the centrifugal force, then it works.

A possibly similar or related issue is that I tried to investigate the plastic deformation by adding a final step (to the full analysis) when one part was shrunk using temperature so that there shouldn't be any contact, so the displacement remaining should be the plastic deformation. That didn't solve either, and I think it behaved in the same way.

It looks like if there isn't 'enough' contact in a plastic and quasi-static simulation then it doesn't solve.

Does anyone have any suggestions?

If there are any examples of anything similar on the forum or in the tutorials then I'd appreciate it if someone could point me that way.

Comments

  • disladisla
    edited April 2023
    If I eliminate any one of the three options above, or reduce the speed for the centrifugal force, then it works.


    ¿Have you check there is no rigid body rotation?.
    ¿Are you able to load partial solution during the analysis? If yes, ¿How does the deformation view looks like on the last available step?
  • VictorVictor
    Since it works at low speed, I'd ramp the speed - eg. enter it as "123 * t" instead of "123". Then you should see the solution up to the point of failure, if any.

    Turning off quasi static causes loads to be ramped automatically, so the sudden application of full load might be the problem.

    Or like @disla said, rigid body motion orthogonal to the load so it might not run away just by luck with some settings.
  • DRQDRQ
    ¿Have you check there is no rigid body rotation?.

    Whilst that is my favourite mistake I've avoided it this time! Always worth checking, and worth checking that I checked.
    ¿Are you able to load partial solution during the analysis? If yes, ¿How does the deformation view looks like on the last available step?

    On my 'proper' simulation I'd defined the loads with tables and saved every time step. So I could see the results that were produced before the speed increased enough to cause loss of contact, and they looked OK.
    I then did a cut down simulation to try and work out what aspects were causing the problem. For that I didn't use tables and either it would be fine or the first step wouldn't solve.

    However, there is more...
  • DRQDRQ
    Turning off quasi static causes loads to be ramped automatically, so the sudden application of full load might be the problem.

    It looks like it might be working now, and if it does solve (still running) then it would appear to be related to time steps.
    I was writing a fuller comment, but thought I'd give a shorter version first, to save anyone having to wade through the long and rambling comment that is on its way.
  • DRQDRQ
    Since it works at low speed, I'd ramp the speed - eg. enter it as "123 * t" instead of "123". Then you should see the solution up to the point of failure, if any.

    My 'full' simulation had the loads defined with tables, which included some ramping between the cases I am particularly interested in.

    I had previously run similar simulations without problems, but in those cases the contact faces separated less; there was more residual contact. And in those previous instances I'd manually set the time step to hit every point on the tables of loads, and used save every nth. This made the file pretty big (about 9 GB) and included a lot of unnecessary data, and didn't include some data I wanted.

    I tried switching to automatic time step and defining a "list of time points" that I wanted a solution to be saved at. I thought (and this is probably where it goes wrong) that the cutback system would deal with any failure to converge, especially since I'd seen each case work independently as static analyses, apart from showing the final plastic deformation.

    In any case, today I have modified my simplified quasi-static simulation to control the speed for the centrifugal force with a formula, as suggested by @victor. After a bit of trial and error adjusting the time steps, list of time points, save every time step, etc. it would run.

    I then switched back to my table defined loads and made sure that the same time steps that were used successfully were defined in the tables and requested as points in the "list of time points", to try and force the solver to consider those cases. But that didn't work.

    What I've now done is to add a couple more points in the "list of time points" to force even more time steps, but still using automatic time stepping. And it seems to be working... It's still running but it's got to a time point that corresponds to a higher speed for the centrifugal force than it's managed before and the convergence plots currently look much more promising, although it is at iteration 12...

    Turning off quasi static causes loads to be ramped automatically, so the sudden application of full load might be the problem.


    Drat. I knew this. I think I even re-read it yesterday whilst looking into this problem but it didn't click.

    I thought that the automatic time stepping would make the solution process more robust but I guess I managed to find a hole in it. It appears there is scope for fine-tuning the iteration control parameters but since that web page has the warning "should only be used by those users who know what they are doing and are expert in the field" I think that counts me out!
  • VictorVictor
    Automatic time stepping does seem to have a problem of ignoring the loads so it can skip over big changes and then struggle to recover or ignore brief loads. What you've done by specifying time points to force it to evaluate at those sounds like a good way.

    I never use *CONTROLS but I've heard that it can be helpful to force a (high error) solution to find out why it's failing. Mostly when it fails, it's for a physical reason. Something like runaway yielding or contact coming apart leading to rigid body motion.
  • DRQDRQ
    The latest version of the full simulation has run, mostly.
    It did something curious that I'll go through here if anyone is interested. And appears to be another interesting aspect of using automatic time stepping.

    It had been running overnight and when I checked it in the morning the message box in Mecway was showing:
    Time 65.75 s
    Iteration 2
    Solver exited

    which is curious, because whilst 65.75 is one of the time points I'd requested results to be saved at, it's not the last one.
    10, 15.75, 17.438, 19.125, 20, 30, 40, 45.75, 47.438, 49.125, 50, 55.75, 57.438, 59.125, 60, 65.75, 67.438, 69.125, 70, 72.5, 75, 77.5, 80
    The CCX output didn't include the usual "Job finished" and time messages, rather it showed 'normal' progress and then stops. But looking back through the log there is a message:
    the increment size exceeds a time point and is decreased to 0.000000e+00
    It appears to have run the increment for 65.75 s, and then decided that the next increment would take it past a time step and changed the increment size to 0. It then starts running an analysis for 65.75 s, does 2 iterations and then stops.
    As it happens, that time step shows what I was hoping to get to.
    I've just started running another version with slightly different geometry that I'd like to get past that time step. Fingers crossed.
    If anyone has any comments or suggestions they will be appreciated but I'm still trying to work out if I've done something I can spot.
  • disladisla
    I also like to ramp the load with a function in which the load is not always proportional to time.
    Sinus is a good option as it becomes gentler up to the end of the Time period when strains and stresses may become more extremes.
    It has the disadvantage that loads do not translate linearly in the time scale, so they are not so easy to track when you question the results.
  • VictorVictor
    That increment size of zero seems suspicious. I wonder if you've run into a bug with the time point accidentally coinciding with what the automatic increment put it at.

    When CCX exits abruptly, it's usually crashed, which you can imagine might happen if something's exactly zero when it shouldn't be.

    Would you be able to send me the file by email to investigate?
  • DRQDRQ
    Sorry for delayed response, I'm tied up with getting a report done but will send something as soon as I get a chance.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Register