Debugging ODEPACK source codes on Intel Visual Fortran Help

[Aravind_R_1]

Hi, I am try to run the Fortran 77 popular ODEPACK files( written by Alan Hindmarsh) on a Intel Visual Fortran Compiler running on Visual Studio Professional 2012. I have fixed most of the errors except for one recurring one that seems to have an aliasing issue with the compiler.

When the overall source codes are run, this is the result:

Error 1 error #6633: The type of the actual argument differs from the type of the dummy argument. [RWORK] C:\Users\FortranCompiler\Desktop\Liu text files\opkdmain.f 3445

Error 2 Compilation Aborted (code 1) C:\Users\FortranCompiler\Desktop\Liu text files\opkdmain.f 1

Error 3 error #6633: The type of the actual argument differs from the type of the dummy argument. [RWORK] C:\Users\FortranCompiler\Desktop\Liu text files\opkda1.f 9499

Error 4 Compilation Aborted (code 1) C:\Users\FortranCompiler\Desktop\Liu text files\opkda1.f 1

List of files and areas of code error:

opkdmain.f

C-----------------------------------------------------------------------

C CALL DSTODE(NEQ,Y,YH,NYH,YH,EWT,SAVF,ACOR,WM,WM,F,JAC,DPRJS,DSOLSS)

C-----------------------------------------------------------------------

CALL DSTODE (NEQ, Y,RWORK(LYH), NYH,RWORK(LYH),RWORK(LEWT),

1 RWORK(LSAVF),RWORK(LACOR),RWORK(LWM),RWORK(LWM),

2 F, JAC, DPRJS, DSOLSS)

KGO = 1 - KFLAG

GO TO (300, 530, 540, 550), KGO

opkda1.f :

C Call DPREPI to do matrix preprocessing operations. -------------------

CALL DPREPI (NEQ, Y, S, RWORK(LYH), RWORK(LSAVF),

1 RWORK(LEWT),RWORK(LACOR),IA,JA,IC,JC,RWORK(LWM),

2 RWORK(LWM), IPFLAG,RES, JAC, ADDA)

LENWK = MAX(LREQ,LWMIN)

IF (IPFLAG .LT. 0) RETURN

C If DPREPI was successful, move YH to end of required space for WM. ---

LYHN = LWM + LENWK

IF (LYHN .GT. LYH) RETURN

LYHD = LYH - LYHN

IF (LYHD .EQ. 0) GO TO 20

IMAX = LYHN - 1 + LENYHM

DO 10 I=LYHN,IMAX

10 RWORK(I) = RWORK(I+LYHD)

LYH = LYHN

C Reset pointers for SAVR, EWT, and ACOR. ------------------------------

20 LSAVF = LYH + LENYH

LEWTN = LSAVF + N

LACOR = LEWTN + N

IF (ISTATC .EQ. 3) GO TO 40

C If ISTATE = 1, move EWT (left) to its new position. ------------------

IF (LEWTN .GT. LEWT) RETURN

DO 30 I=1,N

30 RWORK(I+LEWTN-1) = RWORK(I+LEWT-1)

40 LEWT = LEWTN

RETURN

C----------------------- End of Subroutine DIPREPI ---------------------

END

*DECK DPREPI

SUBROUTINE DPREPI (NEQ, Y, S,YH,SAVR,EWT,RTEM,IA,JA,IC,JC,

1 WK, IWK, IPPER, RES, JAC, ADDA)

EXTERNAL RES, JAC, ADDA

INTEGER NEQ, IA, JA, IC, JC, IWK, IPPER

DOUBLE PRECISION Y, S, YH, SAVR, EWT, RTEM, WK

DIMENSION NEQ(*), Y(*), S(*), YH(*), SAVR(*), EWT(*), RTEM(*),

1 IA(*), JA(*), IC(*), JC(*), WK(*), IWK(*)

INTEGER IOWND, IOWNS,

1 ICF, IERPJ, IERSL, JCUR, JSTART, KFLAG, L,

2 LYH, LEWT, LACOR, LSAVF, LWM, LIWM, METH, MITER,

3 MAXORD, MAXCOR, MSBP, MXNCF, N, NQ, NST, NFE, NJE, NQU

INTEGER IPLOST, IESP, ISTATC, IYS, IBA, IBIAN, IBJAN, IBJGP,

