Branch intel has been updated.
Use of floating points as array index is removed. Also, relevant comments
have been added.
Thanks,
Nitin Rai
From: Ross Walker <rosscwalker.gmail.com>
To: AMBER Developers Mailing List <amber-developers.ambermd.org>
Date: 05-03-2016 23:52
Subject: Re: [AMBER-Developers] weirdness in gb_ene_hybrid.F90
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
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Tue Mar 08 2016 - 06:00:05 PST
