Continue to Site

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

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

UEL subroutine problem reading "coords" variable

Status
Not open for further replies.

marscosta

Mechanical
Oct 2, 2013
3
So I'm building a UEL subroutine and I'm having a basic problem: the coordinates of the nodes of my custom element are not being read correctly.

In my inp file I have a simple model (two solid elements and one cohesive zero-thickness element):
Code:
*Node
 1, 0.,0.,
 2, 1.,0.,
 3, 0.,1.,
 4, 1.,1.,
 5, 0.,1.,
 6, 1.,1.,
 7, 0.,2.,
 8, 1.,2.,
*Element, type=CPE4 
 1, 1,2,4,3, 
 2, 5,6,8,7 
*USER ELEMENT,TYPE=U1,NODES=4
 1,2
*ELEMENT,TYPE=U1
 3,3,4,5,6
*ELSET,ELSET=INTER
 3
*UEL PROPERTY,ELSET=INTER
 7.2, 4.6

and my UEL for file starts with the typical structure:

Code:
      subroutine uel(rhs,amatrx,svars,energy,
     1     ndofel,nrhs,nsvars,props,nprops,coords,
     2     mcrd,nnode,u,du,v,a,jtype,time,dtime,
     3     kstep,kinc,jelem,params,ndload,jdltyp,
     4     adlmag,predef,npredf,lflags,mlvarx,
     5     ddlmag,mdload,pnewdt,jprops,njprop,
     6     period)

      include 'ABA_PARAM.INC'

      dimension rhs(mlvarx,*),
     1     amatrx(ndofel,ndofel),
     2     svars(nsvars),energy(8),props(*),
     3     coords(mcrd,nnode),u(ndofel),
     4     du(mlvarx,*),v(ndofel),a(ndofel),
     5     time(2),params(3),jdltyp(mdload,*),
     6     adlmag(mdload,*),ddlmag(mdload,*),
     7     predef(2,npredf,nnode),lflags(*),
     8     jprops(*)
      
      parameter ( ngauss=2, debug=1 )
      
      call debug_matriz(U,1,ndofel,'D:\test1.txt','U')
      call debug_matriz(coords,mcrd,nnode,'D:\test1.txt','coords')

where debug_matriz is a custom function to write the contents of the matrix to a file. According to the documentation, coords should be an array containing the original coordinates of the nodes, so I would expect a result similar to the node positions I defined in my .inp file. But the result is that coords actually has the following:

Code:
 -coords--------------------------
             0.00000             0.00000             0.00000             0.00000
             0.00000             1.87500             1.87500             1.87500
 -/coords--------------------------
where each column corresponds to one node and each line is the coordinate for that node. Basically it's telling me that the coordinates for node 3 (inp file) is (0,0), and remaining nodes are (0,1.875).

I'm a bit lost as to why this is happening and was hoping someone could shed some light.

Thank you very much!
 
Replies continue below

Recommended for you

Hello akabarten,

This is the code:

Code:
      subroutine debug_matriz(A,n,m,B,C)
      include 'ABA_PARAM.INC'
      real, dimension(n,m) :: A
      character(len=*), intent(in) :: B
      character(len=*), intent(in) :: C
      
      
      open(unit=2, file=B, ACTION="write")
      write(2,*),'-' // C // '--------------------------'
      do i=1,n
            write(2, '(1000F20.5)')( real(A(i,j)) ,j=1,m)
      end do
      write(2,*),'-/' // C // '--------------------------'
      return
      end

Do you think it may be the problem?

Thank you.
 
Hi,

I do not see a mistake but if I were you I would do following:
1. Change unit number. Unit 2 is already used by Abaqus/Standard.
Abaqus Analysis User's Guide, 3.7.1 FORTRAN unit numbers used by Abaqus.
2. Change "debug_matriz" subroutine name to start with "k" letter
Abaqus Analysis User's Guide, 18.1.1 User subroutines: overview, Naming convention
3. Try print "coords" without extra subroutine. Just put into UEL "write(6, coords)" and see what is write to *.dat file

Regards,
Bartosz



VIM filetype plugin for Abaqus
 
Hello akabarten,

You were right, the problem was the debug function. After printing the contents of coords without any assist the coordinates were correctly printed.

Upon debugging, the culprit was:

Code:
real, dimension(n,m) :: A

Changing it to

Code:
dimension A(n,m)

Fixed the problem. Now I'm a bit confused at why the previous declaration is producing such errors, as I use the same type of variable declaration in other points of my UEL. Should I always use the later type? If so why?

Thank you very much for helping me solve this.
 
Hi,

Abaqus use implicit variable declaration base on variable names.
What is integer, real of character is defined in "aba_param.inc" file included in each Abaqus subroutine.
To be more precise you will not find "aba_param.inc" file in your abaqus installation directory.
Instead you can find two files "aba_param_sp.inc" and "aba_param_dp.inc".
First one is used when you run single precision abaqus and the second one with double precision abaqus.

Code:
real, dimension(n,m) :: A
With explicit declaration you always use real*4 for coords array.
Abaqus will use real*4 for single precision execution and real*8 for double precision execution (depend which file is included *_sp.inc or *_dp.inc).
In one case your subroutine works (real*4 in UEL vs real*4 in debug_matriz) in other it will generate numerical garbage (real*8 in UEL vs real*4 in debug_matriz).

Code:
dimension A(n,m)
With implicit declaration you agree abaqus controls variable type and precision.
It will ensure your variable and abaqus variable are consistent.
But be carful here. The variable name make a difference!
In UEL coords array start with c so it is real (single od double).
Let's assume you do not use name A in subroutine but N. All variable which starts with n are integers.
So coords in UEL is real array and passed into your debug subroutine it will be read as integer array.

Remember you have access only to part of the code, you have access to UEL definition but not to UEL call block.
In other words you have no option to check and/or control what type of variable is passed from abaqus to UEL subroutine.
Using implicit declaration and "aba_param.inc" file is option to ensure your variables and abaqus variables use the same type and/or precision.

Of course such limitation are related only to UEL (or any other abaqus subroutine) dummy arguments like (rhs,amatrx,svars,energy,...).
My advice for abaqus subroutine variables please use implicit declaration for other variables implicit or explicit.
You can also try use internal subroutine. Such subroutine has access to variables of level up and you do not have to make declaration.

Code:
subroutine UEL(rhs,amatrx,svars,energy...)

  include 'ABA_PARAM.INC'

  ...
  UEL declaration block
  ...
  
  ! call internal subroutine 
  call debug_matriz('D:\test1.txt','coords') 

contains

  subroutine debug_matriz(B,C)
 
      character(len=*), intent(in) :: B
      character(len=*), intent(in) :: C
            
      open(unit=2, file=B, ACTION="write")
      write(2,*),'-' // C // '--------------------------'
      write(2,*) coords(mcrd,nnode)
      write(2,*),'-/' // C // '--------------------------'
      return

  end subroutine debug_matriz

end subroutine UEL
As you can see I did not pass coords array with dummy arguments since I have direct access to all variables level up.

Regards,
Bartosz

VIM filetype plugin for Abaqus
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor