AnsysWBU encountered a problem, mechanical crashed

KifflomKifflom PolandMember
edited December 2020 in Structural Mechanics

Dear community,

could anybody help me with this error? I am trying to solve a nonlinear static structural analysis, but mechanical crashes for no apparent reason... I am getting the following message:

I have the .dmp file but do not know how to open it. It is impossible to upload this file in this post... Could anyone help me diagnose the problem? I am using Ansys 2020R2.

Thanks in advance,


edit: also when trying to restart the solution from the last available restart point it gives the same message and closes mechanical...


  • @Kifflom

    The dump file is for software developers to look at, you don't want to look into that.

    If you clear the solution, save the model, restart the computer and try solving, does it crash again?

    If so, and you build a really simple model, will it crash again?

  • KifflomKifflom PolandMember
    edited December 2020


    For the first question - yes. For a simple model - no.

    The biggest issue is that it takes several (4-6) hours for it to solve to that point, and I can't just analize this one specific step, because the aim of my simulation is to predict welding distortion of simple butt-welded plates. The simulation crashed half way through the calculation process (i.e. the weld was 50% complete). What bothers me the most is that I don't get a chance to look at what failed (like residuals or unconverged solution deformation) to try and fix it. Thus I am having an "educated" guess - changing contact stiffness factor, simplifying material properties (turning off bilinear isotropic hardening, messing with coefficient of thermal expansion), trying to constrain the model from moving as much, turning stabilisation on, trying adding some contact step control, making the mesh dense, simplifying so that only the added weld material has nonlinear properties etc... If I mess with the simulation too much it gives me some results e.g. 17mm (0,7 inch) deflection instead of expected 4-6...

    It is a core part of my master's dissertation and the time is running out... I don't know what else I could do to make it work.

  • peteroznewmanpeteroznewman Member
    edited December 2020


    Okay, that means the issue is with the computer running a large, long-running model.

    Running out of disk space generally creates a different error, but it is good to check that you have space. Freeing up space is easy to do.

    One idea is to submit the solution to My Computer, Background. That means Mechanical will submit the job to the solver as a standalone job. Once the solve starts, you can quit Mechanical. You can track the progress by looking at the Solve.out file. Since Mechanical is not running, it CANNOT CRASH! When the solver finishes converging on the final step, you can start Mechanical and retrieve the results.

  • KifflomKifflom PolandMember


    Well I didn't expect that my computer could be the issue.

    I have enough disk space (100GB). I could definitely do with more ram, but some models run just fine (but gives inaccurate results).

    I will try the restart trick for sure. By "full solve" you mean a completed load step right before the error, right? I have to clarify though that the error occurred when the solution couldn't converge on a few consecutive substeps... But generally (with different models of the same problem) the program just informs me that it will display unconverged solution so that I can see what went wrong therefore I am not entirely sure whether the crash was really caused by nonconvergence.

    Thank you very much for your assistance so far. I will keep you updated.

  • @Kifflom

    I edited the post after you started reading the first draft. I came up with a simpler approach and deleted the restart approach.

    The error message you show is the Mechanical program crashing. That is completely different from the solver failing to converge. Try the submit to Background solve and quit Mechanical. Note that if you have configured the number of cores to use for a foreground solve, you may have to configure the number of cores for the background solve.

  • @Kifflom

    You could also try to untick "distributed" in solve options. Seems like you have quite a heavy nonlinear model, and thus you could expect the solver to use the hard drive extensively. The DMP mode ("distributed" on) produces even more files and data than SMP mode because of separate thread and files for each computing core. So it could sometimes crash if the hard drive is slow. The SMP could be a bit slower than DMP but it is usually more crash-proof.

    Another hint to optimize a performance, don't forget to check what solution method is faster for your case: direct (in-core/out-of-core) or iterative method. This is a single option in Analysis Settings but it could help a lot, depending on the problem and your hardware.

Sign In or Register to comment.