C/C++ Solving a "Logical" Error in Fortran/C++ Model

[lolay]

i"logical" error?

Hi all,

I hope you can help me with this. I'm running a long and complicated model (I didn't created it) which is written in both fortran and c++. Both parts of the model are compiled together by using a makefile, and I'm using the GNU compilers for it (gfortran and gcc).

Running the makefile I get this error from the fortran part:

dyn1003-29:Macvs1-fromHPvs2 LLM$ make
gfortran -x f77-cpp-input -o main-std.o -c main.f
main.f:10879.12:

IF (present(pft)==.TRUE.) THEN !.AND.tree(pft)=
1
Error: Logicals at (1) must be compared with .EQV. instead of .eq.
make: *** [main-std.o] Error 1


Do you have any clue of where this can come from?

Thanks in advance!

 

[SteamKing]

It looks like the IF ... THEN statement has been joined erroneously with the logical operator .AND.

I would try to rewrite as:
IF (present(pft)==.TRUE.) .AND.tree(pft)= THEN
.
.
.
ENDIF

I don't know what logical condition the programmer was trying to test for with the tree(pft) part of the conditional statement.

 

[lolay]

Thanks SteamKing,

I can't try it now, but I'll let you know how it goes as soon as I do

Cheers

 

[Mark44]

Slight correction to what SteamKing wrote...

It looks like the IF ... THEN statement has been joined erroneously with the logical operator .AND.

I would try to rewrite as:
IF (present(pft)==.TRUE.) .AND. (tree(pft)==<something>)[/color] THEN
.
.
.
ENDIF

I don't know what logical condition the programmer was trying to test for with the tree(pft) part of the conditional statement.

That expression, tree(pft)= , can't be valid.

 

[I like Serena]

Hi lolay! Welcome to PF!

        IF (present(pft)==.TRUE.) THEN                  !.AND.tree(pft)=

It looks as if the text after the '!' is supposed to be commented out, especially seeing how it is indented (which shows when you use [ CODE ][ /CODE ] tags ).

Just remove it or prefix it with proper comment symbols.

Note that tree(pft) sounds as if it tests whether "pft" is a "tree".
present(pft)==.TRUE. probably does the same thing.
So we're probably looking at a quick hack or a historical left over.

 

[lolay]

Hi!

Thanks for all the replies...but, and I´m sorry because I should have deleted it, the part "!.AND.tree(pft)=" is commented in my program, so that shouldn´t be the source of error (it´s just a part that was eventually deleted and left the comment as testimony, as I like Serena said).

The program has actually worked in other computers, so I´m not sure if the problem comes from that statement, unless changing he compilers (from ifort to gfortran) implied a change of rules. Is there any way of knowing where the problem is really coming from, if it´s not due to that statement?


Thanks!

 

[DrGreg]

IF (present(pft)==.TRUE.) THEN !.AND.tree(pft)=
1
Error: Logicals at (1) must be compared with .EQV. instead of .eq.
make: *** [main-std.o] Error 1

It's 35 years since I last programmed in FORTRAN, so I'm a bit rusty, In those days there was no such thing as "==", you had to use ".EQ." instead.

This seems to the problem: your compiler is treating "==" as if it were ".EQ.", but then complaining that it ought to be ".EQV." instead (whatever that is).

 

[Mark44]

I think that DrGreg hit the nail on the head. present(pft) is apparently a boolean expression that is being compared to .TRUE. According to this site, comparisons of boolean expressions should use .EQV. or .NEQV., not .EQ. or .NE.

http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Equivalence-Versus-Equality.html

Here's an excerpt from this page:

15.5.5 Equivalence Versus Equality
Use of .EQ. and .NE. on LOGICAL operands is not supported, except via -fugly-logint, which is not recommended except for legacy code (where the behavior expected by the code is assumed).

Legacy code should be changed, as resources permit, to use .EQV. and .NEQV. instead, as these are permitted by the various Fortran standards.

New code should never be written expecting .EQ. or .NE. to work if either of its operands is LOGICAL.

The problem with supporting this “feature” is that there is unlikely to be consensus on how it works, as illustrated by the following sample program:

     LOGICAL L,M,N
     DATA L,M,N /3*.FALSE./
     IF (L.AND.M.EQ.N) PRINT *,'L.AND.M.EQ.N'
     END

The issue raised by the above sample program is: what is the precedence of .EQ. (and .NE.) when applied to LOGICAL operands?

 

[lolay]

Hi all!

I finally changed "==" for ".EQV." and seemed to work (now I have other errors, but that one didn't appear again).

Thank you so much!

Cheers

Lolay