Fortran Analysis, Engineering
& Migration
A four year old workstation is obsolete. Scientific and engineering Fortran codes live for decades.
fpt contains powerful tools for migrating code from one computer system to another.
-
Copy the Files which Make Up the Program: We recommend working under Linux, OSX or Microsoft Windows.
If the original host runs a different operating system, for example, VMS or Gould-SEL MPX, copy the files to
the system which you will use for analysis, preserving the directory structure as far as is conveniently
possible.
-
Check for Completeness: The first step is to identify all of the files which make up the
program or programs to be migrated. This is most easily done by building an fpt project as described
here. The fpt project contains a list of the files and the directories
for the primary and include files. If necessary, the project may contain additional commands to interpret the
file formats of the original operating system or unusual aspects of the original Fortran syntax. Run fpt and
use the command show unresolved references to find out whether
anything is missing.
-
Missing Routines: There may be three classes of missing routines: routines in operating system libraries,
routines written in other languages such as C or assembler, and user-written Fortran routines not yet included
in the project. If there are missing user-written Fortran routines, repeat the first two steps until all have
been found, If there are routines written in other languages, check that everything which they call is
available, and add any Fortran routines which they call to the project. Any user-written routines which cannot
be found may need to be written as part of the migration task.
-
Operating System Routines: If the migration is from VMS and the code contains references to the
VMS system libraries, we strongly recommend that you contact Sector7
to discuss how the code can be migrated. The VMS system routines have names which begin, for
example, LIB$ or SYS$.
Sector7 have very complete emulations of the VMS system libraries under Unix and Linux and considerable
experience in VMS migration. Sector7 can also advise on PDP11 migrations.
If the migration is from Gould-SEL MPX, SimCon have migrated a large proportion of the system routines and can
supply codes. Please contact SimCon to discuss other
operating system library routines.
-
Assembler Routines: Any routines written in assembler must be translated.
Sector7 have experience in translating VMS and PDP11 assembler, and SimCon
have experience in translating Gould-SEL assembler. In these cases the translation is at least partly
automatic.
-
Embedded Assembler: The code to be migrated may contain assembler embedded in-line in the Fortran.
This is particularly common in Gould-SEL codes, and in this case SimCon have a partly automated system
to translate it to Fortran. fpt issues a warning when embedded assembler is encountered. Search the
fpt listing (.fpl) file for the string "assembler".
You have assessed the migration task, and now have an fpt project which reads and analyses all of the Fortran
files. The next step is to set up acceptance tests so that you can prove that the migration is successful.
-
Design a Test-suite: Set up one or more program runs to exercise the code on the original host.
This test-suite will be run several times. If possible, create a command or batch file to run the tests
and capture the output data to file.
-
Measure the Test Coverage: The coverage analysis measures the proportion of the code which is
executed during ther test runs. fpt can systematically modify the code for coverage analysis -
see the fpt command insert coverage for a description of this
process. Repeat steps 7 and 8 until a satisfactory coverage is achieved.
-
Set up Record/Replay: The test runs may involve interactive entry of data. Optionally, fpt can instrument
the code so that all of the input I/O is captured as it is entered, and can be replayed automatically from
a single file. Please see the command insert record/replay.
File I/O may also be recorded and replayed, so this command may be used to repeat runs where data are
read from a database or file system which might be changed by other processes. Record/replay may also be used
to isolate the effects of sub-program calls or inter-process communication. You may choose specific
sub-program interfaces to be recorded and replayed.
Errors are far less portable than correct code. The effects of a mis-matched argument, for example, will
depend on the number format in use. An array reference out-of-bounds will hit different memory locations
on different systems.
-
Make Templates for the Non-Fortran Routines: If the code contains calls to routines written in other
languages such as C and assembler, you may, optionally, use the fpt command
make templates for missing routines to create templates for them. Check that the templates match
the routine interfaces. Where fpt is unable to make a template because the routine has different types
of argument in different calls, check that this is consistent with the behaviour of the routine and
create an appropriate template by hand. Add the templates to the fpt project.
-
Check and Correct the Code: Use the interactive commands in fpt to check the code for errors.
For example, use the commands check arguments,
check names in common and
check equivalence. Correct the code. In some cases fpt
has commands which make the corrections automatically, e.g.
correct inconsistent arguments. In other cases the corrections must be made by hand. Re-test the corrected
code on the original host. If the code doesn't run correctly on the new host, we need to know that this is
because of the migration process, not because of an existing bug which has shown its symptoms in a
new way. See the Quality Assurance pages for further description of the checks.
-
Make an fpt Project to Convert the Code: fpt converts many language extensions to standard code in
a single pass and in very much less time than the Fortran compilation. Make an fpt project to produce the
changes required, and run it repeatedly, making test compilations on the new host, until everything builds.
In this way we avoid the situation where the source is modified manually through intermediate
stages where it won't run on either host. The changes required depend on the characteristics of
the hosts. fpt has extensive facilities for migration:
-
Run the Test-suite on the New Host: Run the test-suite on the new host and attempt to replicate the
results from the original host. Iterate steps 14 and 15 until a reasonable match is achieved.
-
Finding Why the Results are Different: It is very unlikely that the results of a large program will
be exactly the same on two different hosts. Small differences in rounding, due to different orders of
computation within expressions cause numerical drift between the results. fpt may be used to eliminate
numerical drift, using the run-time trace facility.
This may expose errors in the original code or in the compilers.