CODEWITHSUNDEEP
inputfortran
New Developer
New Developer

Reputation: 89

Type mismatch error compiling vintage F77 code

I want to compile a computational code named MOLSCAT which uses a NAMELIST data as an input file like Test. According to the main code, the compiler reads the input in channel 5. I put the input file in the main code folder and compiled the main code in Linux version of Simply Fortran. But with or without the input file, it gives the output

==============================================================
Generating Makefile... Okay
==============================================================
Compiling /home/farhad/Downloads/v14.f
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -   
  /home/farhad/Downloads/v14.f:2381:17:

   1    PARITY(IEXCH+JLEV(2*NLEV+I)+JTOT+JZCSFL*JLEV(IOFF+I)).LE.0.D0)
             1
   Error: 'mask' argument of 'parity' intrinsic at (1) must be LOGICAL
- - - - -  - - - -- - - - - -- - - - -- - - - - -- - --  -- - - -- - -
/home/farhad/Downloads/v14.f:10720:39:

 4000 CALL CPL24(N,MXLAM,LAM,NLEV,JLEV,JLEV,J,MVALUE,VL,PRINT,LFIRST)
                                   1
  Warning: Type mismatch in argument 'atau' at (1); passed INTEGER(4) to REAL(8)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Error: Last command making (build/v14.o) returned a bad status
 Error: Make execution terminated

* Failed *

Does anyone know what is the problem?

Upvotes: 1

Views: 593

Answers (3)

Jeremy Hutson
Jeremy Hutson

Reputation: 31

I'm the author of MOLSCAT so I can give some definitive answers on this one.

First, this query probably refers to MOLSCAT version 14 from 1994 or so, which was indeed written for FORTRAN 77. I can supply the current version, 2019.0 (beta), which is fully documented and will (I hope) be published in 2019. It's free.

Yes, MOLSCAT v14 has a double precision function parity which takes an integer argument and returns +1.d0 if the argument is odd and -1.d0 if it is even. FORTRAN has since introduced an intrinsic with the same name. We've renamed the function PARSGN in the current version.

MOLSCAT also uses some hokey old FORTRAN features (dating from FORTRAN IV), such as dimensioning arrays at (1) or (2) to suppress array-bound checking. It also economises on storage by passing slices of a double precision array to routines that declare them as integers. Since FORTRAN passes arrays by reference, it works, provided the compiler doesn't do over-zealous comparisons between routines. Just ignore those warnings.

There are also some other deprecated/obsolete constructs such as computed GOTO and arithmetic IF. We've mostly rewritten them in parts of the code that people actually use, but there are some little-used sections that are not worth the effort but shouldn't be deleted in case users want to reproduce old work.

Jeremy Hutson

Durham University

[email protected]

Upvotes: 3

agentp
agentp

Reputation: 6989

re: the second type mismatch warning. They appear to be deliberately passing symbols to the different type:

 CALL CPL24(N,MXLAM,LAM,NLEV,JLEV,JLEV,J,MVALUE ....

note the repeated integer array jlev in pos 5&6, then in the sub:

 ENTRY CPL24(N,MXLAM,LAM,NLEV,JLEV,ATAU,J,MVAL ..

they have an integer and real dummy variables in those positions. Without dissecting the whole code I believe this is intentional and you should ignore the warning.

Another thing I notice, all over the place they dimension arrays 2

  INTEGER J(N),L(N),LAM(2),JLEV(2)
  INTEGER PRINT
  DIMENSION ATAU(2),VL(2)

I'm pretty sure (having seen this before) these are actually assumed size arrays ( essentially counting on the old compiler not doing bounds checking ). That is ok but it means you will not be able to do bounds checking on this code. Any old timers guess why they used 2 ?

Upvotes: 0

Matt P
Matt P

Reputation: 2347

Take cues from the error messages, the hints are usually good. However, errors often cascade, causing other problems even in code that is fine, and that may be why you see so many messages. My advice is to fix the first error listed and try to run again.

These are the errors you've shown in your post:

  1. Parity intrinsic: the problem here is the argument is not an array of logicals. Look closely - there appears to be a typo...look for a missing parenthesis. Fix it and the function should return the expected result. Try running the code. The other errors might disappear.See Note
  2. Type mismatch: the message quite clearly says that an an integer (evidently single precision) was passed in but the code is expecting a real (evidently double precision). I see that implicit typing is used, so that can be the source of this particular bug. I recommend that you follow ATAU through the program and track what happens to it.

Also, come on NASA - Mole Scat??

Note: Ah, I see now: parity is a function defined in the MOLSCAT source code at line 11691. It is not the parity of the (current, 2008) Fortran standard library. It is defined with:

FUNCTION PARITY(I)
IMPLICIT DOUBLE PRECISION (A-H,O-Z)
PARITY=1.D0
IF((I/2)*2-I.NE.0) PARITY=-1.D0
RETURN
END

There is a name conflict here between the source code and the intrinsic in the F2008 standard. I'm not sure how to disable this for compatibility with F77 other than renaming the function in the source code. You may be able to place a new line in the main program: external parity in order to use the function as defined in MOLSCAT...There is a relevant discussion here, perhaps someone like @SteveLionel has some input.

As a side note, I have no idea why this is a useful function. When would it ever return -1.D0?

Upvotes: 1

Related Questions