1 IPIAN, IPJAN, IPJGP, IPIGP, IPR, IPC, IPIC, IPISP, IPRSP, IPA,

2 LENYH, LENYHM, LENWK, LREQ, LRAT, LREST, LWMIN, MOSS, MSBJ,

3 NSLJ, NGP, NLU, NNZ, NSP, NZL, NZU

DOUBLE PRECISION ROWNS,

1 CCMAX, EL0, H, HMIN, HMXI, HU, RC, TN, UROUND

DOUBLE PRECISION RLSS

Analysis: Both files have same error with the way RWORK is classified. From the originally run program, RWORK is classified as follows:

EXTERNAL FEX, JAC

DOUBLE PRECISION ATOL, RTOL, RWORK, T, TOUT, Y

DIMENSION NEQ(12),Y(12), RWORK(500), IWORK(30), RTOL(12), ATOL(12)

DATA LRW/500/, LIW/30/

NEQ(1) = 12

DO 10 I = 1,NEQ(1)

10 Y(I) = 0.0D0

Y(1) = 1.0D0

T = 0.0D0

TOUT = 0.1D0

ITOL = 1

RTOL = 1.0D-4

ATOL = 1.0D-6

ITASK = 1

QISTATE = 1

IOPT = 0

MF = 121

DO 40 IOUT = 1,5

CALL DLSODES (FEX, NEQ, Y, T, TOUT, ITOL, RTOL, ATOL,

1 ITASK, ISTATE, IOPT, RWORK, LRW, IWORK, LIW, JAC, MF)
As listed in the opkdmain.f file of odepack subroutines:

C RWORK = a work array used for a mixture of real (double precision)

C and integer work space.

C The length of RWORK (in real words) must be at least

C 20 + NYH*(MAXORD + 1) + 3*NEQ + LWM where

C NYH = the initial value of NEQ,

C MAXORD = 12 (if METH = 1) or 5 (if METH = 2) (unless a

C smaller value is given as an optional input),

C LWM = 0 if MITER = 0,

C LWM = 2*NNZ + 2*NEQ + (NNZ+9*NEQ)/LENRAT if MITER = 1,

C LWM = 2*NNZ + 2*NEQ + (NNZ+10*NEQ)/LENRAT if MITER = 2,

C LWM = NEQ + 2 if MITER = 3.

C In the above formulas,

C NNZ = number of nonzero elements in the Jacobian matrix.

C LENRAT = the real to integer wordlength ratio (usually 1 in

C single precision and 2 in double precision).

C (See the MF description for METH and MITER.)

C Thus if MAXORD has its default value and NEQ is constant,

C the minimum length of RWORK is:

C 20 + 16*NEQ for MF = 10,

C 20 + 16*NEQ + LWM for MF = 11, 111, 211, 12, 112, 212,

C 22 + 17*NEQ for MF = 13,

C 20 + 9*NEQ for MF = 20,

C 20 + 9*NEQ + LWM for MF = 21, 121, 221, 22, 122, 222,

C 22 + 10*NEQ for MF = 23.

C If MITER = 1 or 2, the above formula for LWM is only a

C crude lower bound. The required length of RWORK cannot

C be readily predicted in general, as it depends on the

C sparsity structure of the problem. Some experimentation

C may be necessary.

C

C The first 20 words of RWORK are reserved for conditional

C and optional inputs and optional outputs.

C

C The following word in RWORK is a conditional input:

C RWORK(1) = TCRIT = critical value of t which the solver

C is not to overshoot. Required if ITASK is

C 4 or 5, and ignored otherwise. (See ITASK.)

C

C LRW = the length of the array RWORK, as declared by the user.

C (This will be checked by the solver.)

C

C IWORK = an integer work array. The length of IWORK must be at least

C 31 + NEQ + NNZ if MOSS = 0 and MITER = 1 or 2, or

C 30 otherwise.

C (NNZ is the number of nonzero elements in df/dy.)

C

C In DLSODES, IWORK is used only for conditional and

C optional inputs and optional outputs.

C

C The following two blocks of words in IWORK are conditional

C inputs, required if MOSS = 0 and MITER = 1 or 2, but not

C otherwise (see the description of MF for MOSS).

C IWORK(30+j) = IA(j) (j=1,...,NEQ+1)

