Fortran at the U.S. Geological Survey

The U.S. Geological Survey provides the MODFLOW hydrologic model, which is considered an international standard for simulating and predicting groundwater conditions and groundwater/surface interactions.

The latest release is known as the MODFLOW One-Water Hydrologic Flow Model. The MODFLOW code is written in Fortran and can be found here.

A search of the USGS website reveals several other interesting Fortran projects, including the Batteries Included Fortran Library (BiF-lib). The actual code can be found here and is under an Apache license. It contains several things you would expect in a standard library.

8 Likes

Did you try BiF-lib? I tried to compile it with gfortran 10.0 but there are some errors. I think that this library was developed with ifort.

Does it compile with gfortran with the -std=legacy option? That’s the first thing to try.when something does not compile by default with gfortran. If it still does not compile, can you list the errors?

1 Like

After checking the errors, this library uses modern fortran features such as do concurrent, functions of the iso_binding_c module and some other intrinsic functions defined in the fortran 2003 and fortran 2008 standard. These features are all available in gfortran 10 but IMO the errors are due to ifort syntax (e.g do concurrent (integer :: i )). It is possible to specify the compiler in the makefile (using make COMPILER=gcc F90=gfortran), but the errors still appear.

I have tried gfortran 8,3 in windows and gfortran 10.2 in a linux box but the errors are still there.

That appears to be standard-conforming syntax starting Fortran 2008.

2 Likes

Thanks for the information about the do concurrent in the fortran 2008 standard, I did not know that. However, gfortran shows the do concurrent (integer :: i …) as an error (using gfortran 8.3 in windows and 10.2 in linux) which means that this is not currently implemented in this compiler.

do concurrent was added to GNU Fortran 8. Make sure you use the correct syntax for concurrent do loops:

integer :: i

do concurrent (i = 1:10)
    print *, i
end do

Sorry, I missed that the source code uses Intel compiler extensions standard conforming F2008 features that are probably not implemented in GNU Fortran 8. Probably has be to solved manually via search and replace.

2 Likes

@interkosmos Thanks for your reply. Yes, the code that you posted worked fine in gfortran 8.3 and 10.2 I was referring to the syntax do concurrent (integer :: i…) which gfortran shows as an error. And you are right, this can be solved with a search and replace. However, there are other compilation errors that might be caused by some missing features in gfortran.

Well, the following is a conforming program that gfortran does not support, so interested gfortran users can file a request at GCC Bugzilla. Or better yet will be if a lot more Fortran practitioners become highly enthused to contribute to GCC/gfortran as C developers to enhance the front-end for Fortran.

   integer :: x(3)
   do concurrent ( integer :: i = 1:size(x) ) 
      x(i) = i
   end do
   print *, "x: ", x
end

C:\Temp>gfortran -c p.f90
p.f90:2:18:

2 |    do concurrent ( integer :: i = 1:size(x) )
  |                  1

Error: Syntax error in DO statement at (1)
p.f90:4:6:

4 |    end do
  |      1

Error: Expecting END PROGRAM statement at (1)

2 Likes

The source code of BiF-lib does not seem to be valid Fortran. I tried:

$ gmake COMPILER=gcc F90=gfortran CONFIG=release

And got:

[…]
gfortran   timer_instruction.f90

./src/datetime/timer_instruction.f90:599:8:

  599 |         SEC = SEC - day2sec*REAL(ITMP, dbl)
      |        1
Error: Variable 'sec' cannot appear in a variable definition context (assignment) at (1) in PURE procedure
[…]

Having a look at the source code in src/datetime/timer_instruction.f90 shows:

  PURE FUNCTION PRETTY_PRINT_TIMER(SEC, LEVEL) RESULT(TIM)
    REAL(DBL), VALUE:: SEC
        […]
        SEC = SEC - day2sec*REAL(ITMP, dbl)  

IIRC, overriding dummy arguments passed as value is not permitted.

1 Like

@interkosmos I got the same errors with the pure functions and also with some intrinsic functions due to differences in the precision of the input arguments (iand function with integer16 and integer 32 inputs). It seems that this library compiles with ifort without problem.

No, the Fortran standard permits dummy arguments with VALUE attribute to be used in a variable-definition context provided they are not declared with INTENT(IN) attribute.

The PRETTY_PRINT_TIMER function, at least as shown upthread, looks standard-conformant - again, gfortran does not appear to have caught up with the standard here.

2 Likes

I’ve found non-conformances in BiF-lib. There are equality operators between Integer and Logical. There doesn’t seem to be a way of contacting the author or submitting issues or pull requests.

1 Like

You can try to contact Scott Boyce from USGS, directly. He can also add you to their GitLab server.

1 Like