Compilation error in UMAT subroutine

[nik@cabana]

Hi Everybody,
I am trying to use UMAT subroutine (described as follows) with Abaqus FEA (CAE) software. When Intel Fortran compiler call UMAT, it is giving compilation error. Can somebody please help me in fixing this? What is wrong in the following subroutine that's why I am getting compilation error? Any help on this issue would be appreciated,
Thanks in advance,

Nik




SUBROUTINE UMAT(STRESS,STATEV,DDSDDE,SSE,SPD,SCD,
1 RPL,DDSDDT,DRPLDE,DRPLDT,
2 STRAN,DSTRAN,TIME,DTIME,TEMP,DTEMP,PREDEF,DPRED,CMNAME,
3 NDI,NSHR,NTENS,NSTATV,PROPS,NPROPS,COORDS,DROT,PNEWDT,
4 CELENT,DFGRD0,DFGRD1,NOEL,NPT,LAYER,KSPT,KSTEP,KINC)
C
INCLUDE 'ABA_PARAM.INC'
C
real :: EMOD,ENU,EBULK3,EG2,EG,EG3,ELAM
integer :: K1,K2
CHARACTER*80 CMNAME
DIMENSION STRESS(NTENS),STATEV(NSTATV),
1 DDSDDE(NTENS,NTENS),DDSDDT(NTENS),DRPLDE(NTENS),
2 STRAN(NTENS),DSTRAN(NTENS),TIME(2),PREDEF(1),DPRED(1),
3 PROPS(NPROPS),COORDS(3),DROT(3,3),DFGRD0(3,3),DFGRD1(3,3)

!This code is written to simulate Isotropic Isothermal Elasticity, which is nothing but uniform elastic model from Abaqus
!PROPS(1) = E; Young's modulus of the material
!PROPS(2) = nu; Poission's ratio of the material
!Please note this code is not applicable for plane stress conditions as the stiffness matrix is different for them
!if (NDI/=3) then
! write(7,*) 'This UMAT only be used for elements with 3D'
! call XIT
!endif

!Elastic Properties definition
EMOD=PROPS(1)
ENU=PROPS(2)
EBULK3=EMOD/(1-2*ENU)
EG2=EMOD/(1+ENU)
EG=EG2/2
EG3=3*EG
ELAM=(EBULK3-EG2)/3

do K1= 1, NDI
do K2= 1,NDI
DDSDDE(K2,K1)=ELAM
end do
DDSDDE(K1,K1)=EG2+ELAM
end do
do K1= NDI+1, NTENS
DDSDDE(K1,K1)=EG
end do

!This part calculates stress based on element stiffness matrix and engineering strain
do K1=1, NTENS
do K2=1, NTENS
STRESS(K2)=STRESS(K2)+DDSDDE(K2,K1)*DSTRAN(K1)
end do
end do

RETURN
END

[Richard Maine]

nik@cabana <nikhil...@gmail.com> wrote:

> it is giving compilation error.

Boy, there sure has been a spate of cases of his error recently.
The error in question is failing to say exactly what the compilation
error is. I'm frankly not inclined to even bother looking at the code
if you can't be bothered to be more specific about the error. Looking
for an unspecified error is at least an order of magnitude more work
than explaining a specific compilation error. If you want people to help
you, make it easier for them to do so.

I'll give you credit for at least posting the code. Well, most of the
code anyway. I do note that the code includes an aba_param.inc file with
unspecified content which might well be critical.

It's better than the occasional "My unspecified code got some sort of
unspecified error; does anyone know why?"

--
Richard Maine
email: last name at domain . net
dimnain: summer-triangle

[nik@cabana]

dis what I got:
Error in job Job-4: Problem during compilation - C:\Users\nikhildlondhe\Documents\Visual Studio 2013\Projects\UMAT_Trials\UMAT_Trials\UMAT.for
Job Job-4 aborted due to errors.

[campbel...@gmail.com]

On Wednesday, September 23, 2015 at 11:39:07 AM UTC+10, nik@cabana wrote:
>
> dis what I got:
> Error in job Job-4: Problem during compilation - C:\Users\nikhildlondhe\Documents\Visual Studio 2013\Projects\UMAT_Trials\UMAT_Trials\UMAT.for
> Job Job-4 aborted due to errors.
>

This error message provides little information.
To me your code should compile but likely give incorrect results.
I expect you have
* not initialised key variables correctly or
* defined the correct variable kind, 4 byte integers and 8 byte reals

