Fortran Program Porting Issues

Japanese version is here.

Prerequisites

Shared Library Setup

I have built a set of RPM packages (gcc Suite for C, C++, Objective C, and FORTRAN), which require the shared library support provided by DR2.1update4(+shared library support). You have to thus set up shared library environment before you can go further.
You can find here how I installed the DR2.1update4+shared library support.

Compiler Setup

Once the DR2.1update4+shared library support is installed, the rest is easy. Get the following RPMs to <somewhere> on your local disk:
$ cd <somewhere>
$ ls
gcc-2.7.2.fu.1-1C.ppc.rpm
gcc-c++-2.7.2.fu.1-1C.ppc.rpm
gcc-g77-2.7.2.fu.1-1C.ppc.rpm
gcc-objc-2.7.2.fu.1-1C.ppc.rpm

If you are interested in how I built the RPMs, take a look at this.

To install them do the following:

$ su
# rpm -i --force <somewhre>/gcc*-2.7.2.fu.1-1C.ppc.rpm

Caution: This overwrites your existing gcc triplet (C, C++, and Objective C) and might destroy your compiling environment. As always install them at your own risk. You had better read this before installation.

Getting Started with G77

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

In Case of Trouble

If it doesn't, you are in trouble. If what you got is something like:

simpletest: error in loading shared libraries
libf2c.so: cannot open shared object file: No such file or directory

It should be relatively easy to fix as follows.
First check if you have /etc/ld.so.conf. If you do, you will get:

$ cat /etc/ld.so.conf
/lib
/usr/lib
/usr/X11/lib
/usr/local/lib

I suspect you don't. You have to create one for example by

$ su
# cat > /etc/ld.so.conf
/lib
/usr/lib
/usr/X11/lib
/usr/local/lib
/usr/lib/gcc-lib/powerpc-unknown-linux/2.7.2.1-ppclinux
^D

where "^D" is CTRL+d. Once you have created /etc/ld.so.conf, you should be able to register your libf2c.so to /etc/ld.so.cache.

# /sbin/ldconfig -v
......
libf2c.so => libf2c.so
......

I should have included in the RPM package a symbolic link to /usr/lib/libf2c.so (I supposed I did, but didn't as pointed out by Matsumura at Osaka University), so that libf2c.so would have been automatically registered in the rpm installation. I'm sorry for inconvenience. I promise the next version will include this symboic link. Meanwhile you have to do the above and try simpletest again (97/12/07: 2.7.2.fu.1-1C now includes the symbolic link and you do not have to do the above, I hope).

If it failed again or if what you got was something different, you are in a real trouble.
I'm sorry but in this case you have to restore your old "gcc" triplet (gcc-2.7.2.1-2J.ppc.rpm, gcc-c++-2.7.2.1-2J.ppc.rpm, gcc-objc-2.7.2.1-2J.ppc.rpm) from the RPMS/ppc directory of DR2.1update4. Then you may want to try compiling "g77" from its SRPM.

$ su
# rpm --rebuild gcc-2.7.2.fu.1-1C.src.rpm

I hope you don't have to do this.

Passing this simple test, you can now proceed to more complicated programs. Then you may encounter various problems like I did.

Experience with G77 on MkLinux

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.

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.

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.

Missing Unix-Intrinsic Functions (U77)

As of July 30, you don't probably have to worry about this, since now the new libf2c installed above includes the free libU77 by Dave Love <d.love@dl.ac.uk> from ftp//ftp.dl.ac.uk/pub/fx/libu77/, which is very hard to connect. In Japan, it's thus easier to get one from a mirror site: ftp://ftp.u-aizu.ac.jp/pub/lang/fortran/libU77/. This valuable information has been provided by Hiroshi Futami in (mklinux-jp 4802). You may want to take a look at this README file that came with the libU77 source code.

This was, however, after I did most of the porting: I have fixed up those missing intrinsic functions such as date_, time_, ..etc. Some examples are here.

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.

Another Optimization Errors (97/10/15)

I found another optimization problem with g77-0.5.19, which always happens with "-O1" or higher. The problem lies in the optimization of any routine containing complex statement functions and can be reproduced by the following simple example:

complex x, y, a, b, add

add(a,b) = a + b

x = (1.,0.)

y = (0.,1.)

print *, 'x = ', x

print *, 'y = ', y

print *, 'add(x,y) = ', add(x,y)

print *, 'x + y = ', x + y

end

"add(x,y)" and "x + y" give the same answer with "-O0" but the formar yields an erroneous result with, for example, "-O1". There is no problem with the same kind of code handling single or double precision real numbers.

You should avoid the use of complex statement functions. Otherwise, you should compile those routines that use complex statement functions with "-O0".

This problem has been fixed in g77-0.5.21 or later. It's fixed in egcs-1.0 coming with DR3 in particular.

To be Filled When I Find More

G77 Performance

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).

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