Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

UMAT compilation error: dgsev, x04caf, ddisna

baayec
Beginner
1,784 Views

Hello dear community,

This is my first post. I am running a UMAT on a Windows computer for Abaqus FEA. The UMAT is written with VisualStudio2015 and I use IntelFortran2018 to compile it. I am facing errors during compilation.

End Compiling Abaqus/Standard User Subroutines
Begin Linking Abaqus/Standard User Subroutines
Creating library standardU.lib and object standardU.exp
KSBmodel_UMAT.obj : error LNK2019: unresolved external symbol dgesvd referenced in function non0norm
KSBmodel_UMAT.obj : error LNK2001: unresolved external symbol ddisna
KSBmodel_UMAT.obj : error LNK2001: unresolved external symbol x04caf
standardU.dll : fatal error LNK1120: 3 unresolved externals
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.

Do you have any idea of how I could solve the problem?

0 Kudos
17 Replies
Greg_T_
Valued Contributor I
1,784 Views

The error message mentions a possible mismatch in the subroutine arguments.  It is possible that the number of arguments in the UMAT subroutine have changed (depending on the version of Abaqus). Have you found the section in the Abaqus user's manual that gives the current UMAT argument list? 

Another possibility is a type mismatch, such as x86 versus x64 for the compiled user subroutine.  I would expect that the current version of Abaqus is expecting the user subroutine to be compiled for x64.

Do you have a main program that can call your UMAT subroutine to test that is compiles and runs outside of Abaqus?  I recommend using a separate project with a main program to test your UMAT so that you can confirm it compiles and runs for a range of inputs.  This should help narrow down the problem to a linking issue with Abaqus.

I have success linking user subroutines to Abaqus by opening the Intel command window so that the Fortran environment variables are initialized.  This will also let you select the x64 initialization.  From the Start menu: Intel Parallel Studio XE 2019 ->  Compiler 19.0 Update ...

Then change to the directory where the Abaqus input file and user subroutine are located, and run abaqus from this Intel console window.

If this doesn't help, you could access the on-line knowledge base at SIMULIA support, as there may be additional information there that could help.  If you have Abaqus support, they would be able to help too.  There are other "abaqus" related articles in the Intel Fortran forum, so a search on "abaqus" in this forum may provide other articles that could help too.

Regards, Greg

0 Kudos
baayec
Beginner
1,784 Views

Greg T. wrote:

The error message mentions a possible mismatch in the subroutine arguments.  It is possible that the number of arguments in the UMAT subroutine have changed (depending on the version of Abaqus). Have you found the section in the Abaqus user's manual that gives the current UMAT argument list? 

Another possibility is a type mismatch, such as x86 versus x64 for the compiled user subroutine.  I would expect that the current version of Abaqus is expecting the user subroutine to be compiled for x64.

Do you have a main program that can call your UMAT subroutine to test that is compiles and runs outside of Abaqus?  I recommend using a separate project with a main program to test your UMAT so that you can confirm it compiles and runs for a range of inputs.  This should help narrow down the problem to a linking issue with Abaqus.

I have success linking user subroutines to Abaqus by opening the Intel command window so that the Fortran environment variables are initialized.  This will also let you select the x64 initialization.  From the Start menu: Intel Parallel Studio XE 2019 ->  Compiler 19.0 Update ...

Then change to the directory where the Abaqus input file and user subroutine are located, and run abaqus from this Intel console window.

If this doesn't help, you could access the on-line knowledge base at SIMULIA support, as there may be additional information there that could help.  If you have Abaqus support, they would be able to help too.  There are other "abaqus" related articles in the Intel Fortran forum, so a search on "abaqus" in this forum may provide other articles that could help too.

Regards, Greg

 

Thank you Greg,

When I remove the part of the UMAT code with EXTERNAL DDISNA, X04CAF, DGESVD and the part where DGESVD is called, the code run. So I think that LAPACK  library not working properly with my Fortran. Do you have an idea of how to get LAPCK work automatically with visual/studio+Fortran compiling?

 

Regards,

 

Cisse

