Fortran Program Porting Issues (egcs version)

Japanese version is here.

Prerequisites

1. Compiler Setup

   The egcs RPMs include those for C, C++, Objective C, and FORTRAN. The C and FORTRAN support is installed in the DR3 installation if "C Development" is selected, while th optional C++ and Objective C support is installed when you add "C++ Development" to your selection.

   If you haven't installed the "C Development" packages, you need to install them by hand. Get the following RPMs to <somewhere> on your local disk:

   $ cd <somewhere>

   $ ls

   egcs-1.0-2e.ppc.rpm

   egcs-as-gcc-1.0-2e.ppc.rpm

   egcs-c++-1.0-2e.ppc.rpm

   egcs-g77-1.0-2e.ppc.rpm

   egcs-objc-1.0-2e.ppc.rpm

   and then install them as:

   $ su

   # rpm -Uvh <somewhre>/egcs*-1.0-2e.ppc.rpm

Getting Started with G77

1. Simple Test

   Congratulation! Now you are ready to try "g77" to compile your fortran programs. You had better start with something rather simple to test if "g77" works at all.

   $ cat simple.f

   	  real*4  a, b, c
   	  a = 1.
   	  b = 2.
   	  c = a + b
   	  print *, ' a, b, c = ', a, b, c
   	  end
   	

   $ g77 simple.f -o simpletest

   $ simpletest

   Passing this simple test, you can now proceed to more complicated programs (You should if your system is DR3). Then you may encounter various problems like I did.

Experience with G77 on MkLinux

1. If Linux Source Is Available

   If somebody already ported your favorite fortran program to a Linux box, your are lucky, since the source code is very likely to be g77-compilable. If you have to deal with bits, bytes, or integer*2s embedded in an I*4, however, you need to be careful. Intel chips and PPC chips have different byte orders. The software package I mentioned above (CERNLIB) falls into this category. Although the source codes are g77-compilable except for some trivial problems inherent in porting any package to a MkLinux box, the porting was a pains-taking process, because of the byte order difference. This only requires patience and carefulness not to miss any place of swapping bytes or equivalencing I*4 with I*2s.

2. Otherwise

   You are on your own. Porting issues then include

   Appropriate Choice of FFLAGS

   If compilation does not work or the created binary does not produce correct results, the first thing you want to try is to fiddle with FFLAGS:
   • -fno-automatic: allocates variable statically, being equivalent to putting SAVE to any subroutine or function. It doesn't by default.
   • -fdollar-ok: allows $ to be used as a valid character in a symbol name. It's not by default.
   • -fno-backslash: does not interpret '\' as an escape sequence. For instance, without "-fno-backslash" 'A\nB' otherwise means three characters, with the second one being newline.
   • -fno-underscoring: prevents g77 from putting underscores to any subroutine or function names. The default behavior without "-fno-underscoring", is to append two underscores to names with underscores and one underscore to external names with no underscores. This is a useful flag to interface a C function to a Fortran function: You want to define fortran's foo_(bar) in terms of C's foo(bar), sometimes.
     When your subroutine name is foo_bar, what you actually get is foo_bar__ instead of foo_bar_. It's in accord with the above specification, but caused me some trouble as you can easily expect.
   • -fno-globals -Wno-globals: to avoid comlaints such as

     Global name NAME defined at ... already defined...

     Global name NAME at ... has different type...

     Too many arguments passed to NAME at ...

     Too few arguments passed to NAME at ...

     Argument #N of NAME is ...

     Try the following for more information:

     $ info -f g77 M GLOBALS

   • -fno-f90 -fugly-complex: to avoid complaints such as

     Ambiguous use of intrinsic INTRINSIC ...

     Try the following for more information:

     $ info -f g77 M CMPAMBIG

   G77's Insufficient Implementation of Fortran77

   • No concatenation allowed for a char from a dummy argument and a local char variable.
     ---> had to copy the dummy character argument to a local character and then concatenate them.
   • "Char(39)", etc. are not allowed.
     I had to switch off -fno-backslash flag and replace char(39) by '\'', char(34) by '\"', char(92) by '\\', etc. There might be more appropriate ways to do this.
     ---> have to consult info pages.
   • "Implicit None" is incompatible with a Entry statement.
     ---> had to delete "Implicit None".
   • If ( Integer ) is not allowed.
     ---> If ( Integer .ne. 0 )
   • Integer = Logical or vice versa is not allowed.
     ---> had to use Byte instead of Logical.
   • Type declaration necessary for external functions.

   Optimization Errors

   With the optimization option like "-O", G77 sometimes produces erroneous codes for some programs having deeply nested ifs or loops. Check the results with and without "-O" before you run a long time job.

   To be Filled When I Find More

