visual fortran error

[rakesh_shriamgmail_c]

1) "error #6634: The shape matching rules of actual arguments and dummy arguments have been violated. 1093 "

this is the errors that show when i run code that was built in fortran 77 compiler.

2) my second question is how do i compile link and run a fortran code from the visual studio mode instead of using the ifort code

3)third question how do i see the output file generated after running i fort command

[Les_Neilson]

Quoting - rakesh.shriamgmail.com

1) "error #6634: The shape matching rules of actual arguments and dummy arguments have been violated. 1093 "

this is the errors that show when i run code that was built in fortran 77 compiler.

2) my second question is how do i compile link and run a fortran code from the visual studio mode instead of using the ifort code

3)third question how do i see the output file generated after running i fort command

(1) in your code you have an array (the actual argument) which is passed to a subroutine :
call MySub(... array ...)
and you have a subroutine with Y as one of the dummy arguments:

subroutine MySub( ... Y ...)

where the dummy argument "Y" is mapped to the actual argument "array". Now in your code "array" and "Y" do not have the same shape.
If you show us the code,especially the declarations of array and Y, then we can help more.

(2) If you look at the Fortran help, under "Building Applications" and then"Using the Microsoft Visual Studio IDE" this will take you through how to set up projects, compile and build your application.

(3) I'm not sure what you mean. One fortran file when compiled produces a ".obj" file with the same name as the fortran file, usually in the same directory as the source file. The link step can produce an executable file (.exe) a library file (.lib) or a dynamic link library (.dll) depending on the type of project you are building.

Les

[rakesh_shriamgmail_c]

Quoting - Les Neilson

(1) in your code you have an array (the actual argument) which is passed to a subroutine :
call MySub(... array ...)
and you have a subroutine with Y as one of the dummy arguments:

subroutine MySub( ... Y ...)

where the dummy argument "Y" is mapped to the actual argument "array". Now in your code "array" and "Y" do not have the same shape.
If you show us the code,especially the declarations of array and Y, then we can help more.

(2) If you look at the Fortran help, under "Building Applications" and then"Using the Microsoft Visual Studio IDE" this will take you through how to set up projects, compile and build your application.

(3) I'm not sure what you mean. One fortran file when compiled produces a ".obj" file with the same name as the fortran file, usually in the same directory as the source file. The link step can produce an executable file (.exe) a library file (.lib) or a dynamic link library (.dll) depending on the type of project you are building.

Les

thanks a lot for ur reply sir ,

i am attaching the code . can you compile it using visual fortran and tel me what was the error there sir .

[anthonyrichards]

Well, it compiles OK with Compaq Visual fortran.
However, when first run, there was an access violation caused by some VERY bad use of COMMON variables. For example, in subroutine DRIVE, you have common variables defined as follows:

COMMON /GEAR2/ YMAX(20)
COMMON /GEAR3/ ERROR(20)
COMMON /GEAR4/ SAVE1(20)
COMMON /GEAR5/ SAVE2(20)
COMMON /GEAR6/ PW(400)
COMMON /GEAR7/ IPIV(20)

However, at two other places in your code, in subroutines STIFF and PSET, you have the following code:
COMMON /GEAR2/ YMAX(1)
COMMON /GEAR4/ SAVE1(1)
COMMON /GEAR5/ SAVE2(1)
COMMON /GEAR6/ PW(1)
COMMON /GEAR7/ IPIV(1)

So, in the first Do loop in STIFF, the loop index goes to 2 and you try and access SAVE1(2) and the CVF debugger caught the attempt to adress outside of the range of the variable SAVE1 defined in the COMMON as COMMON/GEAR4/ SAVE1(1).

There is other horrible use of GEAR1 common, such as the following search results show:

