Hello,
I can reproduce this error, and I know what's happening. Reproducing this
error requires Xcode 4.3, and all ports must be built with this version of
Xcode. Once that is done, however, this error should occur with any
version of GCC that you build with MacPorts (I have verified with both GCC
4.7 and GCC 4.4).
The following command will fix this bug:
sed -i -e "s.real(real8).real(kind=8).g"
$AMBERHOME/AmberTools/src/chamber/psfprm.F90
Then try recompiling. The problem arises due to the assumption (that has
been correct for all systems we tested until today) that real8 is always 8.
The detailed explanation is included as a postscript for interested
parties.
Note, for anyone that implements this fix before waiting for an official
bugfix, when the bugfix for this is released, you will need to apply it
using:
./patch_amber.py --update --ignore-fails
since it will try and apply a patch that was already applied (via the sed
command above).
HTH,
Jason
P.S. The explanation of the bug:
Chamber makes widespread use of "kind" in order to specify the precision of
floating point numbers. From what google tells me, kind is not strictly
defined in the Fortran standard, which can lead to compiler- and
system-dependent definitions. For instance, depending on your system,
real(kind=1) can mean a 4-byte real, while in other cases you need
real(kind=4) to get a 4-byte real. To address this, Fortran has the
"selected_real_kind" intrinsic function to return the value that "kind"
must take to reach a given level of precision.
In psfprm.F90, the "real8" parameter is defined as
"selected_real_kind(15,307)", (meaning the real must be able to support up
to 15 decimal places and an exponent range of 307). What I don't
understand is why real8 was declared (and used to define some variable
types, such as cg, amass, pk, pn, etc.), yet real(kind=8) was used to
define everything else. What's actually causing these errors is that all
deallocates are done by calling a wrapper (deallocate_real for floats). In
subroutine deallocate_real(), all arguments are assigned the type
"real(kind=8)", which will fail any type checking if real8 != 8. For
Richard's system, selected_real_kind(15,307) returns 10 (not 8, like it has
for every other system we've tested so far), which is probably a result of
his version of Xcode.
The moral of this story is that chamber needs to be made self-consistent.
The sed command I suggested changes all uses of "real8" to "kind=8" so
that everything is consistent. My personal feeling is that we should
actually use the real8 constant everywhere, since selected_real_kind() is
more portable than assuming real(kind=8) is an 8-bit real. However, that's
a much more invasive change, so the AmberTools 12 bugfix should probably
just be real8->kind=8
On Sun, Apr 22, 2012 at 3:26 AM, Richard Lonsdale <
richard.lonsdale.gmail.com> wrote:
> Hi all,
>
> I've been experiencing problems installing Ambertools 12 on my Mac. I have
> OS X 10.7.3, Xcode 4.3.2, Macports 2.0.4 and am using gcc47 (as per
> instructions on http://jswails.wikidot.com/mac-os-x#toc2).
>
> The installation runs fine until the chamber stage, where I get the
> following error:
>
> make chamber
> gfortran -DBINTRAJ -c -O3 -mtune=native -ffree-form
> -I/Users/richlonsdale/programs/amber12/include
> -I/Users/richlonsdale/programs/amber12/include -o psfprm.o psfprm.F90
> psfprm.F90:3208.24:
>
> call deallocate_real(cg,amass)
> 1
> Error: Type mismatch in argument 'a0' at (1); passed REAL(10) to REAL(8)
> psfprm.F90:3231.24:
>
> call deallocate_real(pk,pn,phase)
> 1
> Error: Type mismatch in argument 'a0' at (1); passed REAL(10) to REAL(8)
> psfprm.F90:3249.24:
>
> call deallocate_real(cn1,cn2,rk,req)
> 1
> Error: Type mismatch in argument 'a0' at (1); passed REAL(10) to REAL(8)
> psfprm.F90:3250.24:
>
> call deallocate_real(cn114,cn214)
> 1
> Error: Type mismatch in argument 'a0' at (1); passed REAL(10) to REAL(8)
> psfprm.F90:3251.24:
>
> call deallocate_real(radii,screen)
> 1
> Error: Type mismatch in argument 'a0' at (1); passed REAL(10) to REAL(8)
> psfprm.F90:3252.24:
>
> call deallocate_real(scnb_scale_factor,scee_scale_factor)
> 1
> Error: Type mismatch in argument 'a0' at (1); passed REAL(10) to REAL(8)
> psfprm.F90:2754.21:
>
> call allreal(natom,radii,screen)
> 1
> Error: Type mismatch in argument 'a0' at (1); passed REAL(10) to REAL(8)
> psfprm.F90:1084.25:
>
> call allreal(nfound,pk,pn,phase)
> 1
> Error: Type mismatch in argument 'a0' at (1); passed REAL(10) to REAL(8)
> psfprm.F90:1085.25:
>
> call allreal(nfound,scnb_scale_factor,scee_scale_factor)
> 1
> Error: Type mismatch in argument 'a0' at (1); passed REAL(10) to REAL(8)
> psfprm.F90:273.38:
>
> call allreal(ntypes*(ntypes+1)/2,cn1,cn2,cn114,cn214)
> 1
> Error: Type mismatch in argument 'a0' at (1); passed REAL(10) to REAL(8)
> make[3]: *** [psfprm.o] Error 1
> make[2]: *** [install] Error 2
> make[1]: *** [serial] Error 2
> make: *** [install] Error 2
>
>
> Thanks in advance,
>
> Richard
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
352-392-4032
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Sun Apr 22 2012 - 16:30:03 PDT
