Today I had the pleasure of speaking to Prof. Jeff Terry’s computational physics class at IIT today. The topic was software recovery and was focused on my experience resuscitating the Jeppson pipe network analysis codes. I think this is the third or fourth time I’ve spoken to one of his classes and I always enjoy and appreciate the opportunity.
Recovery and revitalization of legacy scientific code can seem like a daunting task – it doesn’t have to be if you use a phased refactoring strategy. Reduce schedule risk by focusing your efforts with a plan not just to reconstitute a working software build, but to revitalize code so it is testable, maintainable, and ready for enhancement. It may take less effort than you think to get control of your legacy scientific code and change it from being viewed as a liability to the asset it is. Download the Jeppson pipe network flow software recovery white paper.
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
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
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.
Today’s Fortran Library of the Today is FLAP (Fortran command Line Arguments Parser for poor people)
From FLAP’s Github page:
A KISS pure Fortran Library for building powerful, easy-to-use, elegant command line interfaces
FLAP is a pure Fortran (KISS) library for building easily nice Command Line Interfaces (CLI) for modern Fortran projects;
FLAP is Fortran 2003+ standard compliant;
FLAP is OOP designed;
FLAP is a Free, Open Source Project.
FLAP is inspired by Python’s
argparse library which involves instantiating a CLI object, registering options and arguments along with descriptions, optional/required status, argument count and type, etc., then parsing and evaluating the command line arguments. The library also generates help/usage messages, manual pages, and other user documentation and handles any errors in user input.
I have yet to put FLAP through its paces but it looks like a great candidate for the Hypothetical Fortran Standard Library!
I work in a number of different languages depending on the project. For rapid prototyping I use Jupyter Notebook with Python 2 or 3 which is then converted to standalone code, documents are written in Markdown or LaTeX and compiled to HTML or PDF, Fortran is used for heavy computation, etc. I also revitalize a lot of legacy FORTRAN IV and FORTRAN77 code so I frequently find myself wishing I had the capabilities found in the standard libraries of more modern languages. I also miss certain language-specific development tools which don’t have a Fortran equivalent.
In the previous post, I lamented the lack of a standard library in Fortran and briefly reviewed the contents of the standard libraries for both C and Python. While these languages serve different roles than Fortran, they are popular and mature and I felt they were worth investigating for inspiration. This post covers two topics: first, I present a brief summary of how a hypothetical Fortran Standard Library could be created and adopted (the “Big Picture“), and second I look at the standard libraries of Julia, R, and Ada.
The Big Picture approach I am taking is to:
- describe the problem (lack of a standard library),
- show how other languages address it,
- set high level policies and goals,
- define & implement an achievable initial library,
- have people use it and provide feedback, and,
- iterate over 4 through 6 until the library is stable, adjusting the policies and goals in 3 to ensure the library is implementable, stable, usable, and meets with community approval.
Following this model, we can define high-level capabilities we want in a standard Fortran library and then get into the details of what functions are necessary. In software engineering terms, that means setting requirements and creating design and functional specifications.
One of Fortran’s major drawbacks is its lack of a standard library, a formally defined set of components outside the language core which are supplied along with the compiler. Recent revisions of the Fortran standard have defined several standard modules (ISO_C_BINDING and ISO_FORTRAN_ENV are the two best known) but these do little more than define constants and data types. As of 2017, there are no standard libraries for (say) operating system or filesystem access, string handling, searching and sorting, or networking.
Since Fortran is primarily used for numerical computing, the lack of a standard network library may not be a great disadvantage. However the lack of filesystem tools and text manipulation and parsing tools severely limit the utility of the language.
Before asking what should be in hypothetical Fortran Standard Library, it might be helpful to review what’s in the standard libraries of other languages such as C and Python.