C:F90GEARGEAR.FOR(246): COMMON /GEAR1/ T,H,HMIN,HMAX,EPSC,UROUND,NC,MFC,KFLAG,JSTART
C:F90GEARGEAR.FOR(435): COMMON /GEAR1/ T,H,DUMMY(4),N,IDUMMY(2),JSTART
C:F90GEARGEAR.FOR(464): COMMON /GEAR1/ T,H,HMIN,HMAX,EPS,UROUND,N,MF,KFLAG,JSTART
C:F90GEARGEAR.FOR(1071): COMMON /GEAR1/ T,H,DUMMY(3),UROUND,N,IDUMMY(3)

If this type of coding is typical in GEAR, then I suspect that there are other things like this waiting to bite you in the behind. You have to go through your code and, ideally define all your COMMON variables inside a MODULE (perhaps called MYCOMMON)that you can USE inside each subroutine and function that requires access to the COMMON variables. You can then delete all references to the COMMON blocks and replace them with USE MYCOMMON. Once you have this sorted out, you can carry onj debugging and find the other faults in the code.

Good luck!

P.S. The code also uses imlicit assumptions about the type of variable depending on the first letter of its name (e.g. names starting with letters I,J,K,L,M,N,O are assumed to be Integer, the rest assumed to be REAL. You need to be clear which REAL variables you intend tobe REAL(4)and whichREAL(8), especially when they are in COMMON - I prefer to add IMPLICIT NONE to all my code and explicitly define all my variables. This catches undefinedvariables at compilation time and gives uninitialised variable warnings.

[Les_Neilson]

Quoting - rakesh.shriamgmail.com

thanks a lot for ur reply sir ,

i am attaching the code . can you compile it using visual fortran and tel me what was the error there sir .

ok.

SUBROUTINE PSET (Y, N0, CON, MITER, IER)
C-----------------------------------------------------------------------
C THE FOLLOWING CARD IS FOR OPTIMIZED COMPILATION UNDER CHAT.
C OPTIMIZE
C-----------------------------------------------------------------------
DIMENSION Y(N0,1)


so Y is an array dimensioned (NO,1) which you then pass to PEDERV

C IF MITER = 1, CALL PEDERV AND MULTIPLY BY SCALAR.--------------------
CALL PEDERV (N, T, Y, PW, N0)



SUBROUTINE PEDERV (N, T, Y, PD, N0)
DIMENSION PD(N0,N0)
PD(1,1) = 0.
PD(1,2) = 1.
PD(2,1) = -10.
PD(2,2) = -11.
RETURN
END

Here Y is a (defaultREAL)scalar (not an array) even though it is not used it is still expected to match.


I have not looked at the rest of the code for problems.
Les

[rakesh_shriamgmail_c]

Quoting - Les Neilson

ok.

SUBROUTINE PSET (Y, N0, CON, MITER, IER)
C-----------------------------------------------------------------------
C THE FOLLOWING CARD IS FOR OPTIMIZED COMPILATION UNDER CHAT.
C OPTIMIZE
C-----------------------------------------------------------------------
DIMENSION Y(N0,1)


so Y is an array dimensioned (NO,1) which you then pass to PEDERV

C IF MITER = 1, CALL PEDERV AND MULTIPLY BY SCALAR.--------------------
CALL PEDERV (N, T, Y, PW, N0)



SUBROUTINE PEDERV (N, T, Y, PD, N0)
DIMENSION PD(N0,N0)
PD(1,1) = 0.
PD(1,2) = 1.
PD(2,1) = -10.
PD(2,2) = -11.
RETURN
END

Here Y is a (defaultREAL)scalar (not an array) even though it is not used it is still expected to match.


I have not looked at the rest of the code for problems.
Les

sir, thanks for your reply .

i am using this code in visual fortran comiler in visual studio 2005 IDE ... there are so many variables to be set ... can you tel me what basic configurations to change ...

[rakesh_shriamgmail_c]

Quoting - Les Neilson

ok.

SUBROUTINE PSET (Y, N0, CON, MITER, IER)
C-----------------------------------------------------------------------
C THE FOLLOWING CARD IS FOR OPTIMIZED COMPILATION UNDER CHAT.
C OPTIMIZE
C-----------------------------------------------------------------------
DIMENSION Y(N0,1)


so Y is an array dimensioned (NO,1) which you then pass to PEDERV

C IF MITER = 1, CALL PEDERV AND MULTIPLY BY SCALAR.--------------------
CALL PEDERV (N, T, Y, PW, N0)



SUBROUTINE PEDERV (N, T, Y, PD, N0)
DIMENSION PD(N0,N0)
PD(1,1) = 0.
PD(1,2) = 1.
PD(2,1) = -10.
PD(2,2) = -11.
RETURN
END

Here Y is a (defaultREAL)scalar (not an array) even though it is not used it is still expected to match.


I have not looked at the rest of the code for problems.
Les

sir,

but this code complies with another compiler .. i would attach the output that is generated in that as my file

is it array declaration that is causing this problem .. to find this out i have written another code ..

in the code the output is not generated ..

[Les_Neilson]

Quoting - rakesh.shriamgmail.com

sir, thanks for your reply .

i am using this code in visual fortran comiler in visual studio 2005 IDE ... there are so many variables to be set ... can you tel me what basic configurations to change ...

Well I turned off interface checking which got me one step furtherbut there are so many problems(such as those mentioned by Anthony) you would be better of correcting the code than trying to work round them. At least make the sizes of all arrays consistent throughout the code.

If it were my choice I would, as a minimum, add IMPLICIT NONE to all the routines andspecify the type of every variable, then I would use f95 style coding with modules instead of common blocks and so on. But that is somethingonly youcan decide.

Les


The fact that it works with another compiler only means that that compiler was/is unable to detect the code problems.

[Les_Neilson]

Since the code is so old (1974)and modern compilers easily detect mismatches in argument shape etc, I would suggest splitting the file into its separate subroutines, compile each file individually and build your exe that way - turn off interface checking.

The code uses an old "trick" to declare a dummy argument as Y(N0,1) to say "I know it is a 2d array but I don't know how big the second subscript is" but as soon as you use Y(..,2) you get an out of bounds error. You could try replacing Y(N0,1) with Y(N0,*)

I had a quick try at updating it to f95 but there are way too many errors for me to spend much more time on it.

Les

[bmchenry]

I concur with les on all his suggestions, etc.

To move you along to conversion, i ran your 1st code, gear.for, through SPAG, a part of PlusFORT
http://www.polyhedron.com/pf-plusfort0html
you can see som diagnostics, etc.
The two filws peovide you with a good template for confersion to f90.
Actually spag.out is pretty much a f90 file (a few edits are required).
spag.log provides some notes on the conversion.

I'd recommend getting a tool such as plusFORT to convert your code to f90.
then adding implicit none, etc to clean up the variables.

One item i note: (i quickly reviewed the thread but not in detail).
Common blocks back in the day could change shape.
The main difference between them and MODs in modern compilers is alignment.
So consider that when looking at the various sizes and shapes of the common.

[Les_Neilson]

Update

I split the file into separate files keeping the old F77 form (I did change all Y(N0,1) to Y(20,13) to avoid bounds errors)
I built the exe but it dies in subroutine STIFF when JSTART is not zero because local variables eg RC, have not been assigned a value.
For example when JSTART is 1 STIFF goes to 200
which says if (abs(RC-1.) ...
but RC has not been assigned a value, it is not in COMMON,neither hasit been give a SAVE option.

GEAR badly needs a re-write :-)

Les

[anthonyrichards]

I attach a solution for you that compiles and executes in both debug and release mode without any diagnostic errors. However, the results differ between debug and release as you will see from looking at GEAR_OUTPUT_DEBUG.TXT and GEAR_OUTPUT_RELEASE.TXT.

What I did was split your code into a seperate main programand seperate subroutines and added a MODULE called MYCOMMON. This was because avariable nameused in a COMMON block in one place was used as a local variable in another place, so dealing with name changes was easier by isolating the natural blocks of code.

For each seperate routine, I then identified the argument variables by appending '_ARG' to the name and edited the file accordingly.

Then, wherever a COMMON block variable was used, I changed its name by adding '_Gn', where n=1,2,3,4,5,6,7,8 or 9, depending on whether the variable was originally included in common block named GEAR1, GEAR2 etc. This way I could keep track of the common block variables and the arguments, leaving all other variables as local variables.

I then added IMPLICIT NONE to each module and defined every argument and every local variable.
Then I made up my module MYCOMMON using all the variables in all 9 original common blocks, plus LOUT, the output unit number. In then replaced all COMMON block references with USE MYCOMMON.

I have made all real variables REAL(4). You might want to change the '4' to an INTEGER PARAMETERwhose valueyou can set to either '4' or '8' in the MODULE so that you can easily switch to double precision when you want to just by selecting the right value for this module parameter. Failing that, concatenate all the files and do a global edit to change REAL(4) to REAL(8)

I leave it to you to clean up the sequence number fields.

[anthonyrichards]

Here are cleaned-up free-format versions (.F90 extension) obtained by running the Fixed-format .FOR versions I posted earlierthrough a preconverter that deals with any tabs to create a fixed-format .F version which was then run through a converter that created the free-format .F90 version. The converter is not perfect (it falls over when tabs are present, hence the preconverter), for example it outputs USEMYCOMMON instead of USE MYCOMMON, ENDPROGRAM instead of END PROGRAMand it does not always put a continuation '&' in column 6 after a line with a continuation '&' in column 73 (this is to make the code compilable both as free and fixed format). I include the peconverter and the converter which I obtained free from the Web.

I have created a project using the new free-format versions and it compiles and runs just fine using Compaq Visual Fortran.It creates an output filecalled GEAR_OUTPUT.TXT.

One of the bits of code that I think you need to deal with better is the way that the array Y(20,30) is presented and dimensioned in subroutines DRIVE and STIFF. These dimensions need to be compatible to values set for module variables (the number of equations etc.) and compatible in each unit. So I think it will be better to put the specification of Y(20,30)into the MYCOMMON module and dimension it there using other module variables, which themselves will then have to be declared as PARAMETERs. Then you should replace the REAL(4) Y(20,13) specification statements in DRIVE and STIFFwith USE MYCOMMON, so as to make the correct size array available to the units.

[Les_Neilson]

Wow Anthony, and my wife says I need to get out more :-)

