[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ccp4bb]: Portland Group Fortran compilers - the 99% solution

***  For details on how to be removed from this list visit the  ***
***    CCP4 home page http://www.dl.ac.uk/CCP/CCP4/main.html    ***


here are my experiences with the Portland Group Compiler:

> .../configure
> -----------
> 	I added a configuration option for linux_pgf77.

I usually set various environmental variables that will then be used
by the configure script instead of the default ones. Here is what I
use for the pgf77 compiler:

    % FC="/usr/pgi/linux86/bin/pgf77"
    % CC="/public/sw/linux/bin/gcc"
    % XFFLAGS="-Mnosecond_underscore -Wl,-rpath,$CLIB"
    % XCFLAGS="-DPROTOTYPE -Wl,-rpath,$CLIB"
    % COPTIM="-O"
    % FOPTIM="-O2 -Munroll -tp px -Kieee -Minform,inform"
    % SHARE_LIB="ld -shared -soname libccp4.so --whole-archive -o \
      libccp4.so libccp4.a"
    % M4="m4 -D_pgf77=1"
    % F77=$FC


    % ./configure --with-x --with-shared-lib linux

Note: you have to change the configure script to fix problems with
picking up the M4 variable: e.g. change 

  M4="m4 -D_g77=1"


  M4=${M4-"m4 -D_g77=1"}

(and similar in several other places). This will make the script pick
up M4 from the environment - if set there (see comment near top of

> lib/src/unix.m4:
> 	_pgf77,1,
> 	  [define(_readonly,[READONLY,])],

Yes, I did the same. As far as I can tell nothing else is required

> 	Once the shared libraries are installed in $CCP4/lib, we need to 
> 	add them to the system ld.so database.  I had already added the
> 	directory to /etc/ld.so.conf, but the database cannot be updated
> 	until the libraries are actually there.  So now run
> 	/sbin/ldconfig

Adding the '-Wl,-rpath,$CLIB' flag to the compiler flags makes
binaries search $CLIB for shared libraries by default. This avoids
setting LD_LIBRARY_PATH or messing around with the system
configuration - which you might not be allowed to do.

> Residual problems
> -----------------
> 	1) The lsqkab_exam failure is due to the program attempting to 
> 	open the same file twice:  HKLIN1 rnase.pdb HKLIN2 rnase.pdb
> 	I can understand why this would be illegal without the READONLY
> 	flag, but I _thought_ that I had correctly added READONLY support.
> 	So I don't understand why it's still failing.  Just as a side note,
> 	I don't understand how this example ever works on a system that 
> 	doesn't support READONLY.

As far as I can tell it has nothing to do with READONLY: the Fortran77
standard states that only 'one unit at a time can be connected to a
file'. The lsqkab example tries to open the same file on two different
units (XYZIN1 and XYZIN2). It's possible, that most other compilers
are a bit more clever and can handle this - but it's clearly a
non-standard assumption. BTW: the Lahey compiler chokes on that too ...

> 	2) The problem with accumulation of scratch files is because
> 	the DISPOSE=DELETE file handling option is not configured for
> 	pgf77 in unix.m4.

Hmmm ... I haven't noticed this on our machine (RedHat 7.0). But I'll
take a closer look again ...

> 	3) The refmac_tls_exam error is another file open failure.

Have you put in the latest patches from the CCP4 problems page?

*** 3644,3649 ****
--- 3644,3651 ----
        GOTO 10
   999  CONTINUE
+       CLOSE(ISCRB)
+       ISCRB = 0

> 	4) Not so much a problem, just a comment.  For some reason code
> 	in the xdl_view directory gets built using the g77 compiler even 
> 	though ./configure should no longer mention g77 at all when 
> 	constructing Makefiles.  I don't think this hurts anything on my 
> 	system, but if you didn't have a working g77 compiler....

If you use the method of setting environmental variables and make sure
that F77 and FC are identical it will work. The reason is, that the
xdl_view/src/configure uses the F77 variable, not FC as in other

BTW: here are some timings running all scripts in

1. Athlon 1.1GHz, RedHat 7.0:
  1.1. default g77/gcc (gcc 2.95.3) linux compilation:

     real time =    886.0
     user time =    781.3
      sys time =     31.4
  1.2. Portland Group Compiler (see flags above):
     real time =    851.8
     user time =    780.1
      sys time =     25.7

2. Pentium III (866 MHz), SuSE 7.1:

  2.1. default g77/gcc (gcc 2.95.3) linux compilation:

     real time =   1216.7
     user time =   1151.4
      sys time =     24.7
  2.2. Portland Group Compiler (see flags above):
     real time =   1245.0
     user time =   1157.7
      sys time =     25.0

Note: I'm sure there is still some room for speeding things up - the
compiler flags for both g77 and pgf77 are fairly conservative. But
there are also a bit too many warning messages coming up in several
places that make me hesitating to go for speed and maybe neglecting
accuracy of results ...




* Clemens Vonrhein, Ph.D.          vonrhein@GlobalPhasing.com
*  Global Phasing Ltd.
*  Sheraton House, Castle Park     Tel: +44-(0)1223-353033
*  Cambridge CB3 0AX, UK           Fax: +44-(0)1223-366889
* BUSTER Development Group (http://babinet.globalphasing.com)