Re: [AMBER-Developers] weirdness in gb_ene_hybrid.F90

From: Ross Walker <rosscwalker.gmail.com>
Date: Sat, 05 Mar 2016 10:22:21 -0800

Adding to this a list of "work items" to be addressed  (posted to the list here) would be helpful.
ThanksRoss-------- Original message --------From: Ross Walker <rosscwalker.gmail.com> Date: 03/05/2016 10:20 (GMT-08:00) To: AMBER Developers Mailing List <amber-developers.ambermd.org> Subject: Re: [AMBER-Developers] weirdness in gb_ene_hybrid.F90
I added the Intel India team to the Dev list here so they should see these messages and are tasked with addressing this. Likely on Monday. I'd like to give it a week here to see if this can all be properly whipped into shape and if not we can roll back to the previous code.-------- Original message --------From: Jason Swails <jason.swails.gmail.com> Date: 03/05/2016 09:42 (GMT-08:00) To: AMBER Developers Mailing List <amber-developers.ambermd.org> Subject: Re: [AMBER-Developers] weirdness in gb_ene_hybrid.F90
On Sat, Mar 5, 2016 at 8:56 AM, David A Case <david.case.rutgers.edu> wrote:

> The distribute_atoms() routine in gb_ene_hybrid.F90 (in pmemd) looks
> very odd:
>
> At line 933:
>
>    real            :: a,b, c  ! Quadratic constants
>    real            :: d, root
>
> Why are these real (vs. double precision), but OK, maybe that's required
> somehow (a comment would be good here).
>
> At line 987:
>
>       do b=1,numtasks
>
> Oooh...why are we using a floating point number as an loop index?????
>
> At line 994:
>
> time_per_atm(b) = (radii_time(b)+diag_time(b))/DBLE(radii_num_atoms(b))
> ​
>


> This seems even more dangerous: a float as an array index.
>

​Agreed -- this is dangerous.  The GNU compiler (and probably the Intel
compiler probably, too) complains heavily about this behavior.  It also
complains heavily about poorly-formatted preprocessor comments.  You can
see the output from the compiler here:
https://gist.github.com/swails/2ae4f257ec455ac7dd81

​Compiler warnings are often helpful to finding issues (*particularly* with
clang and LLVM, which have very good compile-time and run-time analysis),
and letting warnings flood the output like this limits the utility of such
checks.  Given that pmemd recently compiled with relatively minimal
warnings, it would be good to get back to that state.

All the best,
Jason
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sat Mar 05 2016 - 10:30:05 PST
Custom Search