Below are some suggestions, which you should review and then correct.
I would expect that DDSDDT and STRESS are not provided with initial values, although I could be wrong on this ?

SUBROUTINE UMAT (STRESS,STATEV,DDSDDE,SSE,SPD,SCD,

1 RPL,DDSDDT,DRPLDE,DRPLDT,
2 STRAN,DSTRAN,TIME,DTIME,TEMP,DTEMP,PREDEF,DPRED,CMNAME,
3 NDI,NSHR,NTENS,NSTATV,PROPS,NPROPS,COORDS,DROT,PNEWDT,
4 CELENT,DFGRD0,DFGRD1,NOEL,NPT,LAYER,KSPT,KSTEP,KINC)
C

! INCLUDE 'ABA_PARAM.INC' ! this was not provided; and not required ??
C
C declare argument types explicitly ; is this correct ?
C I would expect 8 byte reals and 4 byte integers ??
INTEGER*4 NDI,NSHR,NTENS,NSTATV,NPROPS,
1 NOEL,NPT,LAYER,KSPT,KSTEP,KINC
real*8 SSE,SPD,SCD,RPL,DRPLDT,DTIME,TEMP,DTEMP,PNEWDT,CELENT
real*8 STRESS(NTENS),STATEV(NSTATV),

1 DDSDDE(NTENS,NTENS),DDSDDT(NTENS),DRPLDE(NTENS),
2 STRAN(NTENS),DSTRAN(NTENS),TIME(2),PREDEF(1),DPRED(1),
3 PROPS(NPROPS),

4 COORDS(3),DROT(3,3),DFGRD0(3,3),DFGRD1(3,3)
C
real*8 :: EMOD,ENU,EBULK3,EG2,EG,EG3,ELAM
integer*4 :: k, K1,K2
CHARACTER :: CMNAME*80

C !This code is written to simulate Isotropic Isothermal Elasticity, which is nothing but uniform elastic model from Abaqus
C !PROPS(1) = E; Young's modulus of the material
C !PROPS(2) = nu; Poission's ratio of the material
C !Please note this code is not applicable for plane stress conditions as the stiffness matrix is different for them
C !if (NDI/=3) then
C ! write(7,*) 'This UMAT only be used for elements with 3D'
C ! call XIT
C !endif
C
C !Elastic Properties definition
EMOD = PROPS(1)
ENU = PROPS(2)
EBULK3 = EMOD/(1-2*ENU)
EG2 = EMOD/(1+ENU)
EG = EG2/2
EG3 = 3*EG
ELAM = (EBULK3-EG2)/3

DDSDDE = 0 ! ##### zero values must first be initialised
do k = 1, NDI
DDSDDE(1:NDI,K) = ELAM
DDSDDE(K,K) = EG2+ELAM
end do
do K = NDI+1, NTENS
DDSDDE(K,K) = EG
end do

C !This part calculates stress based on element stiffness matrix and engineering strain only ??
do K = 1, NTENS
STRESS(K) = 0 ! #### is this stress component added to input STRESS(:) provided ??
! do K1=1, NTENS
! STRESS(K2)=STRESS(K2)+DDSDDE(K2,K1)*DSTRAN(K1)
! end do
STRESS(K) = STRESS(K) + DOT_PRODUCT (DDSDDE(:,K),DSTRAN(:)) ! DDSDDE is symmetric
end do
C
RETURN
END

[Richard Maine]

Hmm. Not a very useful message, I'll grant. But you get credit for
quoting it anyway. This looks like an error from some script that
invokes the compiler, rather than from the compiler itself. There might
be the actual compiler messages sitting in a file somewhere, but I can't
off-had tell you where that might be. In any case, it merits at least
some of my attention now. Hmm...

I copied the code into a file and it compiled fine for me with both
gfortran and clf, after 2 simple edits.

1. I appropriately indented the first line,

and

2. Not having much idea what might be in aba_param.inc, I commented out
that include.

This does suggest several possibilities.

1. Note my comment about about appropriately indenting the first line.
The code is clearly in fixed source form. That source form requires that
all statements start in column 7 or later. Your subroutine statement
appears to start in column 1. That might possibly be an artifact of how
you cut&pasted it into your post, but if it really starts in column 1,
that's definitely a problem.

2. The code being fixed source form, as noted, you need to tell the
compiler that one way or another. That is most commonly done by naming
the file with a .f90 extension, though compiler options exist to deal
with other extensions. Either of these possibilities would relate to
whatever script is used to invoke the compiler; I wouldn't know what
that script look slike.

