Continue to Site

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations KootK on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!

ABAQUS/Explicit not "converging" -- How to stop simulation?

Status
Not open for further replies.

dfgsdfgfd

Mechanical
Sep 30, 2015
37
Hi,

When I run my Abaqus/explicit simulation, sometimes it is not converging. The output looks as follows and keeps on going forever, without moving on to the next interval. Is it possible, similarly to the implicit solver, to set a minimum stable element size OR set a maximum number of attempts per increment, and have the solver stop when this number is reached? If possible in Python.

The reason is that I'm running multiple simulations behind each other and I rather have some of them fail and move on to the next one than being stuck with one for many hours or days and not simulate the following ones at all.

Thanks so much!


Code:
              STEP     TOTAL       CPU      STABLE    CRITICAL    KINETIC      TOTAL
INCREMENT     TIME      TIME      TIME   INCREMENT     ELEMENT     ENERGY     ENERGY

  1313863  5.840E-03 5.840E-03  02:41:24 5.248E-09         509  8.404E+00 -3.013E+02
INSTANCE WITH CRITICAL ELEMENT: PARTNAME
ODB Field Frame Number    365 of    500 requested intervals at  5.840002E-03
  1317634  5.856E-03 5.856E-03  02:41:54 4.808E-09        4410  7.454E+00 -3.023E+02
INSTANCE WITH CRITICAL ELEMENT: PARTNAME
ODB Field Frame Number    366 of    500 requested intervals at  5.856006E-03
  1321807  5.872E-03 5.872E-03  02:42:28 4.230E-09        2138  6.610E+00 -3.032E+02
INSTANCE WITH CRITICAL ELEMENT: PARTNAME
ODB Field Frame Number    367 of    500 requested intervals at  5.872002E-03
  1327147  5.888E-03 5.888E-03  02:43:10 2.938E-09        4410  6.104E+00 -3.041E+02
INSTANCE WITH CRITICAL ELEMENT: PARTNAME
ODB Field Frame Number    368 of    500 requested intervals at  5.888001E-03
  1333146  5.904E-03 5.904E-03  02:43:58 3.668E-09        4410  6.323E+00 -3.049E+02
INSTANCE WITH CRITICAL ELEMENT: PARTNAME
ODB Field Frame Number    369 of    500 requested intervals at  5.904003E-03
  1339888  5.920E-03 5.920E-03  02:44:52 2.209E-09        4410  6.126E+00 -3.057E+02
INSTANCE WITH CRITICAL ELEMENT: PARTNAME
ODB Field Frame Number    370 of    500 requested intervals at  5.920001E-03
  1351226  5.936E-03 5.936E-03  02:46:23 8.740E-10        4410  5.819E+00 -3.063E+02
INSTANCE WITH CRITICAL ELEMENT: PARTNAME
ODB Field Frame Number    371 of    500 requested intervals at  5.936000E-03
  1366210  5.942E-03 5.942E-03  02:48:23 3.388E-10        4410  5.869E+00 -3.066E+02
INSTANCE WITH CRITICAL ELEMENT: PARTNAME
  1381148  5.945E-03 5.945E-03  02:50:23 1.681E-10        4410  6.045E+00 -3.067E+02
INSTANCE WITH CRITICAL ELEMENT: PARTNAME
  1396056  5.948E-03 5.948E-03  02:52:23 2.255E-10        4410  6.040E+00 -3.068E+02
INSTANCE WITH CRITICAL ELEMENT: PARTNAME
  1410886  5.951E-03 5.951E-03  02:54:23 2.570E-10        4410  6.451E+00 -3.069E+02
INSTANCE WITH CRITICAL ELEMENT: PARTNAME
  1414975  5.952E-03 5.952E-03  02:54:56 1.383E-10        4410  6.373E+00 -3.069E+02
INSTANCE WITH CRITICAL ELEMENT: PARTNAME
[keeps going like that without moving on to the next interval]

 
Replies continue below

Recommended for you

Explicit analyses don't converge, there's no iteration or convergence checks. The solution marches through time according to the stable time increment. The analysis ends when the total solution time is achieved.

In your output, I think the analysis is proceeding as expected. You can see the total time is increasing by ~0.015e-03 in each line of the output. The reason it's taking forever is because the stable time increment is ~1e-09 or lower. This could be due to a number of reasons.

You should read about the differences between the implicit/explicit solvers in the Abaqus documentation. There are a bunch of ways to reduce the length of explicit analyses that might be useful.
 
Thanks for the response. I'm aware of the differences and ways to speed up the analysis. My log shows only a fraction -- it continues without moving on to the next increment for another 200 steps or so, and there is no end in sight. Hence my question:
Is it possible to set a minimum stable element size OR set a maximum number of attempts per increment, and have the solver stop when this number is reached?
I'm aware that the solution won't be complete then, but I want to specify a criterion to end the simulation and not move on forever.

 
"it continues without moving on to the next increment for another 200 steps"

Your analysis proceedss through successive increments. The first column in the log file shows the increment number is increasing. Your problem is the stable time increment is so small (e-09/10) that the analysis is taking forever.

"Is it possible to set a minimum stable element size"

The minimum element size is dictated by your mesh. The stable time increment is a function of the minimum element size and the material properties. You can specify a fixed time increment in the step definition. This can affect the stability of the solution though.

"Is it possible to set a maximum number of attempts per increment, and have the solver stop when this number is reached?"

As I mentioned earlier there is no iteration, no convergence check and no "attempt" in explicit. Each increment is one single calculation and the analysis just marches through time.

To try to address your issue:

You can monitor certain output in explicit and tell the solver to halt the analysis when the output exceeds a specified value. You could try to use this feature to halt problematic analyses. Its described in the documetation (*EXTREME VALUE).

Alternatively you could use sleep/timeout commands when submitting your analyses to kill a job if it has not completed after some nominal period of time and then move on to the next one.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor