Continue to Site

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

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

UEL subroutine for a Heat Transfer Element

Status
Not open for further replies.

nekovolta

Mechanical
Mar 20, 2012
8
Hi,

I am writing a UEL subroutine in which I try to reproduce the Standard element for a heat transfer problem. The element that I am trying to implement is a four nodes tetrahedron, which would be the DC3D4 element in element library of Abaqus.

The UEL subroutine works, but when I compare the results with the same problem but using the DC3D4 element, it is not the same. I have checked the UEL subroutine a hundreds of times (formulation, shape functions, etc.) but I do not find the problem.

Could anyone suggest what I could do? How can I detect the error?

If you want, I can give you the scripts I am using, in case you also want to try.
 
Replies continue below

Recommended for you

Hi nekovolta,

I suggest you that you take a simple example, for instance a cube to check that everything is ok. It will probably help to identify the problem. By the way, where is the problem? The nodal temperatures are not correct, the fluxes...?

As IceBreakerSours indicates, if you upload your code we might be more helpful.

 
Hi,

thanks for your comments.

eng23bio: as you said, I tried only with one element, with is just a tetrahedron. Please, find attached the files for both problem: the file called 'tetra_ht.inp' is the problem WITHOUT subroutine, using the DC3D4 element of Abaqus. The other two files, 'tetra_UEL.inp' and 'UEL_calor.for' are the INP file and subroutine for the same problem but defining the element through an UEL subroutine.

The problem that I found is that when I compare both problems (using CD3D4 element vs. UEL element) the nodal temperatures are differents.

I would really appretiate if anyone of you have a look to these files and see what is wrong. Thank you very much in advance!
 
 http://files.engineering.com/getfile.aspx?folder=8560da40-6977-4692-a546-f457c0f71eb2&file=Files.rar
Did you write the code? This is one of the oddest things I've ever seen. I don't see a single write command in the subroutine! Also, I noticed the code formatting was messed up, but that may be editor/formatting/uploading-related issue.

Bottomline:

a) You need to use write command as often as you can to test parts of your code sequentially.
b) You may write a separate small piece of Fortran code which calls a given routine by providing the information it needs and writing output from within that routine. This technique will let you test each individual piece with known/provided input.
c) Finally, at least in Visual Studio, if it is set up correctly, you may use the VS debugging tools - while the solver is running.

Are you new to this forum? If so, please read these FAQ:

 
Well, I wrote part of it, but I have to say that I am not an expert with subroutines, as you can see. The thing is that, I took this subroutine from another person and I adapted it for the heat transfer problem I am trying to solve. I understand your impression with this because when I took it I also didn't understand why it was so bar organized.

About you comments:

a) about the write command - I don't know what you mean when you say "use write command". What I do, is to user the coman PRINT*,'', to check something I am interested in. Maybe your suggestion is easier, but please, could you give me an example of the use of write command?

b) I think that the subroutine is already organized in the way you said. There is a main subroutine that call other small pieces of code. Did you mean this?

c) I don't know how to use the VS debugging tool.
 
I fixed the formatting for you. See attached. By the way, it may still look different for you because of the editor; I use Notepad++.

a) There is plenty of information available online.
b) No; what you have now is *not* what I meant. However, the idea is, in principle, the same. See this:

Code:
      PROGRAM TEST
       INTEGER :: x,t,y,z
       INTEGER :: tmin, tmax, tinc	   
       INTEGER :: xmin, xmax, xinc
       INTEGER :: ymin, ymax, yinc
       INTEGER :: zmin, zmax, zinc
       DIMENSION COORDS(3), TIME(2)
       CHARACTER(LEN=80):: SNAME
!
       tmin = 0
       tmax = 10
       tinc = 1
       xmin = 0
       xmax = 10
       xinc = 2
       ymin = 0
       ymax = 10
       yinc = 5
       zmin = 0
       zmax = 10
       zinc = 2
!
       KSTEP=1
       KINC=1
       NOEL=1
       NPT=1
       LAYER=1
       KSPT=1
       JLTYP=1
       SNAME='test'
!
       OPEN(UNIT=10,FILE='test.out')
!
       DO t = tmin,tmax,tinc
        TIME(1) = t
        DO x = xmin,xmax,xinc
         COORDS(1) = x
         DO y = ymin,ymax,yinc
          COORDS(2) = y
          DO z = zmin,zmax,zinc
           COORDS(3) = z
            CALL DLOAD (F,KSTEP,KINC,TIME,NOEL,NPT,LAYER,KSPT,COORDS, & 
            JLTYP, SNAME)
           WRITE (10,*) t,x,y,z,F
      20 FORMAT(5(2X,E16.9))
          END DO
         END DO
        END DO
       END DO
      END PROGRAM TEST

This piece of code was suggested to test the DLOAD subroutine. You could use a similar trick.

c) Again, do some online search.

Are you new to this forum? If so, please read these FAQ:

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor