Hi Jason,
On 22/01/2014, at 4:56 pm, Jason Swails <jason.swails.gmail.com> wrote:
> Hey Ben! I hope all is going well
Yep, things are going pretty well. I won’, however, say too much on a public mailing list :-)
> 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.
I found out that FREEFORMAT_FLAG was set from $freeformat_flag in configure2, and that was being (incorrectly) set to -k. I hadn’t, in my sweep through the configure script, fixed everything. Changing -k to -qfree=f90 seems to have helped a good deal. I and a colleague are trying to figure out some other compiler quirks now, that don’t seem directly related.
>>
>> 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 :).
If I do ever get that patch, I’ll submit it to you guys. I think I still have a working git checkout, in case I should ever be able to tackle such things as fixing the XMIN minimiser (Kennie suggested it might make a good default) and working with Lachele and company on their GUI if that’s still under development.
Thanks for your help!
Ben
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Mon Jan 27 2014 - 20:00:02 PST
