Multiple versions of the Fortran standard in the source code

[Yann Pouillon]

In connection with the heterogeneity of Fortran file extensions, LibGridXC 0.7.3 contains legacy Fortran 77 code. The following files use a severely outdated fixed-form file format:

    cellsubs.f
    ggaxc.F
    ldaxc.F
    m_fft_gpfa.F
    m_io.f
    minvec.f
    radfft.f
    sorting.f

This has a negative impact for the library at several levels:

  - performance: legacy fixed-form Fortran 77 code is not optimized as much as modern free-form code by most compilers, the difference possibly spanning one or two orders of magnitude in terms of vectorization;
  - reliability: Fortran 77 being underspecified and ill-designed for modern computer architectures, most compilers disable consistency checks that would otherwise cause many compile-time errors;
  - usability: modern Fortran relies on modules and strictly defined calling interfaces, which is not possible with legacy Fortran 77;
  - portability: object code produced by modern compilers from legacy Fortran 77 is subject to random variations;
  - debuggability: legacy Fortran 77 cannot be tested, instrumented and profiled as completely and as automatically as modern Fortran;
  - attractiveness: young researchers openly hate Fortran, and even more explicitly legacy Fortran 77, which has clearly become a severe handicap to get contributions and contributors.

Fortran 77 has been considered as technical debt in a steadily growing number of projects and communities for around 10 years. It is important to address this issue and remedy the associated code smells before software entropy becomes unmanageable.

The current Fortran standard version fully implemented in all compilers is now Fortran 2003 (apart from a couple of exotic language features that should not be used anyway). It greatly improves over Fortran 77 and allows a significant code refactoring, in addition to providing extended interoperability with other programming languages. Most electronic structure codes have been switching to Fortran 2003 since 2015. The Fortran interfaces of the Electronic Structure Library – in particular those of LibXC – are also guaranteed to be Fortran 2003-compliant.

It is extremely recommended that all source code of LibGridXC be made compliant with Fortran 2003 and all legacy Fortran 77 code be fully refactored. Most of this task can be performed automatically thanks to a few SED commands.

[Alberto Garcia (albertog)]

These are just comments and questions to try to frame and improve my understanding of the issue.
I broadly agree with you on the need to update the code.

I agree that f2003 should be the target standard for new code. Procedure pointers,
allocatable strings, interoperability with C, allocatable array extensions, etc, are quite useful and let you think more freely about algorithms and data structures.

While I agree that the fixed-form file format is prone to errors, note that what you call "f77" is a subset of f2003, and hence valid (and I would say that fully supported) Fortran. Only deprecated and truly dangerous features such as arithmetic if, equivalence, etc, should be strictly avoided.
How do you plan to convert from 'f77' to 'f2003'? If you are just going to use 'sed' scripts, it seems that you are just changing the format. Note that a lot of code (in Siesta, for example) is fixed-form >f90. I guess you also plan to put things in modules, or create interface blocks.

What you say about the performance penalty for fixed-form (and f77) is completely new to me. Unless some compiler vendor has gone crazy and let a huge legacy of f77 code underperform, I cannot really see what the reason would be for the performance penalty. If anything, it used to be that "new" f90 compilers would have trouble optimizing code because of the new pointer facility, absent in f77.
Do you have references about this?

[Nick Papior (nickpapior)]

A comment to the f77 performance issue. This is also something I have never experienced. If one "mixes" (as is done throughout siesta and libgridxc) intents with f77 one can get the correct aliasing. And if a simple conversion between format is done, no difference will be experienced (unless f77 weirdness stuff are around the code).

I can say for Intel compilers that there are no difference. Steve Lionel has confirmed this on a couple of occasions in the Intel forum as far as I remember.

Indeed I would also be very surprised if this was the case for gcc, i.e. only weird cases of f77 features may result in less performant code.

[Yann Pouillon (pouillon)]

Re-reading my comments now, I realize that I mixed-up different concepts.

What I can tell now that we are using LibGridXC in the ESL Demo is that both fixed-form and .[Ff] extensions have become an impediment with new GCC versions and should be dealt with as soon as we can.

It has indeed become quite difficult to preserve the portability and genericity of the build system in the context of the ESL Bundle. Using fixed-form for Fortran 90/95/2003/2008 files tends to confuse the newest versions of some compilers.

I thus propose to upgrade all the source code of LibGridXC to free-form with .[Ff]90 extensions, at a suitable date chosen by Alberto, in order not to interfere with ongoing developments.

[Yann Pouillon (pouillon)]

P.S.: Once you are satisfied with the new build system, we'll be able to talk about wether you want systematic preprocessing or not.

[Alberto Garcia (albertog)]

I agree with upgrading the source code to free-form.
No other development is ongoing now, just the auto-toolization by Yann.

[Nick Papior (nickpapior)]

Perfect, I will commence the transition!

[Jose M Soler (jose-soler)]

I agree with changing to free format, if that helps in any way.

Aside from the fixed format, I do not see anything 'old' in the interfaces of those files (all modules), that could hinder optimization or debugging, except:
cellsubs.f add intent to arguments (very easy)
minvec.f add intent to argument of volnew (very easy)
sorting.f add intent to arguments (easy)
m_fft_gpfa.F remove (*) dimensions (perhaps not easy)
In addition, this later file contains very old third-party code, whose license I ignore. In the future, it would be higly desirable to substitute it for a modern GPL fft code.

Two independent issues that I think should be done in libGridXC:
- In gridxc.F90, add comments for the explicit interface of setxc_family_authors and setxc_libxc_ids, similar to those of the other public subroutines
- Write C-interoperable interfaces for the public subroutines of gridxc.F90, as well as documentation for the C bindings.

[Nick Papior (nickpapior)]

Thanks for your valuable comments Jose!