Strange error with a do loop

[GeekVampi]

Hi,

I am using a fortran subroutine with ABAQUS (more specifically it is UMAT, user material), a Finite Element Analysis software, on Windows XP platform. This code worked well with ABAQUS v6.5. Now when I am using the same code with ABAQUS v6.7 (for which INTEL Visual Fortran 9.1 is requirement), I am getting an error message "System error code 5". On Microsoft site, the description for this error code is "Access Denied". On many other forums, it was written that this error code is related to memory allocation.

When I started debugging the code, I came across the following DO loop:

DO I=1,NN
XGAM1(I)=0.0
XGAM2(I)=0.0
DO J=1,NN
XGAM1(I) = XGAM1(I) + XM1(I,J)*EFFS(J)
XGAM2(I) = XGAM2(I) + XM2(I,J)*EFFS(J)
END DO
END DO

NN has a value equal to 4. I couldnot find anything unsual in this do loop (which is simple matrix and a vector multiplication). I tried some other options such as EXIT or assiging a value to a dummy variable I am still getting the same error code 5. I also tried by changing this matrix multiplication code to the following but stilll the same error.

DO I=1,NN
XGAM1(I)=0.0
XGAM2(I)=0.0
END DO

DO J=1,NN
DO I=1,NN
XGAM1(I) = XGAM1(I) + XM1(I,J)*EFFS(J)
XGAM2(I) = XGAM2(I) + XM2(I,J)*EFFS(J)
END DO
END DO

For some reason the code is stopping just after this do loop and issueing an error code 5. Surprisingly, this error code disappears when I put a write statement just after the inner do loop

DO I=1,NN
XGAM1(I)=0.0
XGAM2(I)=0.0
DO J=1,NN
XGAM1(I) = XGAM1(I) + XM1(I,J)*EFFS(J)
XGAM2(I) = XGAM2(I) + XM2(I,J)*EFFS(J)
END DO
WRITE(*,*) 'ABC'
END DO

the error code disappears, and my FORTRAN subroutine works fine. Please note that Compaq Digital Fortran 6 is the requirement for ABAQUS 6.5 and this code works very well with it.

I have never encountered anything like this before, so I am completely lost. I will be very grateful if someone could provide me with the explanation and/or solution.

Thanks

[onkelhotte]

So you migrated a CVF code to IVF and now you get this error, right?

I know this, especially that the error does not appear, when you insert a write statement.

There is nothing wrongwith the do loop. You have some memory problems which were not happening with Compaq but they happen now with the Intel compiler. Sadly they wont appear at once but somewhere else. For example in a do loop...

Set these compiler options, remove all warnings and test your code again:
- Fortran - Diagnostics
* Generate Interface Blocks
* Check Routine Interfaces
- Fortran - Floating Point
* Check Floating-Point Stack


Markus

[j_clausen]

Hi GeekVampi

I, too, have experienced some problems with Abaqus Umats terminating in seemingly random positions. Embarrassing as it is, my problems originated in that I didn't have the "implicit none" in my program (my excuse is, that it was not in the Abaqus example Umats).A forgotten comma in the variable declaration then caused problems similar to yours.

This is probably not the issue here, but just to let you know.

[GeekVampi]

Thanks Markus

I followed your advice, and now I can see may errors during compilation. I will try to fix them up. But still I have a doubt. I am using /iface:cvf compiler option. Does it not make all the necessary checks? Shouldn't a fortran 90 code remain independent of compiler (if not then there is not much difference between fortran and C/C++ in this regard) I am not very good in FORTRAN, so I don't know much about difference between different compilers.

[Les_Neilson]

The use of "implicit none" in your code along with checking for uninitialized variables, and array bounds etc will help narrow down the problem area. Otherchecks identify possible mismatches when calling subroutines (passing real variables when an integer is expected and so on)
The iface:cvf optionspecifies how arguments are passed between subroutines in particular calling routines written in other languages.

Les

[onkelhotte]

Quoting - GeekVampi

Thanks Markus

I followed your advice, and now I can see may errors during compilation. I will try to fix them up. But still I have a doubt. I am using /iface:cvf compiler option. Does it not make all the necessary checks? Shouldn't a fortran 90 code remain independent of compiler (if not then there is not much difference between fortran and C/C++ in this regard) I am not very good in FORTRAN, so I don't know much about difference between different compilers.

I dont know if /iface:cvf does all the necessary checks.

