UEL subroutine problem reading "coords" variable
UEL subroutine problem reading "coords" variable
(OP)
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):
and my UEL for file starts with the typical structure:
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:
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!
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-------------------------- I'm a bit lost as to why this is happening and was hoping someone could shed some light.
Thank you very much!





RE: UEL subroutine problem reading "coords" variable
Could you post source code of "debug_matriz", please?
Regards,
Bartosz
VIM filetype plugin for Abaqus
https://github.com/gradzikb/vim-abaqus
RE: UEL subroutine problem reading "coords" variable
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 endDo you think it may be the problem?
Thank you.
RE: UEL subroutine problem reading "coords" variable
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
https://github.com/gradzikb/vim-abaqus
RE: UEL subroutine problem reading "coords" variable
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
Changing it to
CODE
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.
RE: UEL subroutine problem reading "coords" variable
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
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
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 UELRegards,
Bartosz
VIM filetype plugin for Abaqus
https://github.com/gradzikb/vim-abaqus