C IWORK(31+NEQ+k) = JA(k) (k=1,...,NNZ)

C The two arrays IA and JA describe the sparsity structure

C to be assumed for the Jacobian matrix. JA contains the row

C indices where nonzero elements occur, reading in columnwise

C order, and IA contains the starting locations in JA of the

C descriptions of columns 1,...,NEQ, in that order, with

C IA(1) = 1. Thus, for each column index j = 1,...,NEQ, the

C values of the row index i in column j where a nonzero

C element may occur are given by

C i = JA(k), where IA(j) .le. k .lt. IA(j+1).

C If NNZ is the total number of nonzero locations assumed,

C then the length of the JA array is NNZ, and IA(NEQ+1) must

C be NNZ + 1. Duplicate entries are not allowed.

It seems that the sections that RWORK is taken as an array of a mix of double precision and integer data types. Is it possible for the RWORK array to contain two different data types or must it only contain one based on Intel's aliasing rules for Fortran 77. Please let me know if the structure of the code right now is in error or if there is an alternative way of allowing RWORK to include both INTEGER and DOUBLE PRECISION data types.  Thank you!

[Steven_L_Intel1 · Accepted solution]

Some terminology correction is in order. What you have isn't aliasing. It's using a variable of one type to hold data of a different type. This was never allowed in Fortran - Intel's or anyone else's - but many compilers don't check for type matches of arguments to external procedures. Many older programs took advantage of this to deliberately mismatch types.

You can disable this error check by setting the project property Fortran > Diagnostics > Check routine interfaces to No. Do this only once you have convinced yourself that the mismatch is intentional and harmless.

And is it harmless? No. In particular, storing integer data in a real-typed variable can cause that data to be silently changed due to the way floating point data is interpreted. You might also get run-time errors depending on the value stored.

[mecej4]

That code was written in the 1980's, and it was standard practice to use one big block of scratch-pad/work-area memory (with a work array of any arbitrary type) and parcel chunks of it out as needed. If your objective is just to use the code to solve a problem, there are no "errors" to fix. Just choose suitable compiler options, i.e., relaxed type checking. Below I show the results of a straightforward compilation and linking. The results from running the program agreed with those at Netlib.

It is probably incorrect and misleading to label as "aliasing" the use of a work array that was allocated as of one type and used later as an array of a different type.

S:\ODE>ifort /Od demos1.f opkda1.f opkda2.f opkdmain.f
Intel(R) Visual Fortran Compiler for applications running on IA-32, Version 16.0.3.207 Build 20160415
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 12.00.31101.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:demos1.exe
-subsystem:console
-incremental:no
demos1.obj
opkda1.obj
opkda2.obj
opkdmain.obj

S:\ODE>

[Steven_L_Intel1 · Accepted solution]

Some terminology correction is in order. What you have isn't aliasing. It's using a variable of one type to hold data of a different type. This was never allowed in Fortran - Intel's or anyone else's - but many compilers don't check for type matches of arguments to external procedures. Many older programs took advantage of this to deliberately mismatch types.

You can disable this error check by setting the project property Fortran > Diagnostics > Check routine interfaces to No. Do this only once you have convinced yourself that the mismatch is intentional and harmless.

And is it harmless? No. In particular, storing integer data in a real-typed variable can cause that data to be silently changed due to the way floating point data is interpreted. You might also get run-time errors depending on the value stored.

[Aravind_R_1]

Hi,

Thank you both for taking the time to comment on my dilemma. I will look into both your suggestions but I just have a couple quick follow up questions: Where do I go on Visual Studio 2012 Professional to change the compiler options to relaxed Type setting, and where do I go to access project property? I am quite new at working with Fortran and Visual Studio in general so any additional advice would be most appreciated. Thank you!

Best regards,

Aravind R.

[Steven_L_Intel1]

In the Solution Explorer pane, right click on the Fortran project (purple and white F icon), select Properties. Then Fortran > Diagnostics. Other compiler settings are in this dialog.

[mecej4 · Accepted solution]

You may also consider Hindmarsh's newer solver, VODE, which is also available at Netlib: http://www.netlib.org/ode/vode.f .

This newer solver does not use work arrays in ways that you may find objectionable. However, it calls the old Linpack linear equation solvers, and you may wish to replace those calls with corresponding calls to the Lapack routines in MKL.