3. I mentioned commenting out the include line. The problem could
concievably relate to whatever is in the aba_param.inc file (or in that
file not existing). I don't have enough information to investigate that
further.

These certainly aren't the only possibilities, but they are what ocur to
me from the data available.

See also some o fthe comments from campbelljohnd01. Those issues
shouldn't case compilation errors, but they might cause you to get wrong
results. (And I disagree with one aspect of his comments - the
recommendation to use nonstandard real*8 and integer*4 syntax for
declarations).

[FortranFan]

On Tuesday, September 22, 2015 at 11:12:05 PM UTC-4, Richard Maine wrote:

> ..

>
> 2. The code being fixed source form, as noted, you need to tell the
> compiler that one way or another. That is most commonly done by naming
> the file with a .f90 extension, though compiler options exist to deal

> with other extensions. ..

I assume you meant .for extension for fixed source form and .f90 for free form.

> ..
> See also some o fthe comments from campbelljohnd01. .. (And I disagree with one aspect of his comments - the

> recommendation to use nonstandard real*8 and integer*4 syntax for
> declarations).
>

Uh oh, off could go this thread! Perhaps Richard Maine can convince the author of these other comments to move away from real*8 and integer*4 syntax, but much ink has been spilled in the past to no avail!

[Richard Maine]

FortranFan <pare...@gmail.com> wrote:

> On Tuesday, September 22, 2015 at 11:12:05 PM UTC-4, Richard Maine wrote:

> > 2. The code being fixed source form, as noted, you need to tell the
> > compiler that one way or another. That is most commonly done by naming
> > the file with a .f90 extension, though compiler options exist to deal
> > with other extensions. ..
>
> I assume you meant .for extension for fixed source form and .f90 for free
form.

Oops. Yes, I said it backwards, though I'm more used to .f than .for for
fixed form. But definitely not .f90.

[Richard Maine]

Nah. If someone is dead set on using that syntax, I'm not going to waste
my time arguing. I have better things to do. Let's see, I was just in
the middle of replaying Fallout New Vegas - that counts as something
better to do. :-) Or I could go work on cleaning up the garage, which
would still be more fun than fruitless arguments.

But when it is offerred to novices as a suggestion, I will at least
mention that there are experienced people who disagree with the
suggestion.

[campbel...@gmail.com]

The precision (Fortran KIND) of variables you will be using is defined in the file 'ABA_PARAM.INC' that has been configured for your install. (I'd be interested to see what it is.) As such, you must use this INCLUDE statement.

I suggest that you review the precision that you are selecting for the Abaqus install you have and use the kind declarations as they are included there.

My recommendation was to code as if IMPLICIT NONE was selected, however the examples don't show that and you may be better to code as the example. (Hopefully reference to IMPLICIT NONE doesn't cause a problem.)

You need to confirm if STRESS has been supplied with an initial stress value (possibly zero) or if you should set it to zero.

[glen herrmannsfeldt]

Richard Maine <nos...@see.signature> wrote:
> nik@cabana <nikhil...@gmail.com> wrote:

>> it is giving compilation error.

> Boy, there sure has been a spate of cases of his error recently.
> The error in question is failing to say exactly what the compilation
> error is. I'm frankly not inclined to even bother looking at the code
> if you can't be bothered to be more specific about the error. Looking
> for an unspecified error is at least an order of magnitude more work
> than explaining a specific compilation error. If you want people to help
> you, make it easier for them to do so.

This reminds me of a story from years ago of a compiler that
just said "SYNTAX ERROR" without any more details for any error.
I don't remember if it even gave the line number.

But that is rare now.

No excuse for compilers that actually do give messages.

-- glen

[Paul Anton Letnes]

Look in the "output" window in visual studio. It should show a blue link to the log file (mine does). Post all of its contents.

I suspect a link-time error, byt that's a loooong shot.

Paul

[campbel...@gmail.com]

I have reviewed some available documentation and found the following:

http://imechanica.org/files/Writing%20User%20Subroutines%20with%20ABAQUS_0.pdf

It appear fairly comprehensive, although some on this forum might not accept it's recommendations when it discusses 'ABA_PARAM.INC' stating:
"The include statement sets the proper precision for floating point variables (REAL*8 on most machines)."

[Richard Maine]

glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

> This reminds me of a story from years ago of a compiler that
> just said "SYNTAX ERROR" without any more details for any error.
> I don't remember if it even gave the line number.

