On Fri, Jun 8, 2012 at 10:11 AM, David A Case <case.biomaps.rutgers.edu>wrote:
> On Fri, Jun 08, 2012, Jason Swails wrote:
> >
> > Many people have reported errors like the following when trying to build
> > with the latest version of Xcode (4.3.2) and Mac OS X Lion:
> >
> > bintraj.F90:555.18:
> >
> > call checkerror(nf90_put_var(ncid, var_id, buf(:,:), &
> > 1
> > Error: Generic function 'nf90_put_var' at (1) is not consistent with a
> > specific intrinsic interface
>
> Neat. I understand putting quotes around "20.455", but do you understand
> what is going on with the "buf" changes?
>
> ...just curious....dac
>
Maybe, but this is mostly speculation until I have a chance to test my
hypothesis (although I think it's likely since it explains every issue
we've seen with this OS/Compiler combo). NetCDF overloads its function
calls in its Fortran API by using interfaces, and in doing so can provide a
separate function to handle each variable type. The variable types they
use are defined using "selected_int_kind" and "selected_real_kind" to
define a four byte real, an 8 byte real, a 1 byte int, etc.
Therefore, this bug ultimately reduces to the issue we saw in chamber where
selected_real_kind started returning 10 where it had always returned 8 in
the past. I think the FourByteReal they stored via selected_real_kind(P =
6, R = 37) is not returning 4 like it should (although the 8-byte real is
behaving just fine). This is also why the 20.455 was bombing out -- it was
being passed in as an implicit real*4, but since NetCDF used FourByteReal,
it was type-mismatching, just like the coordinate/velocity issue (and like
the chamber issue).
There was actually a report on the MacPorts mailing list where someone was
seeing the same behavior (so it's not just Amber that's suffering here),
and someone more knowledgeable than me had this to say (correcting me in
the process :)):
http://www.mail-archive.com/macports-users.lists.macosforge.org/msg28114.html
That's the best explanation I have...
All the best,
Jason
P.S. I'm thinking that putting quotes around the 20.455 isn't the best way
to go -- I think this will make ptraj choke when it tries to use it as a
double in reporting real time series rather than frame number. Another
workaround would be to pass it in as an explicit double using
dble(20.455). The time conversion constant really should NOT be a string,
it should be a float of some sort. It doesn't make sense to break the
NetCDF format, even if it's just a little, to patch up a platform bent on
introducing bugs into its compiler suite. Thoughts?
--
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 Fri Jun 08 2012 - 08:30:02 PDT
