Should I be expecting to get zero errors?
I basically got the same results with and without -macAccelerate
Finished serial test suite for Amber 12 at Fri Jun 8 15:04:19 EDT 2012.
265 file comparisons passed
217 file comparisons failed
0 tests experienced errors
Test log file saved as
/Users/jonathangough/amber12/logs/test_amber_serial/2012-06-08_14-26-56.log
Test diffs file saved as
/Users/jonathangough/amber12/logs/test_amber_serial/2012-06-08_14-26-56.diff
Summary of AmberTools serial tests:
566 file comparisons passed
36 file comparisons failed
3 tests experienced errors
Test log file saved as
/Users/jonathangough/amber12/logs/test_at_serial/2012-06-08_13-58-00.log
Test diffs file saved as
/Users/jonathangough/amber12/logs/test_at_serial/2012-06-08_13-58-00.diff
I tried the following:
>
> ./configure -macAccelerate gnu
> make install
> make test
>
> and got:
> Finished serial test suite for Amber 12 at Fri Jun 8 12:59:26 EDT 2012.
>
> 265 file comparisons passed
> 217 file comparisons failed
> 0 tests experienced errors
> Test log file saved as
> /Users/jonathangough/amber12/logs/test_amber_serial/2012-06-08_12-19-28.log
> Test diffs file saved as
> /Users/jonathangough/amber12/logs/test_amber_serial/2012-06-08_12-19-28.diff
>
> Summary of AmberTools serial tests:
>
> 566 file comparisons passed
> 36 file comparisons failed
> 3 tests experienced errors
>
>
> On Fri, Jun 8, 2012 at 11:04 AM, Jason Swails <jason.swails.gmail.com>wrote:
>
>> 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
>>
>
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Jun 08 2012 - 12:30:04 PDT