That's about like my recollection of IBM JCL. I'd get a job back and the
only thing I could understand about it was "Job not run. JCL error."
Yes, there was also about a whole page of gobbledygook, just as there
was when the jobs ran normally, but none of it made much sense to me to
the extent that I couldn't even tell what of it might be an error
message. So I'd just examine my deck to see what might be wrong based on
no more clue than "Job not run. JCL error." Yes, I was quite a bit
younger at the time; that would heve been around undergrad school, about
45 years ago.

[FortranFan]

On Tuesday, September 22, 2015 at 9:39:07 PM UTC-4, nik@cabana wrote:

> ..

>
> dis what I got:
> Error in job Job-4: Problem during compilation - C:\Users\nikhildlondhe\Documents\Visual Studio 2013\Projects\UMAT_Trials\UMAT_Trials\UMAT.for
> Job Job-4 aborted due to errors.
>

@Nik,

Is the information on this site on Abaqus 6.13 relevant to what you're doing? Have you gone through such documentation to try to help yourself?
http://129.97.46.200:2080/v6.13/books/usb/default.htm

Abaqus appears to be a commercial program. It probably has its own customer support site and possibly a user forum. You should look into it and try to get your answers there.

Your issues may have less to do with Fortran than with the intricacies and details of Abaqus. You should clear everything up first with Abaqus. There might be some worked out examples that you should try to reproduce exactly as expected so you know your setup and configuration, etc. are correct.

[Richard Maine]

Link-time error had occurred to me also. I was thinking of trivia like
invoking ifort without the -c switch, but I decided that the script
probably got that part right so it wasn't worth mentioning. But now that
you bring it up, it occurs to me that another possibility might be wrong
precision in the arguments. I seem to recall that on some platforms,
ifort encoded total argument length information into mangled procedure
names, which could cause link-time errors if you had the kinds wrong.
I'd believe that one.

[robin....@gmail.com]

On Wednesday, September 23, 2015 at 11:15:49 AM UTC+10, nik@cabana wrote:
> Hi Everybody,
> I am trying to use UMAT subroutine (described as follows) with Abaqus FEA (CAE) software. When Intel Fortran compiler call UMAT, it is giving compilation error.

What is the error message?

[glen herrmannsfeldt]

Richard Maine <nos...@see.signature> wrote:
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

>> This reminds me of a story from years ago of a compiler that
>> just said "SYNTAX ERROR" without any more details for any error.
>> I don't remember if it even gave the line number.

> That's about like my recollection of IBM JCL. I'd get a job back and the
> only thing I could understand about it was "Job not run. JCL error."

As with Fortran 66, I learned pretty fast the way JCL worked,
so mostly avoided that. Well, for one, double checking for the
usual typegraphic errors.

> Yes, there was also about a whole page of gobbledygook, just as there
> was when the jobs ran normally, but none of it made much sense to me to
> the extent that I couldn't even tell what of it might be an error
> message. So I'd just examine my deck to see what might be wrong based on
> no more clue than "Job not run. JCL error." Yes, I was quite a bit
> younger at the time; that would heve been around undergrad school, about
> 45 years ago.

That might be about the way I did it, too. But often enough
also for Fortran 66. Often, just knowing which statement it was in,
I would figure out the error.

Fortran H tells the column number where the error was detected, but
faster than counting, I could usually find it.

One interesting JCL error when using WYLBUR comes from putting
in lower case letters, which JCL doesn't recognize at all.
Then debugging from printed output which maps lower to upper case.

-- glen

[Jos Bergervoet]

On 9/24/2015 7:10 AM, glen herrmannsfeldt wrote:
> Richard Maine <nos...@see.signature> wrote:
>> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
>>> This reminds me of a story from years ago of a compiler that
>>> just said "SYNTAX ERROR" without any more details for any error.
>>> I don't remember if it even gave the line number.
>
>> That's about like my recollection of IBM JCL. I'd get a job back and the
>> only thing I could understand about it was "Job not run. JCL error."
>
> As with Fortran 66, I learned pretty fast the way JCL worked,
> so mostly avoided that.

When I was a student we were clearly told we didn't need
to know such things, by our professor (R.I.P. Kees Koster
https://en.wikipedia.org/wiki/Cornelis_H._A._Koster )
So the real computer nerds immediately saw the opportunity
and printed out the "JCL primer" and started vividly
discussing it, completely incomprehensible to physics nerds
or math hippies hanging around, who already had their own
secret worlds of course. Thanks to JCL now things were even
again!

--
Jos