Les


still doesn't run for me.

DRIVE.f90 has a missing assignment to N0 (after JSTART_G1 = 0)
N0 = N_ARG

but after adding thatit still dies in STIFF.f90 at label 200 because RC is uninitialised when JSTART_G1 > 0

presumably the original author used a system/setting where local variables were saved ?



Yes. I set local variables save (/Qsave) and it ran to completion :-)

[anthonyrichards]

Quoting - Les Neilson

Wow Anthony, and my wife says I need to get out more :-)

Les


still doesn't run for me.

DRIVE.f90 has a missing assignment to N0 (after JSTART_G1 = 0)
N0 = N_ARG

but after adding thatit still dies in STIFF.f90 at label 200 because RC is uninitialised when JSTART_G1 > 0

presumably the original author used a system/setting where local variables were saved ?



Yes. I set local variables save (/Qsave) and it ran to completion :-)

Well spotted, Les. The CVF compiler saves most things by default. There is no equivalent /Qsave option. I guess a SAVE statement should be added to STIFF and DRIVE for portability.

And yes, my work load is a little light at present!

P.S. to the original poster: There are several occurrences of IF tests of the following type:

IF (T.EQ.0.) GOTO 80

where a real is compared to zero. I think it is better practice to use a test for the number being within a small quantity from zero, for example

IF (ABS(T).LT.SMALLQUANTITY) GOTO 80

where you can define SMALLQUANTITY in a module and USEthe module in the program sections where it is needed (unless of courseyou really have to insist on it being EXACTLY zero to the accuracy to which 0. is stored internally).

by trying out a range of values for SMALLQUANTITY, you may find(a) that your results are not sensitive to values below a certain threshold and (b) that your execution speeds improve using finite values for SMALLQUANTITY.