Error: Comma required after P descriptor in format string

Question

When I try to compile calrank.for (CALRANK_v7.0.0_L140912.zip) with gfortran I get this error:

> gfortran  -m64 -c -o calrank.o calrank.for
calrank.for:1922:32:
         write(io,'(2f10.3,1p1000(2x,e16.7,1x,2a10,1x))')
                                1
Error: Comma required after P descriptor in format string at (1)

When I make a comma I got the same error.
I note only that the code was compiled before with LF95.

   subroutine xycout(io,nrank,nsp)
      use userinf
      use header
      use rankdata

      implicit none

    integer :: io,nrank,nsp
      integer :: k,ir,is,i
      character(len=20)   :: head1,head2,head3
      character(len=40)   :: add1x,add2x,add3x
      character(len=40)   :: add1(nsp),add2(nsp)
      character(len=40)   :: add3(nsp)
 ......
 c --- Loop over receptors to write data records
      do ir=1,ntotrec(k)
         write(io,'(2f10.3,1p1000(2x,e16.7,1x,2a10,1x))')
     &                   xreckm(ir,k),yreckm(ir,k),
     &                  (xounit(is,k)*rankvalue(ir,is,nrank),
     &                   arankdate(ir,is,nrank),
     &                   aranktime(ir,is,nrank),is=1,nspout(k))
      enddo

      return
      end

Some variables are defined in other place of the code as:

c --- Real arrays for header (derived)
      allocate (xreckm(mxrec,k),yreckm(mxrec,k))
c --- Modified units multiplier
      allocate (xounit(mxspout,k))
      c --- Array of values (all species, receptors) for requested ranks
      allocate (rankvalue(ntotrec(k),nspout(k),n_ranks))
      allocate (arankdate(ntotrec(k),nspout(k),n_ranks))
      allocate (aranktime(ntotrec(k),nspout(k),n_ranks))
c --- Integer arrays for header
      deallocate (ndrec,nctrec,nspout,i2dmet,iutmzn)

Answer 1

@francescalus suggested I expand on my comment.

First, Fortran generally requires a comma between two "format items". A format item is an edit descriptor (F, E, etc.) with or without a repeat count preceding it, or a parenthesized group of format items (which may have its own repeat count; @Vladimir F mentioned * - this is an "unlimited repeat count" and may be used only with a parenthesized group.

The comma may be omitted:

• between a P edit descriptor and an immediately following F, E, EN, ES, EX, D, or G edit descriptor, possibly preceded by a repeat specification,
• before a slash edit descriptor when the optional repeat specification does not appear,
• after a slash edit descriptor, or
• before or after a colon edit descriptor

Now as for the P edit descriptor, this sets the scale factor and it is indeed strange and has very different effects depending on what kind of editing you're doing. It also is "sticky" and applies to all later editing in that format.

On input, it causes the read value to be divided by 10**k, where k is the scale factor (2P means k=2, etc.). So if the characters in the input is 123 and 2P is in effect, the value reads as 1.23. Similarly if -2P was in effect, 123 would read as 12300. A decimal point in the input doesn't change this, but an exponent removes the scaling. So 1.23 read with 2P is .0123 but 1.23E0 is 1.23.

On output with F editing, it makes the output value to be multiplied by 10**k, reversing the input scheme.

You may ask WHY??? The answer lies in punch cards, an input (and sometimes output) form used in the 1950s through the 70s. These had 80 columns and wasting a column on a decimal point could be a problem. So a scale factor allowed one to omit the decimal point but still get fractions.

But wait, it gets stranger! On output with E and D editing, the scale factor simply determines the number of leading digits to the left of the decimal point (and a subsequent reduction of the exponent. So for a value of 1.23 and a format of 2P,E11.3, you'll get b12.300E-01 (b=blank unless SP is in effect, which is a reply for another day.)

And for output with G format? Even weirder. If the value is in the range where you get the equivalent of F format, the scale factor has no effect, otherwise it behaves like E.

Lastly, the scale factor has no effect on EN, ES or EX editing. (EX? That's a F2018 feature for hexadecimal floating point output.)

One good use of P format is when doing currency calculations with integers instead of reals, as the latter can lose precision (.01, for example, has no exact binary float representation.) Assuming the values you're dealing with aren't too big, you can read dollars and cents into an integer with a -2P format and not lose any pennies doing addition, subtraction and multiplication. I once wrote a mortgage calculator this way that was precise.