0 Kudos
mecej4
Honored Contributor III
1,784 Views

All of the missing subroutines are to be found in MKL (i.e., the Lapack part of MKL), and the linker uses MKL during a program (EXE or DLL) build only if the user specifies that MKL is to be used. 

Examine (and report here, if you have further questions) the linking command that the Abaqus batch file issues. If it does not specify the MKL libraries, that is an issue that will have to be addressed. If you use Visual Studio, one of the project options is to use MKL libraries at link time, and that option should be selected. Another possibility is to use  suitable INCLUDELIB directives in your source files.

cisse, cheikh wrote:
When I remove the part of the UMAT code with EXTERNAL DDISNA, X04CAF, DGESVD and the part where DGESVD is called, the code run.
. Well, that is as effective as avoiding compiler error messages by not compiling. The results of an Abaqus run with such a DLL (one that has necessary functionality removed) are probably of no use.

0 Kudos
baayec
Beginner
1,784 Views

mecej4 wrote:

All of the missing subroutines are to be found in MKL (i.e., the Lapack part of MKL), and the linker uses MKL during a program (EXE or DLL) build only if the user specifies that MKL is to be used. 

Examine (and report here, if you have further questions) the linking command that the Abaqus batch file issues. If it does not specify the MKL libraries, that is an issue that will have to be addressed. If you use Visual Studio, one of the project options is to use MKL libraries at link time, and that option should be selected. Another possibility is to use  suitable INCLUDELIB directives in your source files.

Quote:

cisse, cheikh wrote:

When I remove the part of the UMAT code with EXTERNAL DDISNA, X04CAF, DGESVD and the part where DGESVD is called, the code run.

. Well, that is as effective as avoiding compiler error messages by not compiling. The results of an Abaqus run with such a DLL (one that has necessary functionality removed) are probably of no use.

 

Thank you,

 

Actually the DGESVD is important for having correct values. When I included, I have added the following line in my code:

INCLUDE 'mkl_lapack.fi'

However, I get the following errors:

C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2017.2.187\windows\mkl\include\mkl_lapack.fi(27): error #5082: Syntax error, found '&' when expecting one of: * <IDENTIFIER>
      SUBROUTINE CGELQ( M, N, A, LDA, T, TSIZE, WORK, LWORK,            &
------------------------------------------------------------------------^
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2017.2.187\windows\mkl\include\mkl_lapack.fi(52): error #5082: Syntax error, found '&' when expecting one of: * <IDENTIFIER>
      SUBROUTINE CGEMLQ( SIDE, TRANS, M, N, K, A, LDA, T, TSIZE,        &
------------------------------------------------------------------------^
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2017.2.187\windows\mkl\include\mkl_lapack.fi(56): error #5082: Syntax error, found '&' when expecting one of: <IDENTIFIER> %FILL
      COMPLEX           A( LDA, * ), T( * ), C( LDC, * ),               &
------------------------------------------------------------------------^
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2017.2.187\windows\mkl\include\mkl_lapack.fi(63): error #5082: Syntax error, found '&' when expecting one of: * <IDENTIFIER>
      SUBROUTINE CGEMLQT( SIDE, TRANS, M, N, K, MB, V, LDV, T, LDT, C,  &
------------------------------------------------------------------------^
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2017.2.187\windows\mkl\include\mkl_lapack.fi(67): error #5082: Syntax error, found '&' when expecting one of: <IDENTIFIER> %FILL
      COMPLEX           V( LDV, * ), T( LDT, * ), C( LDC, * ),          &

Ant many others like this.

 

I when open the mkl_lapack.fi and rmove the extra '&' sign, it shows a sign error saying:

"error #5082: Syntax error, found END-OF-FILE when expecting one of: <LABEL> <END-OF-STATEMENT> ; TYPE INTEGER REAL COMPLEX BYTE CHARACTER CLASS DOUBLE ...
      END INTERFACE.

It is only one error but I don't know why it requires another END INTERFACE. I am even not sure if I should modify the "mkl_lapack.fi" which I believe has been developed by great engineers.

Thank you in advance

0 Kudos
mecej4
Honored Contributor III
1,784 Views

The errors that you reported in #5 are probably caused by a mismatch between the file extension of the source file that contains the include 'mkl_lapack.fi' and the source format. If the file ends with .f or .for, the source file should be in Fortran fixed form; if the file ends with .f90, the source file should be in Fortran free form. Furthermore, any included file, such as mkl_lapack.fi, should also be in the same form as the parent file into which its contents are being INCLUDEd.

In any case, it would be easier to help you if you reported, in addition to the error messages, the commands that produced those error messages.

0 Kudos
baayec
Beginner
1,784 Views

Thank you again macej4,

 

What do you mean by "If the file ends with .f or .for, the source file should be in Fortran fixed form"? 

My UMAT written with Visual Studio is a ".for" file. The MKL library is ".fi" file. Inside that file, the subroutine are written as

       INTERFACE
      SUBROUTINE (.....)

      END
      END INTERFACE

The library comes from intel MKL, and I was expecting it to be automatically compatible with Fortran/VStudio. 
Given that my UMAT is a ".for" file, what sould be the extension of the "mkl_lapack.fi" file?

Than you

0 Kudos
andrew_4619
Honored Contributor II
1,784 Views

The & at the end of the line is a fortran free format syntax for a continued line. This is  associated with the .f90 file type so if you have this in a .for file you will get errors.  The extension of the include file is not important. The compiler just pastes the contents of the include file into its parent. The actual contents of the include file must have a format (fixed or free) that is the same as the parent file. 

0 Kudos
baayec
Beginner
1,784 Views

andrew_4619 wrote:

The & at the end of the line is a fortran free format syntax for a continued line. This is  associated with the .f90 file type so if you have this in a .for file you will get errors.  The extension of the include file is not important. The compiler just pastes the contents of the include file into its parent. The actual contents of the include file must have a format (fixed or free) that is the same as the parent file. 

Thank you andrew,

When I download MKL from intel website et install it, I expect to be windows-compatible. If I understand your answer, I will have to change the ".fi" to ".for"?

How can i change the content of the include file to get it compatible with my ".for' UMAT file?

Thank you

0 Kudos
gib
New Contributor II
1,784 Views

As Andrew said "The extension of the include file is not important."  The problem is in the .for file that you created.  Because it uses & for line continuation, which is a Fortran90 feature, you need to tell the compiler that you are compiling a Fortran90 file by giving it the extension '.f90' instead of '.for'.

0 Kudos
baayec
Beginner
1,784 Views

gib wrote:

As Andrew said "The extension of the include file is not important."  The problem is in the .for file that you created.  Because it uses & for line continuation, which is a Fortran90 feature, you need to tell the compiler that you are compiling a Fortran90 file by giving it the extension '.f90' instead of '.for'.

Thank you gib,

Actually my issue is that Abaqus doe snot accept ".f90" UMAT. It has to be a ".for" file. The solution would be to know how to adapt the MKL files to works with the ".for" file. Is there a way to do it?

I have also tried another idea: I copied all the subroutine in the LAPACK and BLAS downloaded folders and past them in my UMAT.for directory, and modified their extension from ".f" to ".for". However, when I run the job, I get the following error:
"The CALL statement is invoking a function subprogram as a subroutine. [DGESVD]  CALL DGESVD('overwrite A by U','singular vector',M,N,A,---------------------------------------------------------------------------------------------------------^"

When I add 'INCLUDE 'DGESVD.for', it says that DGESVD cannot be included.

I also modified the Abaqus v6 environment file by adding '/Qmkl' after 'ifort', but i am getting the same error messages.

I am out of idea now

0 Kudos
gib
New Contributor II
1,784 Views

Sorry, I know nothing about Abacus and can't help.

0 Kudos
baayec
Beginner
1,784 Views

gib wrote:

Sorry, I know nothing about Abacus and can't help.

 

Thank you anyway, gib

0 Kudos
andrew_4619
Honored Contributor II
1,784 Views

I looked at mkl_lapack.fi in my install and it seems that it is written to work with fixed form or free format

col 1-6 are empty and & is used in column 6 as a continuation character. An ending & for continuation for free format is included in column 73 so should be ignored  by a fixed format compiler.

OP I think your compile must use a non-standard /extend-source:80 or /extend-source:132 compile option. rather than the default which is /noextend-source 

!      Intel(R) Math Kernel Library (Intel(R) MKL) Fortran interface for LAPACK routines
!*******************************************************************************

      INTERFACE
      SUBROUTINE CGELQ( M, N, A, LDA, T, TSIZE, WORK, LWORK,            &
     &                  INFO )
      IMPLICIT NONE
      COMPLEX           A( LDA, * ), T( * ), WORK( * )
      INTEGER           M, N, LDA, TSIZE, LWORK, INFO
      END
      END INTERFACE

 

0 Kudos
baayec
Beginner
1,784 Views

Thank you all,

I managed to solve the problem by modifying the Abaqus_v6.env  environement file.

For Windows, add after '/fpp', '/Qmkl:sequential', and '/free' after 'ifort' in the compiler option

For Linux, add -fpp, -free, and -mkl=sequential in the compiler option

 

 

 

 

 

0 Kudos
mecej4
Honored Contributor III
1,784 Views

The /free (or -free) option that you listed in #15 is appropriate only if the source file that you are compiling through Abaqus is, in fact, in free format. If you had shown enough of your source file to enable one to discern its source format, this whole thread could have been made much shorter.

In general, it is better to describe the relevant details and context than to list error messages. Likewise, it is far more effective to ascertain the appropriate compiler options by reasoning than to rely on recipes -- recipes whose applicability can be questionable. For building DLLs for use with Abaqus, the options recommended by the Abaqus vendor are appropriate only if the source form is also as recommended by Abaqus. If your source form deviates from that recommended form, you have to make appropriate changes to the options used.

The MKL option /Qmkl:sequential will prevent the MKL/Lapack routines called from the Abaqus-generated DLL from being executed in parallel. You have to ascertain whether the corresponding performance degradation is tolerable or if you should use a parallel version of MKL. 

0 Kudos
baayec
Beginner
1,784 Views

mecej4 wrote:

The /free (or -free) option that you listed in #15 is appropriate only if the source file that you are compiling through Abaqus is, in fact, in free format. If you had shown enough of your source file to enable one to discern its source format, this whole thread could have been made much shorter.

In general, it is better to describe the relevant details and context than to list error messages. Likewise, it is far more effective to ascertain the appropriate compiler options by reasoning than to rely on recipes -- recipes whose applicability can be questionable. For building DLLs for use with Abaqus, the options recommended by the Abaqus vendor are appropriate only if the source form is also as recommended by Abaqus. If your source form deviates from that recommended form, you have to make appropriate changes to the options used.

The MKL option /Qmkl:sequential will prevent the MKL/Lapack routines called from the Abaqus-generated DLL from being executed in parallel. You have to ascertain whether the corresponding performance degradation is tolerable or if you should use a parallel version of MKL. 

 

Thank you mecej4,

I modified to remove the '/free' in deed, with the '/free' there was a compilation error too. When I put only ''/Qmkl' only it does not work. It only works when I add '/Qmkl:sequential'. At least the thread helped me narrow my options search and found a working soultion

 

0 Kudos
Shen__Fei
Beginner
1,784 Views

baayec wrote:

Thank you all,

I managed to solve the problem by modifying the Abaqus_v6.env  environement file.

For Windows, add after '/fpp', '/Qmkl:sequential', and '/free' after 'ifort' in the compiler option

For Linux, add -fpp, -free, and -mkl=sequential in the compiler option

HI baayec,

 

Have you solved your problem?

Currently I also find a similar problem with using mkl functions (dgetrf and dgetri). After adding '/Qmkl:sequential' in the compile_fortran of the win86_64.env file, it still has two errors (error LNK2019: unresolved external symbol). I used abaqus2019+vs2015+ivf2018.

 

Do you have any idea on my problem? Thanks.

 

 

 

 

0 Kudos
Reply