G77 Performance

1. Description of Sample Programs

   tt_gen: e+ e- ---> t tbar

   TT_GEN is a program to calculate the production cross section for the top-antitop pair production process via electron-positron annihilation:
   e+ e- ---> t tbar

   followed by subsequent decays of the top and antitop into a bottom quark and two fermions.

   This is a 21-dimensional integration, including integration variables for spin, final-state selection, initial-state radiation, and beamstrahlung. The scattering amplitude is calculated by using HELAS (Helicity Amplitude Subroutines) and the integration by the BASES/SPRING Monte Carlo integration package.

   The BASES part calculates the cross section based on the weighted sampling method, while the SPRING part generates weight-one events, using the integration results from the BASES part. The Monte Carlo integration consists of two steps: grid optimization step and accumulation step. In the grid optimization step, the integration is carried out in hyper-cubes in the integration space, with the size of the hyper-cubes and that of the sub-mesh (grid size) being adjusted in each iteration. In the accumulation step, the hyper-cubes and the grids are fixed, and just accumulates statistics to improve numerical accuracy.

   In this example, each iteration consists of 20000 sample points in the integration space. The optimization step is made of 5 iterations and the accumulation step of 50 iterations.

   The SPRING step includes the JLC detector simulator for particle tracking and calorimeter response.

   tth_gen: e+ e- ---> t tbar h

   TTH_GEN is similar to TT_GEN but with an additional Higgs boson in the final state. The integration of this process is of 28 dimensions, including integration variables for spin, final-state selection, initial-state radiation, and beamstrahlung.

   Each iteration consists of 20000 sample points in the integration space. The optimization step is made of 5 iterations and the accumulation step of 10 iterations (I didn't need much accuracy here).

   tth_anl: e+ e- ---> t tbar h

   An analysis program to select this process, clustering final state jets, finding energetic leptons, testing kinematical configurations, etc.

   The program consists of two separate parts: one for 8-jet final states (8J) and the other for 1 letpon plus 6-jet final states (L+6J).

2. Results

   Maybe you are just interested in this table:
   

   	C100 (HP-UX)	8115/100 (MkLinux)
   TTH_GEN:BASES	140.73 sec (2.94834 +/- 0.00927 fb)	850.05 sec (2.94811 +/- 0.00927 fb)
   TTH_GEN:SPRING	402.19 sec (output data: 35MB)	813.35 sec (output data: 35MB)
   TTH_ANL: 8J	218.53 sec	435.08 sec
   TTH_ANL: L+6J	166.2 sec	306.2 sec
   TT_GEN:BASES	410.27 sec (0.40153 +/- 0.00061 fb)	2485.85 sec (0.40153 +/- 0.00061 fb)
   TT_GEN:SPRING	103.62 sec (output data: 5.6MB)	244.45 sec (output data: 5.6MB)

   where the center of mass energy has been set at 700(340) GeV for TTH (TT) and the top mass is chosen to be 170 GeV. In the SPRING stage, 1000(200) events were generated for TTH (TT). Notice that TT_GEN takes into account the threshold enhancement thus has a finite cross section even at the production threshold.

   Comments

   Except for the BASES step, the difference is about a factor of two, which is probably consistent with the CPU speed difference (I'm not sure though). In the BASES step, the factor becomes about six instead. The performance of the MkLinux box is significantly worse than the other cases. This is probably due to the BASES's randomly accessing a huge array that exceeds a tiny cache. I am going to test this, if time allows.

Back to Keisuke Fujii's MkLinux Page