Results 1 to 5 of 5

Thread: Strange values of DFGRD0 in Abaqus UMAT subroutine

  1. #1

    Strange values of DFGRD0 in Abaqus UMAT subroutine

    Hello all,

    I am new to the forum, but I have been reading posts here as a non-user from quite some time.
    I have run into a problem with DFGRD0 and I am clueless about what to do.
    I have written a UMAT subroutine for modeling of woven fabric materials, based on a rheological model of the fabric mesostructure, as found in a 2006 paper by King, Jearanaisilawong and Socrate, "A continuum constitutive model for the mechanical behavior of woven fabrics".
    The model allows to convert the deformations on a macroscopical plane continuum structure (e.g. simple membranes or shells) in forces acting on the yarns in the mesostructural model, and finally from these forces to obtain the stresses back on the continuum structure, as if it were not continuum but a woven fabric.

    In the mesostructural model, the two orthogonal yarn families, warp and weft, are conceptually imagined as trusses connected via torsional springs.
    The state of deformation is passed in as information, from which the geometry of the trusses, and the axial and bending forces and moments acting on them are estimated.

    I modelled the continuum structure in Abaqus (the UMAT is for Abaqus Standard) as a plane stress, 2D, 1 CPS8R finite element, square plate, pinned on the left edge, and with a little horizontal ramp-in-time displacement on the right edge, of 0.1.
    The results I obtain from my UMAT are very wild, and blatantly not accurate at all. In particular, I got that the stresses were =0 during all the simulation.
    I wrote a few "WRITE(*,*)" statements in the UMAT to track the evolution of the variables in the .log file of the abaqus job.


    What I think makes my simulation fail is the fact that the initial value of DFGRD0, DFGRD1 and DROT are:

    Drot:
    0.0000000E+00 0.0000000E+00 0.0000000E+00
    1.875000 0.0000000E+00 0.0000000E+00
    0.0000000E+00 0.0000000E+00 0.0000000E+00

    DFGRD0:
    0.0000000E+00 0.0000000E+00 0.0000000E+00
    1.875000 0.0000000E+00 0.0000000E+00
    0.0000000E+00 0.0000000E+00 0.0000000E+00

    DFGRD1:
    0.0000000E+00 0.0000000E+00 0.0000000E+00
    1.875000 0.0000000E+00 0.0000000E+00
    0.0000000E+00 0.0000000E+00 0.0000000E+00

    The same tensors, with a shear deformation value when I give an axial, 1-direction displacement... This tricks the mesostructural model to return some important internal geometrical variables as 0, and the stresses in return come out as 0 too.

    Another possible problem that I can think of, from the "WRITE(*,*)" statements, is the dtime variable, which is set at the beginning as dtime: 89128.96 , while my static analysis on Abaqus is scripted to last only 1 second.

    I really don't know what to do, I would be grateful to receive help on this!!

  2. #2
    Hello,

    i suppose that the array declaration at the beginning of the umat is not correct.
    Can you post the declaration part here?


    Regards, Viktor

  3. #3
    Hello muvik,
    thanks for the reply.

    You are right, the cause was the syntax I used.
    I tried to write another simple trial subroutine with pure elastic isotropic behaviour and what I got were unrealistic results, again. The three matrices Drot, DFGRD0 and DFGRD1 were still

    0.0000000E+00 0.0000000E+00 0.0000000E+00
    1.875000 0.0000000E+00 0.0000000E+00
    0.0000000E+00 0.0000000E+00 0.0000000E+00

    like in the previous UMAT.

    I found out that the problem laid in my tinkering with the abaqus_v6.env file: in it, I added '/free' as an argument in the compile_fortran list. This made Abaqus able to read subroutines .for written in the FORTRAN90 free format, instead of FORTRAN77 fixed format, which was default but I found rather cumbersome.

    It looks to me that, after tampering with abaqus_v6.env, Abaqus fails somehow to import correctly the variables passed in for information (Drot, DFGRD0 and DFGRD1, dtime, stran, etc) to the UMAT F90 file, although it is still able to run the job to completion.

    I have so far rewritten the trial subroutine in f77 format, and now it works fine, with Drot, DFGRD0 and DFGRD1 being identity matrices and the end results of the analysis being correct.

    Still, now I have to rewrite my code for the fabric UMAT in f77, which means DO statements in place of the handy matmul(x,y) and dot_product(x,y) commands in f90 and lots of other boring issues.

    Anyway, the header, and some of the declarative and executive parts, I used in my UMAT written with f90 were:

    Code:
    SUBROUTINE umat(STRESS,STATEV,DDSDDE,SSE,SPD,SCD,&
          RPL,DDSDDT,DRPLDE,DRPLDT,STRAN,DSTRAN,&
          TIME,DTIME,TEMP,DTEMP,PREDEF,DPRED,CMNAME,NDI,NSHR,NTENS,&
          NSTATV,PROPS,NPROPS,COORDS,DROT,PNEWDT,CELENT,&
          DFGRD0,DFGRD1,NOEL,NPT,LAYER,KSPT,KSTEP,KINC)
    
          implicit none
     !     implicit real*8(a-h,o-z)
     !     parameter (nprecd=1)
    
          CHARACTER*80 CMNAME
          DIMENSION STRESS(NTENS),STATEV(NSTATV),&
          DDSDDE(NTENS,NTENS),DDSDDT(NTENS),DRPLDE(NTENS),&
          STRAN(NTENS),DSTRAN(NTENS),TIME(2),PREDEF(1),DPRED(1),&
          PROPS(NPROPS),COORDS(3),DROT(3,3),&
          DFGRD0(3,3),DFGRD1(3,3)
    
        !!!!!!!!
        integer :: q1
        integer :: q2
        integer :: q3
        integer :: col
        integer ( kind = 4 ), parameter :: n=2
        real ( kind = 8 ), parameter :: start(n)=(/4e-4, 4e-4/)
        real ( kind = 8 ), parameter :: step(2)=(/1e-4, 1e-4/)
         ...
        !abaqus internal var
        !!!!!!!!!!!!!
        real  :: dtime
        integer  :: ntens ,NDI ,NSHR ,NOEL,NPT,LAYER,KSPT,KSTEP,KINC
        integer  :: nstatv
        integer  :: NPROPS
        !
        real  :: DFGRD0,DFGRD1,STRESS,DDSDDE,STATEV,SSE,SPD,SCD,&
          RPL,DDSDDT,DRPLDE,DRPLDT,STRAN,DSTRAN,&
          TIME,TEMP,DTEMP,PREDEF,DPRED,&
          PROPS,COORDS,DROT,PNEWDT,CELENT
        !!!!!!!!!!!!!!!
    
        !
        WRITE(*,*) ntens ,nstatv ,nprops ,props ,ndi ,nshr ,dtime ,time(1) ,time(2) ,npt ,noel ,kinc
    
        WRITE(*,*) 'Drot:'
            DO q1=1,3
                WRITE(*,*) Drot(q1,:)
            END DO
    
        WRITE(*,*) 'DFGRD0:'
            DO q1=1,3
                WRITE(*,*) DFGRD0(q1,:)
            END DO
    
        WRITE(*,*) 'DFGRD1:'
            DO q1=1,3
                WRITE(*,*) DFGRD1(q1,:)
            END DO
    
        WRITE(*,*) 'stran:'
            DO q1=1,ntens
                WRITE(*,*) stran(q1)
            END DO
    
        WRITE(*,*) 'Dstran:'
            DO q1=1,ntens
                WRITE(*,*) dstran(q1)
            END DO
    
        WRITE(*,*) 'stress:'
            DO q1=1,ntens
                WRITE(*,*) stress(q1)
            END DO
    
        WRITE(*,*) 'DDSDDE:'
            DO q1=1,ntens
                WRITE(*,*) DDSDDE(q1,:)
            END DO
       ..........
        !
        DO q1=1,3
            DO q2=1,3
                IF (iSnAN(DFGRD0(q1,q2))) THEN
                    DFGRD0(q1,q2)=0
                END IF
            END DO
        END DO
        g1=matmul(DFGRD0,g1_0)
      .....
        p_(1)=sqrt(dot_product(g1,g1))*p_0(1)
    !    WRITE(*,*) 'p_(1) dotproduct' ,p_(1)
       ....
    Some remarks:
    1)As you see, instead of using the aba_param_dp.inc file I used the IMPLICIT NONE , typical f90 declaration.
    2)The suspicion Abaqus cannot export variables in f90 files should have come from the fact I had to declare them all in the subroutine's declaration part: real::dtime ; integer::ntens ; etc.
    3)Towards the end of the exerpt, I used f90 functions like matmul and dot_product ( I don't know if IsNan is f90-only too).

    So, here I pose a new question: is there a way to adapt Abaqus to interact correctly with f90 subroutines? After all, Intel Fortran compiler works fine with all fortran editions up to f08, so it is not a compiler problem..

  4. #4
    Hello barabba,

    what abaqus version do you use?

    I programmed also some umat subroutines in F2003 and they are working perfectly with abaqus 6.11.

    You should test your subroutines with an own fortran program. I thick you will get compiler errors.

    Perhaps you can try the following declaration part:
    Code:
    subroutine umat(stress, statev, ddsdde, sse, spd, scd, rpl, ddsddt, drplde, drpldt, stran, dstran,   &
                    time, dtime, temp, dtemp, predef, dpred, cmname, ndi, nshr, ntens, nstatv, props,   &
                    nprops, coords, drot, pnewdt, celent, dfgrd0, dfgrd1, noel, npt, layer, kspt, kstep, kinc)
    
    implicit none
    
      integer               :: kstep, kspt, layer, npt, noel, nprops, nstatv, ntens, nshr, ndi, kinc
      double precision :: sse, spd, scd, rpl, drpldt, dtime, temp, dtemp, pnewdt, celent
      double precision, dimension(3, 3) :: dfgrd0, dfgrd1, drot 
      double precision, dimension(2) :: time
      double precision :: stress(ntens), ddsdde(ntens, ntens), ddsddt(ntens), drplde(ntens),  &
                                     stran(ntens), dstran(ntens), predef(1), dpred(1), props(nprops), coords(3)
      double precision, dimension(nstatv) :: statev
      character(len=80) :: cmname 
    
      !!! local decarations
      integer :: ....
    After you have tested the umat with an separate program you can generate an object file with the compiler and give it to ABQ.

    Regards, Viktor

  5. #5
    I use abaqus 6.10.

    I tried to modify the declaration part with your premise, I compiled it without linking, but in the end unfortunately my Abaqus does not look to work with user subroutines in .obj format, apparently.

    It gives me back the following error message in the .log file:

    Abaqus JOB umat_
    Abaqus 6.10-1
    Begin Linking Abaqus/Standard User Subroutines
    8/16/2012 7:22:52 PM
    Creating library standardU.lib and object standardU.exp
    standardU_static.lib(umat.obj) : error LNK2005: _UMAT already defined in subroutine_abaqus_2.obj
    standardU.dll : fatal error LNK1169: one or more multiply defined symbols found
    Abaqus Error: Problem during linking - Abaqus/Standard User Subroutines.
    This error may be due to a mismatch in the Abaqus user subroutine arguments.
    These arguments sometimes change from release to release, so user subroutines
    used with a previous release of Abaqus may need to be adjusted.
    Abaqus/Analysis exited with errors

Similar Threads

  1. How can I use the UMAT subroutine in ABAQUS CAE
    By j.suebsuk in forum Finite Element Modeling
    Replies: 3
    Last Post: 2012-06-02, 15:07
  2. Accessing displacement values within VDLOAD subroutine
    By skiller in forum Finite Element Modeling
    Replies: 0
    Last Post: 2011-06-29, 12:41
  3. Help on ABAQUS UMAT subroutine
    By biomechanics in forum Finite Element Modeling
    Replies: 19
    Last Post: 2011-02-20, 10:45
  4. Strange problem using umat w Abaqus
    By kvemaganti in forum Computer Software
    Replies: 2
    Last Post: 2009-04-14, 20:18
  5. UMAT DFGRD0-1 and ELEMENT
    By Ratatosk in forum Finite Element Modeling
    Replies: 5
    Last Post: 2005-02-13, 16:54

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •