Selection of format a concern

I have 2 format commands, depending upon a given variable value.

The format commands are as follows:

 201  format(' HYDRO OUTPUT: ', 1i5, 1p, 7d15.5, 0p, 1f12.7)
 202  format(' HYDRO OUTPUT: ', 1i5, 1p, 4d15.5, 0p, 1f12.7)

Whilst the calling routines are within this selection piece…

if (massonly .EQ. 0) then
            accL = 0.75 * GRAV * CorM * fluxM / CorR
            totL = accL + CorL
            write(6,201) i, TIME, DTIME, CorM, CorR, CorL,                &
     &      totL, fluxM, smass
            write(6,202) i, TIME, DTIME, CorM, fluxM, smass

The thing is that I believe this runs the first, then progresses onto the second command (the second is followed by an END command, which I assume returns the code back to where it came from?

Am I wrong and, if so, where might I be going wrong?

For clarity, if I have massonly set to 0 or 1, I get the same output results.

Only one part of the if block should be executed, based on the value of massonly. I am surprised by your last statement about getting the same results regardless of the value of massonly. Could you try printing massonly before entering the if block to make sure that it is being set properly?

Yes, that is my plan. Unfortunately, as I hit this issue I had to go out for the afternoon (a lovely time out, I hasten to add but it did take me away from my code).

At least I am not missing something obvious in my coding; thank you. :slight_smile:

Yes, a good old print as suggested by @Beliavsky .
And is massonly declared as an integer? (why not use a LOGICAL?)

But if I have understood, you say both the IF block and the ELSE block are executed, which looks impossible in that piece of code. But if the IF is in a loop I can imagine the two WRITE could be executed in two different iterations if the massonly variable is accidentally modified. But then the printed variables would probably have some differences, especially i.

Sorry, I have created confusion; never write in haste! :slight_smile:
What I mean is that no matter what I set massonly to (I have it set inside the code physically as 1 then 0) it only runs as if the value is one. However, I will check again and see what happens.
In terms of the use of data type, I did look at setting it as a Boolean but read that this wasn’t a data type that Fortran recognised; am I incorrect there then?

(Obviously I am, so I will explore further once again).

Thank you so far!

1 Like

As far as I know, the LOGICAL data type (booleans) was introduced into the FORTRAN IV compiler, released in 1962. :older_man:

1 Like

The hilarious thing is that I thought I would just find where I had read that Fortran didn’t support Boolean, repeated the same search I did before and ALL I can find are references to using Boolean/logical within Fortran.

DOH! Ha ha ha!

Okay, changing variable now.

1 Like

And the amazing thing is that everything is now working just fine?!

Never code in a rush; there’s the lesson (that I have failed to learn time and time again).

Thanks for all the help (and, yes, it is now a Boolean). :slight_smile:

1 Like

Note also that in modern Fortran (>=90), you can use the more readable operator == instead of .EQ. to test the equality of numbers.
See fortran - Difference between .eq. and == - Stack Overflow

I’m using Fixed Format rather than free form (so, .f rather than .f90); though I might convert it all over time.

Not sure if that is related to swapping .EQ. with == (which would be sooo nice). :slight_smile:

No, that was just an additional remark. .EQ. and == are equivalent.