Like I said before, I had similar problems and after cleaning up my code it worked fine.

Markus

[Les_Neilson]

Quoting - GeekVampi

Shouldn't a fortran 90 code remain independent of compiler

Only if your code conforms to the Fortran Standard.
Some (most?) compiler vendors provide what are called "extensions" to the language,but because they are not defined in the Standard then different compilers may do the samething differently. An example of thiswould be SYSTEM (for executing other programs or running operating system commands from your program) Some compilers have SYSTEM as a subroutine, some as a FUNCTION,there may becompilersthat donot have a SYSTEM command.

Some people in the past have relied on the facility that their variables were automatically given an initialvalue of zero by their old setup. When moving to new hardware, Operating System, compiler etc this feature disappeared and their programs, which used to work, now don't, or produce wrong answers. ( I speak from experience in having maintained such software - moral *always*declare and initialise your variables)

Use of "extensions" means a program is not (usually) portable from one compiler to another without having to do somerecoding.

Also over the years compilers have become better at detecting coding errors in programs which may have worked for years but were just waiting for the right set of circumstances to occur beforefailing. ( Again I speak from experience )

Les

[Steven_L_Intel1]

/iface:cvf does not do any checks. It simply changes the defaults for how routines are called to match what CVF used.

However, the error GeekVampi is seeing is an access violation which could result from a mismatch of calling conventions.

Since the ABACUS version you have is built for use with Intel Fortran, you should NOT use /iface:cvf. If you converted the project from CVF then /iface:cvf was applied by default. I suggest that you go into the Properties > Fortran > External Procedures page and set the calling convention to "Default" and the "String length argument passing" to "After all args". Then rebuild the entire project.

[GeekVampi]

Hi,

Many many thanks to everyone for their advice. My code is working right now (atleast for the time being).

I am unable to interprete one error

The shape matching rules of actual arguments and dummy arguments have been violated. [TIME]
CALL IMPL8(TIME,DT,PNEWDT,STRAN,GDELPS,D,NOEL,NPT,KSTEP,KINC)

The variable TIME is a vector of dimension 2 passed from ABAQUS, but it is not actually being used in the code. This is passed in SUBROUTINE IMPL8 just for future purposes.

@Steve Lionel
The code that I am working with, a major portion of it (almost 90%) was written using Digital Visual Fortran. Does that mean I need to rewrite the whole code again? If not then how I can update it for Intel Fortran 9.1 (and higher versions). I do not use Visual Studio IDE. I usually work with command line.

Once again thanks to everyone.

[bmchenry]

I would echo the suggestion to be sure to use IMPLICIT NONE on ALL routines.

When porting code it is an time consuming issue on the front end (having to declare all those implicit variables) but in the long run it will avoid the types of issues you are having.

For example your latest problem is most likely related to *4 vs *8 word size.

By the subroutine name I expect it uses *8 sized variable and the calling routine probably stores in *4 size.

As far as porting from DVF to IF, you should encounter no major issues.

I've ported >20,000 lines of code, hundreds of programs and subroutines, etc and some from mainframe compilers, some from mini computers, and a lot from Microsoft Fortran->Compac/Digital Fortran->Intel.

Once you establish the IMPLICIT NONE and then also determine whether your old routines are passing by value or passing by location, you will are 98% ported.

The main issue you appear to be encountering is that IF is trying to help you realize that there are some word size issues with your variables.

Some of the older compilers were much more lax in checking for such things (or was it more forgiving?) and therefore allowed a wee bit more sloppy programming to be acceptable.

Brian

[Steven_L_Intel1]

Quoting - GeekVampi

I am unable to interprete one error

The shape matching rules of actual arguments and dummy arguments have been violated. [TIME]
CALL IMPL8(TIME,DT,PNEWDT,STRAN,GDELPS,D,NOEL,NPT,KSTEP,KINC)

The variable TIME is a vector of dimension 2 passed from ABAQUS, but it is not actually being used in the code. This is passed in SUBROUTINE IMPL8 just for future purposes.

@Steve Lionel
The code that I am working with, a major portion of it (almost 90%) was written using Digital Visual Fortran. Does that mean I need to rewrite the whole code again? If not then how I can update it for Intel Fortran 9.1 (and higher versions). I do not use Visual Studio IDE. I usually work with command line.

The error is telling you that in IMPL8, the declaration of the dummy argument corresponding to TIME does not have the same shape - that is, it is not an array of the same dimensions. For example, you may have declared it as a scalar. You should declare the argument in IMPL8 to be the proper dimensions. It could be (2) or (*), depending on what you need.

