ABAQUS UMAT getting hung up (no error message)

[Dave_Holmes]

I am using ABAQUS/Standard 6.5-4 and have written a UMAT incorporating a spring in parallel with a Maxwell element (in 3D) with Ogden potentials for each of the spring stiffnesses. For certain loading cases (i.e. about 10% strain) the simple 1 element model I am using to verify the UMAT solves very well. Unfortunately for higher loading cases and for some other loading rates the simulations dies without any indication of why. Now I am aware using UMATs can be problematic an will more often than not be the cause of unexpected termination however by incorporating detailed WRITE statement tracers throughout the UMAT generally allows any of these type of terminations to be found or at least has in my past experiences. Unfortunately the problem seems to be more sinister because when I run the program interactively, it would appear to be 'stuck' more so than terminated because ABAQUS stays in the simulation with all the pending solution type files (.023 .CID .LCK. STT etc) still present in the working directory however all the file sizes get to a point and stop, no mention of any error. I then have to delete these files and reopen my X interface to restart a problem.

The point where the simulation falls down is generally straight after a time increments has been completed following anywhere up to several hundred previously converged successful increments. Upon checking the odb in Viewer the simulation looks to be going in the right direction up until this point in as much as the stress vs strain curves are that which would be expected (i.e. no unexpected instabilities etc) and the simulation can continue to values even as high as 150% strain. Then trying to reduce the load or specified displacement in such a way as to try and reproduce the solved part of the previous attempt, the simulation gets hung up part the way to the new desired end point??

When the simulation gets stuck, the .DAT and .MSG files have no mention of failure and look as if they were opened mid solution. The tracer WRITE statements from the UMAT are written to the .DAT file up to a random point which can stop before a new increment, after a full statement or even in the middle of writing a statement (i.e. like halfway through writing out a 3x3 tensor???). Given the same solution parameters, the simulation always gets stuck at the same place however any change in these can mean a very different outcome which would be unexpected were any one error in the UMAT to be to blame.

Because of the seemingly random point at which the records in the dat file get stuck, I have a feeling the problem is something along the lines of decimal discrepancies somewhere between when stress, state variable and modulus are updated and when the UMAT is subsequently called again. The feeling is that the UMAT has read values, continues on its way but as an after thought gets confused and locks. One would assume that if the problem occurred in the ABAQUS solution algorithm then at least some error message would be produced.

Can anyone suggest what possible cause there could be for unexplained hanging when using a UMAT bearing in mind that I have debugged all the usual physical coding culprits and now I seem left with a more intrinsic program language type problem?

Alternatively, are there more detailed methods of debugging that can monitor the passing in and out of variables between ABAQUS and a UMAT subroutine?

Apologies for the long post but it would seem the problem is as complicated as it is frustrating.

[sq]

This is perhaps the best laid-out question I have seen on this board to-date.

Using write statements as tracers seems like the right diagnostic tool- especially if you are appending to some output file that you can look at later. This should not only include your tensor quantities, but your state varibles (i.e., Maxwell deformation state) as well, to help look for unusual behavior near the end (you could, for example, write an Excel macro or m-script that allows you to plot the relevant variables).

I may not be reading part of your description correctly- are you saying that the hang-up occurs at or just after a load reversal? This may be an important clue.

[Dave_Holmes]

No, unfortunately I am only running simple single step, forward loading cases on a 1 element model (I have tried prescribing an end deformation condition and a distributed load and both have the same results).

I have been observing the behaviour of all model parameters including state variables and there seems to be nothing significantly unique about the increments where hangging occurs. I have put write statements at the beginning of the program to make sure every variable called from abaqus is read correctly as well and this seems to present no obvious culperets.

I have to date been observing total stress and strain values in postprocessing up to the point of hang and have observed no instabilities however I will try your suggestion of observing a plot of the partial strains from the maxwell element and see how they go.

[Jorgen]

Dave,

Here are a few general comments.

:arrow: How do you write your debug statements? I recommend that you use simple print-statements without a unit number (assuming that you use Fortran 77). That way the messages will be written to standard output and you should be able to follow the execution of your UMAT directly. If you write to one of the ABAQUS files (e.g. the dat-file) then your statements are only added when the file is "flushed", and you might be missing info if the UMAT hangs.

:arrow: How are you integrating the flow in your UMAT? Can you avoid the crash with smaller max time increments?

:arrow: Is it possible that your problem has anything to do with the Jacobian matrix? It is often easier to debug a VUMAT than a UMAT.

:arrow: What computer are you running on? I have noticed that the error messages are often better on Windows PCs than Linux computers :roll:

- Jorgen

[Dave_Holmes]

Thanks for the responses guys.

Upon further observation it would seem the cause of the hang ups is an instability in the shear strain values. I had not thought of this and so thanks sq for the helpful suggestions.

The shear strain values for a simple tensile test travel along in the order of 10e-15 to 10e-20 as they should and then they become unstable and oscillate at an exponentially increasing magnitude until the hang at strain values in the order of 10e-7 or there abouts for one simulation I have been working with. The instability comes on very suddenly and would seem to be the obvious cause of the hang ups.

Unfortunately as you have suggested Jorgen, this would seem to indicate my DDSDDE tensor as the cause of my problems, an unfortunate outcome as I'm sure you all understand the unpleasant nature of reviewing a complicated DDSDDE formulation.

I'm still slightly perplexed as to exactly what could trigger the sudden instability when anywhere up to several hundred prior increments perform admirably and as such would appreciate any suggestions in this regard.

[sq]

Well, you have my sympathy for sure.

My days of writing method-of-lines simulations taught me one certain thing about dynamic numerical simulation: numerical instability gets triggered for reasons that are almost never immediately apparent, and the exponential growth is inevitable. Though, this is typically a feature (in my past experience) of forward integration methods (high-order or otherwise), and rarely implicit schemes.

Let me re-iterate Dr. Bergstrom's question- how are you integrating your flow (i.e., Maxwell element deformation)?

[Dave_Holmes]

The viscoelastic flow in my model is being integrated using Newtons method on the exponential mapping solution of the differential equation. This is done in principal directions. This is a similar method to that published by Reese and Govindjee (1997) and converges very rapidly to a tolerance of around 1x10e-22 in less than 4 iterations for most cases I have tried.

I have checks all through the loop to ensure that it doesn't get stuck in an infinite itteration and I have plotted the elastic component of Maxwell strain against total strain and it looks good and is totally stable in the 11, 22 and 33 directions and is identical to the total response in 12, 13 and 23 with the instability coming on rapidly at the end.

I attribute the instability being present in both viscoelastic and total shear strains because the spectral re-composition of the viscoelastic strain incorporates the deformation gradient which carries the error through.

[Jorgen]

It sounds like you are doing things right. One last comment, you might want to check that your eigenvalue decomposition and spectral decompositions are robust and correct.

It is difficult to figure out what the problem is without hands-on testing (and as you noticed, it can be difficult even with hands-on testing :x)

- Jorgen

[Dave_Holmes]

Thanks for all the help guys, Jorgen I'm using the inbuilt ABAQUS eigenvalue solver SPRINC so it should be ok. For the spectral decomposition direction tensors I'm using a formula published by Simo and Taylor (1991) so it should be ok too.

Unfortunately I think I'm going to have to review my DDSDDE formulation and then start stripping back the program and see which element is to blame. Thanks again, I will let you know how things go... isn't programming fun :?