We have an exciting announcement about badges coming in May 2025. Until then, we will temporarily stop issuing new badges for course completions and certifications. However, all completions will be recorded and fulfilled after May 2025.
General Mechanical

General Mechanical

Topics related to Mechanical Enterprise, Motion, Additive Print and more.

Mechanical goes back to already computed time steps

    • remi.gerard-marzan
      Subscriber

      Hello all,

      This is a question about a transient thermal computation in Mechanical 2023R3. The analysis is structured in 13 different steps, each with different boundary conditions. What baffled me yesterday was looking, while computation was taking place, at the Temperature - Maximum global and Temperature - Minimum global data. It shows that, for some reason, the computation goes back in time and recomputes some specific time steps more than once. This can be seen on the following picture.

       

      Has anyone ever encountered such an odd situation? It might be perfectly normal, for all I know, just extremely confusing.

      Best regards,

      Rémi

    • dlooman
      Ansys Employee

      This can't be right.  The behavior is what would happen if you left solution between load steps.  In Analysis Settings only the end time for a load step is specified since it's assumed it start from the end of the previous load step.  Are you using commands objects that might modify the normal behavior of the program? 

    • remi.gerard-marzan
      Subscriber

      Hmm well I'm using the PID ACT developped by PADT, which is described here. I'm not entirely sure how this ACT works under the hood, so it might be related. But the computation has a very hard time converging with this ACT and given that auto time stepping is on, the time step is halved over and over again till the computation converges.

    • dlooman
      Ansys Employee

      Yes, that could definitely be related.  I would think the 13 steps should be consecutive in time, not independent solutions like you show, but I'm not familiar with the extension.

    • remi.gerard-marzan
      Subscriber

      Well thank you for the answer. I guess it's going to be difficult going much further in the diagnosis, though.

    • dlooman
      Ansys Employee

      Possibly PADT will help you.

    • remi.gerard-marzan
      Subscriber

      I have been able to make headway on this issue. First off, I have suppressed the PID ACT in my analysis, in order to narrow down the origin of this behaviour. Then, I have structured my analysis very simply: two successive load steps of 20s each. Like this :

      Then, things work out smoothly. At the beginning of load step 2, the following message appears:

      which is perfectly as expected. And then, when taking a look at the first substep, we do see that it starts from t=20s, which is indeed the end of load step 1.

      This would indicate that, indeed, the issue comes from the ACT module.

    • remi.gerard-marzan
      Subscriber

      And indeed, should I reactivate the PID module, it all falls apart: I first have, for the first load step, as normal,

      But then, for the second load step, it's written as "load step number 1" again, and instead of starting back from t=20s, it starts back from the very beginning.

      And this, I guess, explains the odd "crossing-back" that I have displayed on the very first picture of this thread.

    • dlooman
      Ansys Employee

      Good detective work!

    • remi.gerard-marzan
      Subscriber

      I guess this can be closed. I hope it will shed light for future uses of the PID ACT that might encounter this situation.

Viewing 9 reply threads
  • You must be logged in to reply to this topic.