Opened 7 years ago

Closed 7 years ago

#726 closed defect (Fixed)

Fortran Integer Range

Reported by: arango Owned by: arango
Priority: major Milestone: Release ROMS/TOMS 3.7
Component: Nonlinear Version: 3.7
Keywords: Cc:

Description (last modified by arango)

  • Recently, I introduced at resetting of the reporting of the time-step counter in routine diag.F after 10 billion steps. The formatted field is I10 (ten digits):
               WRITE (stdout,30) MOD(iic(ng)-1,10000000000),               &
               ....
            30 FORMAT (i10, ....
    
    Some compilers seem to have issue with this integer operation. For example gfortran gives:
    diag.f90:383:53:
    
               WRITE (stdout,30) MOD(iic(ng),10000000000),                 &
                                                       1
    Error: Integer too big for its kind at (1). This check can be disabled with the option -fno-range-check
    

To avoid issues with different compilers, I am changing the statement to a floating-point operation:

           WRITE (stdout,30) INT(MOD(REAL(iic(ng)-1,r8),1.0E+10_r8)),  &
           ...

It is more robust to use the MOD intrinsic function with floating-point values.

  • Cleaned the documentation in mod_kinds.F. Both byte and bit were used and it is better to do it in bits. Notice that byte and bit are not the same and can get confusing.
  • I renamed the i4b integer kind to i8b in files gasdev.F, nrutil.F, ran1.F, and ran_state.F to agree with the 32-bit documentation of the random numbers and the definition in mod_kinds.F.

Be aware that SELECTED_INT_KIND and KIND are different in Fortran when declaring integers:

     integer, parameter :: i8b = selected_int_kind(8)

     integer          :: i                    ! default
     integer (i8b)    :: i8
     integer (KIND=8) :: j8

A simple program can be written to examine the largest integer possible using the HUGE intrinsic function:

                Default, HUGE(i  ) =   2147483647
  SELECTED_INT_KIND(1 ), HUGE(i1 ) =   127
  SELECTED_INT_KIND(2 ), HUGE(i2 ) =   127
  SELECTED_INT_KIND(4 ), HUGE(i4 ) =   32767
  SELECTED_INT_KIND(8 ), HUGE(i8 ) =   2147483647
  SELECTED_INT_KIND(9 ), HUGE(i9 ) =   2147483647
  SELECTED_INT_KIND(16), HUGE(i16) =   9223372036854775807

               KIND(1 ), HUGE(j1 ) =   127
               KIND(2 ), HUGE(j2 ) =   32767
               KIND(4 ), HUGE(j4 ) =   2147483647
               KIND(8 ), HUGE(j8 ) =   9223372036854775807

Notice that the SELECTED_iNT_KIND(8) and KIND=8 have very different values. Also notice that the default declaration have the same values as SELECTED_iNT_KIND(8) or KIND=8.

Change History (3)

comment:1 by arango, 7 years ago

Resolution: Done
Status: newclosed

comment:2 by arango, 7 years ago

Description: modified (diff)
Resolution: Done
Status: closedreopened

For some reason, I missed to include the updated files gasdev.F, nrutil.F, and ran1.F when I committed the ticket. We need these files to have i8b instead i4b. This is the reason why some users are having problems compiling because of the mismatch between integer type arguments between these routine and ran_state.F. All the random number generation routines need to have the same integer type (i8b).

Many thanks to Nirnimesh Kumar and Kate Hedstrom for bringing this to my attention.

Last edited 7 years ago by arango (previous) (diff)

comment:3 by arango, 7 years ago

Resolution: Fixed
Status: reopenedclosed
Note: See TracTickets for help on using tickets.