No, you do not have to rewrite the whole code. But you do have to correct errors that DVF may not have detected.

[Greg_T_]

We also use Abaqus with user subroutines. Some of the pitfalls we've had have been due to changes in the argument list and the aba_param.inc file. It would be worth checking that the number and type of arguments hasn't changed between Abaqus versions for your user subroutine. We have had a few cases where an older user subroutine didn't work correctly since a newer version of Abaqus had a new argument or two added to the call statement. I would also be worth checking that the precision set in the aba_param.inc file is what you want for 32 or 64 bit computers. We've had some problems when there was a mismatch between that file and the computer used to run the Abaqus analyis.s

Other approachesthat have helped us to test and debug Abaqus user subroutines include writing to the *.msg file and creating a main program. You can write intermediate values during an Abaqus analysis to the .msg file using file unit 7, according the Abaqus user's manual. It is also possible to write to the *.dat and *.sta files. And we write a main program to drive the user subroutine to run test cases to check that the calculations and calling are working well. This allows us to compare debugging values from within the Abaqus analysis and from the stand-alone main program.I hope this may help with investigating your current problem.

Regards,
Greg

[julienx2k2]

Hi,

I have kind of the same problem with Abaqus/Explicit (VUMAT). The very first time it is called abaqus crashes and returns an error 142.
It seems the error comes up at the very beginning of the routine, when the first do loop starts.
Everything that comes before the do loop is done right as I print the results. But when the loop starts it crashes at once, without even being able to print a message right after the "do km=1,nblock" statement...

Have you ever encountered such an error? I have checked several times the routine and it is compiled by Abaqus without error.

Thanks in advance

Julien

[GeekVampi]

Hi Julienx2k2,

I had similar error with UMAT and I was getting 145. As somebody suggested, I tried following compile options and it helped me in debugging.

/warn:interfaces /gen-interfaces /Qfpstkchk

I also tried /CB to check array bounds. The error code I was getting was due to assumed array size. One array was of dimension 3, which was being passed to another subroutine where its dimension was defined to be 4. So the compiler was adding one extra location without initializing the array. Therefore, the 4th element was having an initial number -1e291, which was being squared, and error code 145 was being issued whenever compiler was trying to access this number. It's overflow but still /fpe:0 couldn't catch it.

So my suggestion is to first try all these compiler options. If it still doesn't resolve the error code, then you will have to go through the "hard" way (there might be another way but I am not aware of). Print suspecious variables just before and after call of each subroutine with a flag. This way it will help you to figure out where is the problem.

[GeekVampi]

Mine was also aborting in the very first increment (when all the variables are zero), same as yours. So it is easier to diagnose now. It is related to some mathematical operation (could be similar to what I was having).

[julienx2k2]

Quoting - GeekVampi

Mine was also aborting in the very first increment (when all the variables are zero), same as yours. So it is easier to diagnose now. It is related to some mathematical operation (could be similar to what I was having).

Thanks for the help! I have tried the various compiler options and it has helped me clear unused variables etc. The error came actually from a division by 0 in the do loop long long after its beginning.
So it seems that the computer reads and execute the program much faster than its ability to print results and strings on the screen! This I didn't know...

Thanks again :)
Julien

[GeekVampi]

Quoting - julienx2k2

Thanks for the help! I have tried the various compiler options and it has helped me clear unused variables etc. The error came actually from a division by 0 in the do loop long long after its beginning.
So it seems that the computer reads and execute the program much faster than its ability to print results and strings on the screen! This I didn't know...

Thanks again :)
Julien

Yeah printing data in a file or console is most time consuming. By the way you can share your experience here (may be this will help others to debug their UMAT or VUMAT for these undocumented errors). Like the compiler options, source of the error, resolution, etc. Or shall I start a new thread spcially for abaqus undocumented errors?

[julienx2k2]

Quoting - GeekVampi

Yeah printing data in a file or console is most time consuming. By the way you can share your experience here (may be this will help others to debug their UMAT or VUMAT for these undocumented errors). Like the compiler options, source of the error, resolution, etc. Or shall I start a new thread spcially for abaqus undocumented errors?

I guess it might be wiser to start a dedicated thread so it becomes easily accessible from search engines (like by typing "abaqus umat error"!
I'd definitely add some comments to such a thread as time goes :)