17374496333_54c62d9372_k.jpg

Legacy Fortran modernization

Introduction

http://www.booktopia.com.au/http_coversbooktopiacomau/600/9781498738606/the-finite-element-method.jpg

http://www.booktopia.com.au/http_coversbooktopiacomau/600/9781498738606/the-finite-element-method.jpg

In my efforts to learn Fortran, there were two main skill sets I was hoping to develop: using the language to create my own code, and translating legacy code (mainly Fortran 77) into modern Fortran. In looking up different HPC (high performance computing; more or less supercomputers) centers, I came across Dr. Darrell Pepper and Dr. Juan Heinrich's book The Finite Element Method and the code examples written for the book posted on their UNLV website. In reviewing the code, it looks to be mostly in a 77 style, and in talking to Dr. Pepper, it sounds like the code hasn't had major revisions since the 70s. In short, it looked like a good opportunity to work with some legacy Fortran and maybe even learn some finite element analysis along the way.


So what are the major differences in legacy and modern Fortran?

Some of the changes that entered the language after the 77 standard are relatively minor. Some of the ones I'll be changing in my version are:

  1. Defaulting to lowercase for readability. Fortran 77 and older only supported uppercase characters.
  2. Replacing .EQ., .GT., etc. intrinsic functions with their more intuitive ==, >, etc. counterparts.
  3. Using "end do" instead of the do [tag] [iterator] syntax.
  4. Moving from fixed format to free format and using indentation. 
  5. Replacing loops with array operations where possible.

Some of the major changes are:

  1. Eliminating the use of GOTOs. 
  2. Eliminating implicit typing
  3. Replacing COMMON blocks with modules.
  4. Organizing methods into different modules, instead of having a single, monolithic source file.
  5. Making data and methods private where possible to reduce data access.
  6. Having arrays be allocatable where possible instead of having their sizes hard coded.

Also, in general, I tried to maintain some kind of style and best coding practices, although I am learning those as I'm doing this project, so it may be slightly inconsistent.


What about future improvements?

Part of this depends on the needs and interest of the authors. I'm not sure it does me any good to perfect code that won't be used or doesn't meet the needs of the readers of this text. But, left to my devices, I'd like to:

  1. Improve the data management of the code. Right now data flow depends heavily on essentially global variables. I'd like to make the data flow more explicit and traceable. I'd also like to use some object oriented programming in order to make sure the input data can't be altered once read, for instance.
  2. Vectorize computations. The original code does vector and matrix calculations element by element. It's correct, but I'd like to gain a better insight into FEM so that these calculations can use the vectorization features of Fortran and be a bit more compact and intuitive.
  3. Parallelize computations. A lot of work going into the Fortran standard since 2003 or so has been around parallel computation, as you might expect for a language used heavily in HPC. Several features in Fortran can implicitly parallelize, such as forall, do concurrent, and coarrays, and there are also several explicit options such as OpenMP and MPI. There are differences in how each of these work that make them better or worse options depending on the system, but it might allow much larger examples to be given online than were possible with the previous code.
David PernerFortran, FEM