[Aravind_R_1]

Hi,

Thanks to your suggestions, I got the program to work. I am now trying to run the ODEPACK files through a different program that calls them and writes the results into KPOV.txt files as shown below:

PROGRAM DESIGN05A

C

C The purpose of this program is to compute a batch reaction

C to produce PET. The batch time is five hours, and the charge

C is liquid ethylene glycol and solid terephthalic acid.

C Solid dissolution is assumed to occur instantaneously, i.e.,

C it is not rate limited.

C

C The code automatically varies the EG/TPA mole feed ratio

C (from 0.5 to 1.5, in increments of 0.1) and the temperature

C exponent (from 1 to 20, in increments of 5), and records the

C effect of these variables on:

C *Mass PET Produced / Mass Fed

C *Number-average molecular weight of the PET produced (kg/mol)

C *Mass DEG Produced / Mass PET Produced

C

C The code takes a few minutes to run on a Intel Pentium 4, 3GHz

C personal computer.

C

C Kevin C. Seavey, 2006

C Blacksburg, VA 24061

C

IMPLICIT NONE

C

INTEGER NCOMP, NEQ, I, JLOOP1, JLOOP2

PARAMETER (NCOMP = 14, NEQ = NCOMP+1)

INTEGER COMPLIST(NCOMP), COMPTYPE(NCOMP)

DOUBLE PRECISION MW(NCOMP), CRIT(NCOMP,3), PSAT(NCOMP,5),

$ LMV(NCOMP,4), VAPVISC(NCOMP,4), LIQVISC(NCOMP,5),

$ VKLIQDENS(NCOMP,6), ETAZERO(NCOMP,2), XC

DOUBLE PRECISION MOLES(NEQ), PRES

INTEGER LENRWORK, LENIWORK, ITOL, ITASK, ISTATE, IOPT, MF

PARAMETER (LENRWORK = 1000, LENIWORK = 30)

INTEGER IWORK(LENIWORK)

DOUBLE PRECISION ATOL, RTOL, RWORK(LENRWORK), T, DT, JAC, TOUT,

$ TEND, ZERO, TEMP, LMOLES(NCOMP), MWN, POLYMWN, MASS(NCOMP),

$ FEEDMASS, TEXP, KPOV(3,11,5)

PARAMETER (ZERO = 0.D0)

C

EXTERNAL FILLPROPS, DLSODES, F, MOLETOMASS, MWN

COMMON /INT/ COMPTYPE, COMPLIST

COMMON /DP/ LMV, XC, VKLIQDENS, MW, TEND, TEMP, TEXP

C

C The first step in this simulation is to define the component list.

C For us, it is acetaldehyde, antimony triacetate,

C diethylene glycol, ethylene glycol,

C terephthalic acid, water, PET, B-DEG, B-EG, B-TPA, T-EG, T-TPA,

C T-VIN, and T-DEG

COMPLIST(1) = 1

COMPLIST(2) = 4

COMPLIST(3) = 8

COMPLIST(4) = 9

COMPLIST(5) = 11

COMPLIST(6) = 12

COMPLIST(7) = 14

COMPLIST(8) = 16

COMPLIST(9) = 17

COMPLIST(10) = 18

COMPLIST(11) = 21

COMPLIST(12) = 24

COMPLIST(13) = 25

COMPLIST(14) = 26

C

C The second step is to fill the property parameter arrays

CALL FILLPROPS(NCOMP, COMPLIST, COMPTYPE, MW, CRIT, PSAT,

$ LMV, VAPVISC, LIQVISC, VKLIQDENS, ETAZERO)

C

C The third step is list the initial molar hold ups of the

C liquid and solid phases. These will be stored in a stacked

C vector containing liquid phase components, then solid phase

C components (only TPA is in solid phase). Also define the

C crystal mole fraction in PET.

C (in addition, we are also entering a nested loop where

C the EG/TPA mole feed ratio is automatically changed (JLOOP1) and

C the temperature exponent is also automatically changed (JLOOP2))

DO JLOOP1 = 1,11

DO JLOOP2 = 1, 5

C

DO I = 1, NCOMP

MOLES(I) = ZERO

ENDDO

MOLES(2) = 0.D0

