PDA

View Full Version : Odd UMAT problem



Polyurethane
2006-11-13, 20:37
Hi guys,
I am developing umat for a material desribed by a dashpot parrallel with isotropic hardening plasticitic unit.
State variable STATEV (1 by 5 array) is used to store the equivalent strain and stresses (4 components inaxisymmetric case) in the plastic unit. In the begining of the code, these variable are retrived from STATEV by codes:

EQPLAS=STATEV(1)
WRITE (*,*) 'EQPLAS=', EQPLAS
DO K1=1,NTENS
STRES1(K1) = STATEV(K1+1)
END DO

In the end of the main program, the equivalent plastic strain and stresses were stored by

STATEV(1) = EQPLAS
WRITE(*,*) 'STATEV(1)=', STATEV(1)
DO K1=1,NTENS
STATEV(K1+1) = STRES1(K1)
END DO

The problem is the values stored in STATEV changed when umat was executed in next increment. This was found by printing out STATEV in the beginning and the end of the main program. A typical output in the log file for two consecutive steps is:

UMAT BEGINS
RETRIEVED STATEV= 1.029438210024758E-003 -5.713945669888542E-004 -3.048620394409372E-005 -8.527738384755799E-006 7.037705558193434E-004
EQPLAS= 1.029438210024758E-003
HARDING ITERATION
STATEV(1)= 1.101677901087380E-003
STORED STATEV= 1.101677901087380E-003 -5.782241858473527E-004
-3.148488354301983E-005 -9.967012388190511E-006 7.115024463430152E-004
UMAT ENDS

UMAT BEGINS
RETRIEVED STATEV= 4.123105002527970E-003 7.514232424012210E-004
-1.292459902481510E-003 -7.863942169827721E-005 1.270424561421470E-004
EQPLAS= 4.123105002527970E-003
HARDING ITERATION
STATEV(1)= 4.286253394173197E-003
STORED STATEV= 4.286253394173197E-003 7.589994231809726E-004
-1.305955859848658E-003 -7.997639334470215E-005 1.284520717761968E-004
UMAT ENDS

Apparently the values read from stored STATEV changed. Has anyone seen this kind of problem before?
Thanks a lot,

Polyurethane

Jorgen
2006-11-13, 23:54
That certainly sounds strange.

It is hard to give specific advice without more information, but the problem could potentially be caused by writing to an array out side the range of the array, i.e. something like: STRES1(87) = 1.0. Of course, I don't know if this is the problem in your case.

- Jorgen

ashu28
2006-11-14, 01:19
What about the values in the STRESS array ? Do they change as well or they are carried over fine ? This can help understand whether there is some problem with the code or not.

Ashu

Dave_Holmes
2006-11-14, 02:24
Some quick notes that may help:

I have got strange results in the past when the dimensions of *DEPVAR and *INITIAL CONDITIONS are specified incorrectly or where my code unintentionally tries to overfill STATEV. Also STATEV only stores values when a time step has converged. Make sure your comparison is definitely between STATEV values from the end of the previous converged step, to those read in at all iterates of the next one. Values won't carry on between iterations because iterations within a time step all start from the same point etc. Also if dealing with large strain are you rotating STATEV at some stage?

You've probably thought of these things but I figured I'd mention them just in case.

Polyurethane
2006-11-14, 14:20
About what you said "Also STATEV only stores values when a time step has converged", I am a little confused about how umat is executed. After stress array is updated in umat and passing back to abaqus, will abaqus run other iterations before executing umat again?

How to make sure comparison is between two converged steps? Right now I just add WRITE command in the beginning and the end of the umat.


Some quick notes that may help:

I have got strange results in the past when the dimensions of *DEPVAR and *INITIAL CONDITIONS are specified incorrectly or where my code unintentionally tries to overfill STATEV. Also STATEV only stores values when a time step has converged. Make sure your comparison is definitely between STATEV values from the end of the previous converged step, to those read in at all iterates of the next one. Values won't carry on between iterations because iterations within a time step all start from the same point etc. Also if dealing with large strain are you rotating STATEV at some stage?

You've probably thought of these things but I figured I'd mention them just in case.

ashu28
2006-11-14, 18:52
Well, the values get carried over only when the iteration has converged. Otherwise it starts all over again. Also those steps are computed at gauss points (and is thus related to the element type you chose CPE4 is different from CPE4R). That is probably the reason as to why you are not seeing same values(someone correct me if I am mistaken).
To ensure that you converge, you must evaluate a consistent Jacobian.

Ashu

Dave_Holmes
2006-11-14, 23:41
That looks like the reason your getting different STATEV values then. ABAQUS calls UMAT at each iteration, for each gauss point, however the values fed in for strain/def grad, state variables, previous time etc are all from the previous converged time step. There are numerous iterations within a time step all of wich are trying to get closer to the actual value of stress, state variables etc for the current step (i.e. iteration). I think it works that when the stress that UMAT calculates, and the ABAQUS stress prediction (function of strain and previous DDSDDE for the case of prescribed displacement) differ by less than the given tolerance, the time step converges and all stress and state variables are stored. If STATEV was stored at each iteration, convergence wouldn't be possible.

If you look at the STATEV values from the previous converged iteration for the relavant gauss point, and compare them to the STATEV values input to UMAT at every stage of the next time step, they should be the same. UMAT output STATEV will always be different because they are all approximations of the new values, hopefully getting closer to what you want. If this is the case, then I think the state variable storage is operating correctly and pherhaps you should look further into your code to find any errors you may be having.