- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have a fixed form code that I have used for almost 10 years now and never seen this issue before. I added 6 arguments to a subroutine:
Old:
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)
New:
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,
5 outputArray1,outputArray2,outputArray3,nsp1,nsp2,nsp3)
I changed the calls to the subroutine accordingly:
CALL UMAT(STRESS,STATEV,DDSDDE,SSE,SPD,SCD,RPL,DDSDDT,
1 DRPLDE,DRPLDT,STRAN,DSTRAN,TIME,DTIME,TEMP,DTEMP,
2 PREDEF,DPRED,CMNAME,NDI,NSHR,NTENS,NSTATV,PROPS,
3 NPROPS,COORDS,DROT,PNEWDT,CELENT,DFGRD0,DFGRD1,
4 NOEL,NPT,LAYER,KSPT,KSTEP,KINC,outputArray1,
5 outputArray2,outputArray3,nsp1,nsp2,nsp3)
The code compiles in Release as it should, but in Debug it says:
error #6784: The number of actual arguments cannot be greater than the number of dummy arguments. [UMAT] ...\modules_main.for 547
error #6784: The number of actual arguments cannot be greater than the number of dummy arguments. [UMAT] ...\modules_main.for 695
error #6784: The number of actual arguments cannot be greater than the number of dummy arguments. [UMAT] ...\modules_main.for 717
The 6 new outputs are defined with:
DIMENSION outputArray1(100),outputArray2(100),outputArray3(100)
integer :: nsp1,nsp2,nsp3
If I remove the 6 added arguments from everywhere, the code can compile as expected. If I remove the 6 added arguments from the subroutine calls (but leave it in the definition), the code can compile. And again the code can compile with the change in release but not in debug.
Does anyone have any ideas on how to fix this?
Jesse
PS. I have a new symptom. I was suspecting maybe it is exceeding the number of continuation lines (it shouldn't), so I changed the code to the following, it does not change the number of parameters, but now it only has 4 continued lines instead of 5:
CALL UMAT(STRESS,STATEV,DDSDDE,SSE,SPD,SCD,RPL,DDSDDT,
1 DRPLDE,DRPLDT,STRAN,DSTRAN,TIME,DTIME,TEMP,DTEMP,PREDEF,DPRED,
2 CMNAME,NDI,NSHR,NTENS,NSTATV,PROPS,NPROPS,COORDS,DROT,PNEWDT,
3 CELENT,DFGRD0,DFGRD1,NOEL,NPT,LAYER,KSPT,KSTEP,KINC,outputArray1,
4 outputArray2,outputArray3,nsp1,nsp2,nsp3)
I get new errors:
error #7983: The storage extent of the dummy argument exceeds that of the actual argument. [OUTPUTARRAY1] ...\modules_main.for 550
error #7983: The storage extent of the dummy argument exceeds that of the actual argument. [OUTPUTARRAY3] ...\modules_main.for 551
error #7983: The storage extent of the dummy argument exceeds that of the actual argument. [OUTPUTARRAY2] ...\modules_main.for 551
error #7983: The storage extent of the dummy argument exceeds that of the actual argument. [OUTPUTARRAY1] ...\modules_main.for 697
error #7983: The storage extent of the dummy argument exceeds that of the actual argument. [OUTPUTARRAY3] ...\modules_main.for 698
error #7983: The storage extent of the dummy argument exceeds that of the actual argument. [OUTPUTARRAY2] ...\modules_main.for 698
error #7983: The storage extent of the dummy argument exceeds that of the actual argument. [OUTPUTARRAY1] ...\modules_main.for 718
error #7983: The storage extent of the dummy argument exceeds that of the actual argument. [OUTPUTARRAY3] ...\modules_main.for 719
error #7983: The storage extent of the dummy argument exceeds that of the actual argument. [OUTPUTARRAY2] ...\modules_main.for 719
PPS: There is one more symptom and now I think it might be my computer system. Since the code compiles in release I wanted to proceed with my work. So I reverted all the changes since it was only for output anyway. Now the compiler is complaining that I need to put the 6 new parameters in:
error #6631: A non-optional actual argument must be present when invoking a procedure with an explicit interface. [OUTPUTARRAY1] ...\modules_main.for 547
error #6631: A non-optional actual argument must be present when invoking a procedure with an explicit interface. [NSP3] ...\modules_main.for 547
error #6631: A non-optional actual argument must be present when invoking a procedure with an explicit interface. [NSP2] ...\modules_main.for 547
error #6631: A non-optional actual argument must be present when invoking a procedure with an explicit interface. [OUTPUTARRAY2] ...\modules_main.for 547
error #6631: A non-optional actual argument must be present when invoking a procedure with an explicit interface. [OUTPUTARRAY3] ...\modules_main.for 547
error #6631: A non-optional actual argument must be present when invoking a procedure with an explicit interface. [NSP1] ...\modules_main.for 547
Usually these issues are fixed when I close and re-open visual studio, but it did not fix it. I will try restarting my computer and see if that helps. If anyone still have any ideas any suggestions would be appreciated.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Debug config turns on /warn:interfaces. that option implicitly turns on /gen-interfaces. You have a mismatch between a generated interface for the subroutine and your call sites listed above.
First read /gen-interfaces documentation to understand the automatically created interfaces for your subroutines. Remember that you will not see this option directly in your Project settings for Debug configuration. Rather, it is implicitly invoked when ...
/warn:interfaces is an option in your Project/Configuration settings. This option is turned on for Debug configurations by default.
With this background, first CLEAN all your projects, particularly the project containing the source file with SUBROUTINE UMAT. Now, use File Explorer and dive down into your Debug folder and see if any .mod files are left over. In particular, look for procedure-name__GENmod.f90 as well as the procedure-name__GENmod.mod files. These should have been cleaned up, if not, remove them.
Rebuild Debug config
Use file explorer again. Find the procedure-name__GENmod.f90 file for UMAT. This is a text file. Open it. Examine. This is what the compiler thinks are your arguments and kinds for the arguments.
Now keep that open and go to any warning/error about CALL UMAT and compare what the compiler thinks the arguments should be, and what you are using in the CALL. Do they match in number and KIND?
The compiler is trying to help you out here and prevent stack corruptions due to mismatched arguments. Take this very seriously, there is a problem in your code that needs to be addressed.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Debug config turns on /warn:interfaces. that option implicitly turns on /gen-interfaces. You have a mismatch between a generated interface for the subroutine and your call sites listed above.
First read /gen-interfaces documentation to understand the automatically created interfaces for your subroutines. Remember that you will not see this option directly in your Project settings for Debug configuration. Rather, it is implicitly invoked when ...
/warn:interfaces is an option in your Project/Configuration settings. This option is turned on for Debug configurations by default.
With this background, first CLEAN all your projects, particularly the project containing the source file with SUBROUTINE UMAT. Now, use File Explorer and dive down into your Debug folder and see if any .mod files are left over. In particular, look for procedure-name__GENmod.f90 as well as the procedure-name__GENmod.mod files. These should have been cleaned up, if not, remove them.
Rebuild Debug config
Use file explorer again. Find the procedure-name__GENmod.f90 file for UMAT. This is a text file. Open it. Examine. This is what the compiler thinks are your arguments and kinds for the arguments.
Now keep that open and go to any warning/error about CALL UMAT and compare what the compiler thinks the arguments should be, and what you are using in the CALL. Do they match in number and KIND?
The compiler is trying to help you out here and prevent stack corruptions due to mismatched arguments. Take this very seriously, there is a problem in your code that needs to be addressed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you very much! This solved it. I will remember that from now on.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I suspect that the subroutine UMAT being discussed is an ABAQUS Umat subroutine, in which case the user is not free to change the argument list of the subroutine. These subroutines are intended to be called from the Abaqus FEA program, and their interface is defined by the program vendor. A user may add arguments and pass those new additional arguments from calls within the user's own sources, but the Abaqus program will not pass those additional arguments since it knows nothing about them.
If there are include files in which are located standard Umat interface blocks, those will be incompatible with the new interface. A compilation with checking options enabled will flag those incompatibilities, whereas a Release build will not.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is true if I am running it with Abaqus. But I am running it standalone with an umat wrapper that simulates Abaqus. So it is just like any other Fortran code.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page