January 2018 – Acorvid Technical Services Corporation

A common problem when revitalizing old scientific software is the need to recreate a working build environment. With standards-conforming code, this is usually straightforward, often a matter of setting a few compiler flags to initialize variables, persistently save local variables, adjust floating point exception-handling, etc. Occasionally one is faced with code that made use of library routines which are not available under the current build environment or which require a software license incompatible with the legacy code’s license. This is especially true of the routines provided with the book Numerical Recipes; back when the book was used as a primary text for numerical analysis, less attention was paid to software licenses and most students (now practicing engineers and developers) were unaware the code from the book was proprietary and could not be redistributed without a commercial license.

The Acorvid Legacy Fortran Compatibility (ALFC) library was created to assist in revitalizing legacy code by providing an open API to a number of proprietary and vendor-specific libraries. At present it contains compatibility interfaces for Numerical Recipes functions (FORTRAN 77 version) and the Sperry-Rand UNIVAC large scale systems libraries, MATH-PACK and STAT-PACK. The ALFC library is licensed under the MIT License which should be permissive enough for almost any application.

Today I saw a reference to The new features of Fortran 2018 float past on Twitter. The WG5 standards committee has renamed the forthcoming language revision to Fortran 2018 from Fortran 2015 to reflect a more accurate release date. Many of the changes focus on coarrays and distributed computing but there were several useful clarifications of existing features. I was very happy to see that COMMON, EQUIVALENCE, DO <label>, FORALL, and arithmetic-IF have finally been marked as obsolescent and are on their way to the dustbin of computing practice. All but FORALL are leftovers from FORTRAN 77 and earlier. Modern Fortran provides much better and clearer facilities for persistence, aliasing, and dynamic memory management than COMMON and EQUIVALENCEand modern control structures make DO <label> and arithmetic-IF redundant. Numeric line IDs seem to attract spaghetti logic so I see the slow deprecation of these features as a welcome change to the language to improve code quality, reliability, and maintainability. When refactoring code, I tend to refactor away all four of these constructs anyway but it is heartening to see the standards committee recognize these features are problematic enough to (eventually) remove them from the language

In the case of FORALL, the construct never worked up to its potential and has since been replaced with DO CONCURRENTwhich fits more into the DO <iteration style> syntax model. FORALL is rarely used because it never reliably performed any better than a conventional loop. My early experience with modern Fortran led me to experiment with FORALL; finding that it didn’t offer any advantages on any of the compilers I used at the time led me to abandon it, though I really need to look deeper into the coarray model for concurrent execution.

If you have had experience applying coarray features to legacy code, please let me know in the comments or via email (address listed on the contact page). I’m curious what strategies you’ve found to work.

Introducing the Acorvid Legacy Fortran Compatibility Library

What’s New in Fortran 2018!