MOLES(4) = 0.5D0 + (FLOAT(JLOOP1)-1.D0)*0.1D0

MOLES(NCOMP+1) = 1.D0

XC = 0.D0

TEXP = 1.D0 + (FLOAT(JLOOP2)-1.D0)*5.D0

FEEDMASS = MOLES(4)*MW(4) + MOLES(NCOMP+1)*MW(5)

C

C The fourth step is to define DLSODES parameters and time

C constants (s)

T = 0.D0

TEND = 5.D0 * 3600.D0

DT = 60.D0

TOUT = T + DT

ITOL = 1

RTOL = 1.D-10

ATOL = 1.D-10

ITASK = 1

ISTATE = 1

IOPT = 1

MF = 222

IWORK(5) = 5

IWORK(6) = 10000

IWORK(7) = 10

C

C The fifth step is to repeatedly integrate in time until

C the end time is reached

OPEN(11, FILE = "Results.txt")

WRITE(11,20) T, 100.D0, (MOLES(I), I = 1, NEQ)

DO WHILE (T.LE.TEND)

C

C Integrate to new time

CALL DLSODES(F, NEQ, MOLES, T, TOUT, ITOL, RTOL, ATOL,

$ ITASK, ISTATE, IOPT, RWORK, LENRWORK, IWORK, LENIWORK,

$ JAC, MF)

C

C Check to see if solver failed

IF (ISTATE.LT.0) GOTO 10

C

C Write results

WRITE(11,20) T, TEMP, (MOLES(I), I = 1, NEQ)

C

C Reset TOUT

TOUT = TOUT + DT

C

ENDDO

C

C Now compute pertinent quantities

DO I = 1, NCOMP

LMOLES(I) = MOLES(I)

ENDDO

POLYMWN = MWN(NCOMP, COMPTYPE, LMOLES, MW)

CALL MOLETOMASS(NCOMP, COMPTYPE, MW, LMOLES, MASS)

KPOV(1,JLOOP1,JLOOP2) = MASS(7)/FEEDMASS

KPOV(2,JLOOP1,JLOOP2) = POLYMWN

KPOV(3,JLOOP1,JLOOP2) = MASS(3)/MASS(7)

C

C Normal stop

CLOSE(11)

C (two ENDDOs below correspond to JLOOP1 and JLOOP2)

ENDDO

ENDDO

C Now write the KPOV matrices (as a function of EG/TPA feed

C and temperature exponent) to output files

OPEN (12, FILE="KPOV1.txt")

OPEN (13, FILE="KPOV2.txt")

OPEN (14, FILE="KPOV3.txt")

DO JLOOP1 = 1, 11

WRITE(12,30) (KPOV(1,JLOOP1,JLOOP2), JLOOP2=1,5)

WRITE(13,30) (KPOV(2,JLOOP1,JLOOP2), JLOOP2=1,5)

WRITE(14,30) (KPOV(3,JLOOP1,JLOOP2), JLOOP2=1,5)

ENDDO

CLOSE(12)

CLOSE(13)

CLOSE(14)

STOP

C

C Print error if solver fails

10 WRITE(*,*) "INTEGRATOR FAILED. ISTATE:", ISTATE

CLOSE(11)

STOP

C

20 FORMAT(2F10.1, 15(X, ES10.3E2))

30 FORMAT(ES10.3E2, 4(X, ES10.3E2))

C

PRINT *, "PROGRAM DONE"

END

The external programs that are called are written in as well but for some reason, output is blank. I think the code successfully wrote the data into .txt files but I am having trouble locating where those files are stored since the files did not pop up upon the completion of the code. The build is listed as being successful, so if you could direct me as to where I can find stored .txt files in visual studio I would be most grateful.​

Thanks!

Aravind

[Aravind_R_1]

And mecej4 thanks for the alternative approach! The program seems to be running fine when I just adjust the error check settings though, so I think I will just stick to Hindmarsh's older solver for now.

[mecej4]

The external programs that are called are written in as well but for some reason, output is blank. I think the code successfully wrote the data into .txt files but I am having trouble locating where those files are stored since the files did not pop up upon the completion of the code. The build is listed as being successful, so if you could direct me as to where I can find stored .txt files in visual studio I would be most grateful.​

Lots of "iffy" statements here!

