Hey Ben! I hope all is going well
On Tue, Jan 21, 2014 at 8:49 PM, Ben Roberts <ben.roberts.geek.nz> wrote:
> Hi all,
>
> I’m trying to compile Amber on a BlueGene using the IBM XL compilers. I
> get errors such as this one:
>
> xlf -WF,-DBINTRAJ -c -k -O0 -qfixed -qextname
> -I/hpc/home/bpr22/amber12/include
> -I/bgp/local/pkg/netcdf/4.1.3parallel/include -o ambpdb.o ambpdb.F90
> COMMAND LINE 1520-022 (W) The FREE option has been replaced by the option
> FREE(F90).
> "ambpdb.F90", line 4.0: 1515-005 (S) Continuation line is not permitted at
> beginning of program or after INCLUDE, EJECT, .PROCESS statements or
> comment directive. Line is ignored.
> "ambpdb.F90", line 8.0: 1515-005 (S) Continuation line is not permitted at
> beginning of program or after INCLUDE, EJECT, .PROCESS statements or
> comment directive. Line is ignored.
> "ambpdb.F90", line 9.0: 1515-005 (S) Continuation line is not permitted at
> beginning of program or after INCLUDE, EJECT, .PROCESS statements or
> comment directive. Line is ignored.
>
This is strange. I don't know the xlf compiler flags, but -qfixed seems to
suggest that xlf is trying to build this F90 file with fixed format (but
-WF means it's assuming free-format?) In any case, ambpdb.F90 is a
Fortran-90 file, obviously, and needs to be compiled as a free-format
Fortran-90 file. The line it is choking on is "program", likely because it
is not indented 6 spaces. There is a variable inside the config.h --
FREEFORMAT_FLAG -- that defines the flag necessary to tell the compiler to
compile as free-format F90. That should be set for .F90 files and not set
for .F/.f files already in the Makefiles. Try fiddling with this some (and
consulting the xlf manual and/or google) and see if you can get it to work.
>
> and so on and so forth, including syntax errors.
>
>
> This seems to be related to the XL compilers’ way of handling different
> versions of Fortran. If the source were all fixed-format F77 style, it
> would be easy, and conversely if all free-format F90. It might even be
> handleable if there were different extensions on the files, so that
> programmatically we could distinguish one from the other.
>
This should already be the case (see below).
>
> As far as I can tell, though, there’s no way in the Amber 12 / AmberTools
> 13 configure script to say the following:
>
> “If the file is F77 format (or is called <name>.[Ff]77), use this compiler
> with these flags. If F90, use that compiler with those flags.”
>
Correct. This is currently impossible. None of the compiler suites we
regularly test fail to build F77 files with the F90 compiler (e.g.,
gfortran, ifort, pgf90). I don't know of any other developer that
currently has access to the IBM compilers to get it working, either...
However, the FREEFORMAT_FLAG variable in config.h is used for F90 files
and not for F77 files, I believe.
>
>
>
> Is there such an option, that I’ve just overlooked? Or an alternative
> solution, besides, “Don’t use the XL
>
> compiler suite”?
>
>
This may require some Makefile hacking. An alternative of course is to
build _only_ pmemd with xlf and use another compiler suite for the rest
(you will need to link to an external NetCDF library built with the XL
compilers for pmemd using the --with-netcdf /path/to/netcdf flag to
configure). pmemd is likely the only program to significantly benefit from
using the IBM compilers, anyway, but simultaneously supporting pmemd.MPI
with xlf/MPI and sander.MPI with gnu/MPI will be a challenge.
>
> I know that about three years ago the idea to rename the source files with
> standardised extensions was brought up (back when I was an active
> developer), but came to a standstill after discussion (see
> http://dev-archive.ambermd.org/201110/0007.html and linked pages).
Actually this was done. All Fortran 90 source code files end in .F90 and
all Fortran 77 code (that we develop) has a .F suffix. (3rd party source
code, like BLAS, LAPACK, and ARPACK are still .f). Furthermore, there are
only few .F files remaining, and they are fairly localized so it may be
straightforward to modify the relevant Makefiles to use a specific F77
compiler.
> Right now, although I could perhaps with a degree of pain go through the
> source files and Makefiles and rename them in my local copy, then provide
> Configure-script logic to deal with the situation, that sounds like a lot
> of work, and before I embark on it I’d like to know whether anyone else has
> had better luck with alternative approaches.
>
Assuming no suggestions I made above work, my next approach would be the
one you describe here. If you initialize the directory as a git
repository, it'll let you experiment a bit and discard unsuccessful
attempts. More importantly, it'll let you easily create a patch that we
can use to support XLF if you ever get this up and working :).
Best of luck!
Jason
--
Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Jan 21 2014 - 20:00:03 PST