1. A successful build does not automatically cause the just-built program to be run. 
2. If the program was built and run, there is nothing unusual about "output is blank", since your program only writes to files (except when the solver fails). The output is made to be blank by your design.
3. It is amusing to me that you expect the text files written by your program to "pop up" upon the completion of the code. I may be old-fashioned, but I expect my programs to just do what they were programmed to do, and no more. If there is to be any celebration of their doing so, I want to be in charge.

If the program did run, you should normally see the output files in the project directory (the directory where the .SLN and .VFPROJ files of the project are located), but the location can be altered by your project settings or your program itself.

[Aravind_R_1]

Thanks mecej4,

So if I wanted the text file to be open is there a command I can write in on the program to make that possible and if not how exactly do I open the project directory on Visual Studio?

[mecej4]

If the VS output window is open, you will see something similar to the following when your program has finished:

The program '[5696] tprj.exe' has exited with code 0 (0x0)

Pressing ctrl+o will show you a directory box, and within it you should see the newly-created file(s).

Regarding getting VS to open the files, etc., someone else may answer. I do not use VS at all, if I can avoid doing so.

[Steven_L_Intel1]

In Visual Studio you can use File > Open... > File... to open any file. You can also add an arbitrary file to your project and view it within Visual Studio (assuming it's something VS knows how to read.)

[mecej4]

Steve, the files concerned are files that are written/re-written by his program. I suppose he could manually open the files after first creation, and thereafter have the editor sense when the files are rewritten on disk and refresh the display. 

[Aravind_R_1]

Thanks guys! 

I was able to open the files per mecej4's suggestion thank you both for taking the time to answer my questions!

Wish you all the best!

[ivanpribec]

I just stumbled upon the same compiler flags as Aravind in trying to use LSODES to solve some partial differential equations using the method of lines and the PDEONE routine from Sincovec and Madsen.

In agreement with the replies from mecej4 and Steve Lionel, the ODEPACK documentation in fact explicitly mentions this type mismatching:

4. ODEPACK contains a few instances where ANSI Fortran 77 is violated:
   (a) In various places in the LSODES and LSODIS solvers, a call to a
       subroutine has a subscripted real array as an argument where the
       subroutine called expects an integer array.  Calls of this form
       occur in Subroutine SLSODES (to SSTODE), in SIPREP (to SPREP),
       in Subroutine SLSODIS (to SSTODI), and in SIPREPI (to SPREPI).
       Another such call occurs in the SLSODES demonstration program,
       from the main program to Subroutine SSOUT.  This is done in order
       to use work space in an efficient manner, as the same space is
       sometimes used for real work space and sometimes for integer work
       space.  If your compiler does not accept this feature, one possible
       way to get the desired result is to compile the called routines
       and calling routines in separate jobs, and then combine the binary
       modules in an appropriate manner.  If this procedure is still not
       acceptable under your system, it will be necessary to radically
       alter the structure of the array RWORK within the LSODES or LSODIS
       solver package.  (See also Note 5 below.)

5. For maximum storage economy, the LSODES and LSODIS solvers make use
of the real to integer wordlength ratio.  This is assumed to be an
integer L such that if a real array R and an integer array M occupy
the same space in memory, R(1) having the same bit address as M(1),
then R(I) has the same address as M((I-1)*L+1).  This ratio L is
usually 1 for single precision, and this is the value used in the
single precision version supplied.

Are such tricks still useful anywhere today or would they be considered extremely bad practice?

Best,

Ivan

[mecej4]

These tricks are mostly unnecessary, since in Fortran 90+ subroutines can allocate and deallocate scratch space as needed, without requiring the caller to provide scratch arrays in the argument list.

For modern versions of the Livermore ODE solvers, see https://computation.llnl.gov/projects/sundials .

[avinashs]

I empathize with the originator of this thread @Aravind R since I have battled with this same issue for several years. Several good responses to the question but here are my comments as a user of IVF:
 
 1. I have been using LSODE since 1993 and it worked for several years with several compilers on Windows(95/NT/2000/XP)/Unix/Linux up to and including Compaq Visual Fortran WITH NO CHANGE IN THE SETTINGS OF THE DEFAULT PARAMETERS. Somehow, the default parameters allowed error-free compilation and linking as well as accurate results with all runs.
 2. With the change to IVF, the default parameters did not allow error-free compilation for reasons outlined above.
 3. However, even within the various releases of IVF, there are changes to default parameters that result in errors (see my recent post on MINLOC/MAXLOC).
 4. I checked a project that had successfully run in 2012 with the new version of LSODE (released first in 2003) but it will not compile today with 19.0.1.144 and the "Yes (/warn:interfaces)" default option is one of the problems for these older codes.
 5. Previously, with IVF, the option /iface:cvf did the trick for these older codes since as described in the IVF manual it "Tells the compiler to use calling conventions compatible with Compaq Visual Fortran*. This value is only available on Windows* systems." That does not seem to work anymore although the code was CVF compatible.
 6. Also, the /warn:interfaces on/off switch seems to be generating a compiler error. Should this not be a compiler warning? The default for "Treat warnings as errors" is no. 

[Steve_Lionel]

/warn:interface diagnostics are indeed errors and not warnings. Similar for /warn:declarations Yes, it seems confusing and inconsistent.

A lot of old code was written in ways that violate the Fortran standard, but compilers of that era didn't detect the problem or the program managed to work anyway. As compilers advanced, both with optimization and diagnostics, the sins of the old code finally catch up to it and errors ensue. This is almost always the fault of the old code. 

I would not expect that /iface:cvf would solve this sort of problem. It might mask it, though.

[mecej4]

avinashs wrote:

I empathize with the originator of this thread @Aravind R since I have battled with this same issue for several years. Several good responses to the question but here are my comments as a user of IVF:
 
 1. I have been using LSODE since 1993 and it worked for several years with several compilers on Windows(95/NT/2000/XP)/Unix/Linux up to and including Compaq Visual Fortran WITH NO CHANGE IN THE SETTINGS OF THE DEFAULT PARAMETERS. Somehow, the default parameters allowed error-free compilation and linking as well as accurate results with all runs.
 2. With the change to IVF, the default parameters did not allow error-free compilation for reasons outlined above.
 3. However, even within the various releases of IVF, there are changes to default parameters that result in errors (see my recent post on MINLOC/MAXLOC).
 4. I checked a project that had successfully run in 2012 with the new version of LSODE (released first in 2003) but it will not compile today with 19.0.1.144 and the "Yes (/warn:interfaces)" default option is one of the problems for these older codes.
 5. Previously, with IVF, the option /iface:cvf did the trick for these older codes since as described in the IVF manual it "Tells the compiler to use calling conventions compatible with Compaq Visual Fortran*. This value is only available on Windows* systems." That does not seem to work anymore although the code was CVF compatible.
 6. Also, the /warn:interfaces on/off switch seems to be generating a compiler error. Should this not be a compiler warning? The default for "Treat warnings as errors" is no. 

These complaints are valid only if you build within Visual Studio and you have /warn:interfaces in your project settings, by default and not by voluntary selection.

I do not use Visual Studio, and my compiler options, as set in ifort.cfg, are just /traceback /MD . With these options, I compiled an ran the first demo program for Odepack from Netlib using IFort 2013-SP1 and IFort 19.0.1. The results agreed with each other and with those provided at Netlib in the file opkd-sum. I did the same test with the NAG compiler, and I found that I had to use the -dusty option of that compiler to overcome the legitimate complaint that arg-10 of the calls to DPREP had the wrong type. 

I reran, using /iface:cvf with IFort 19.0.1. As I expected, the results were not affected at all. In fact, the output results from two runs (i) 64-bit, /traceback /MD and (ii) 32-bit, /traceback /MD /iface:cvf, were byte-level identical (I redirected the outputs to files and compared using fc /b) .

If you are a regular user of old F66 and F77 codes with such benign (and other less benign) errors, simply turn off interface checking for those projects, and manage the ensuing risks. Yet another option is to break up the source file using a Fortran file splitting utility (fsplit in CVF, Sun Fortran, etc.), and to compile the split files separately.

The default options should be those that best match the desires of the majority of Ifort users, whether those are for command line usage or in Visual Studio.

One of the first things that I do after installing Windows, Linux, a new version of Parallel Studio or another compiler package is to change the settings to match my preferences. Since I know that I am not in the majority group, I have no complaints about having to do this minor chore. In fact, I am thankful that there exists a simple and convenient way of setting my preferences and having them stay in effect until the next compiler update.