Hi Dave,
Yes, this is purely compiler; the code is basically pretty old and
unmodified, and has worked fine with a dozen different versions of ifort and
every other compiler. On the common blocks - I use them reluctantly, but it
is a "standard" method to make sure that things get handled correctly in mpi
transfers of run control variables and parameters. We could use sequenced
records presumably with a bit of jerking around, but you are really then
just introducing added complexity in the name of programming purity, an
oft-practiced but nonetheless generally bad thing. By the way, same story
here as with all Lachele's grief with bugfix 126 - sometimes you just have
to use a version of the compiler that works. I notice that Ross just posted
instructions for getting a working intel compiler; I would recommend that we
warn our users about problems with intel compilers, post a list of
known-good (per Scott or whoever), and post Ross' instructions on the
website. Otherwise we will be driven craz(ier). On only: - yes, very good.
Tom Darden started doing this a lot in code he was giving me; I have a bad
history of modifying things so frequently that I have historically not used
this much, but am leaning more and more in this direction. We might be more
vocal about the compilers that work and the relative performance metrics; I
found that pgi responded very positively in the past to complaints I made on
the list about their stuff not working; intel of course is probably another
story... I unfortunately don't have access to all the compilers or more
modern machines at the moment, so can't do the comparison myself.
Best regards - Bob
----- Original Message -----
From: "case" <case.biomaps.rutgers.edu>
To: <amber-developers.ambermd.org>
Sent: Wednesday, March 10, 2010 11:12 AM
Subject: [AMBER-Developers] more on pme_setup problem
>I am ordinarily reluctant to assign problems as "compiler errors" since it
> is not uncommon for there to be subtle errors in our code that are only
> exposed with certain compilers or options.
>
> In this case, however, I am somewhat more willing to blame Intel. Here
> are a few additional points of information:
>
> 1. It doesn't seem to be related to any recent code change: ifort 11.1
> (069)
> gives the same failure for amber10 as for the amber11 in CVS.
>
> 2. In addition to working for various flavors of ifort 10, the current CVS
> code also works for ifort 11.0 (081) and ifort 11.1 (046). I am working
> to
> narrow down further when the problem appears [known to fail for ifort 11.1
> (069), but I've not tested intermediate versions.]
>
> This kind of explains why all this has only come up recently: it is only
> quite recent versions of ifort that exhibit this behavior. It seems to be
> related to the fact that pmemd is using a common block to pack module
> variables in a certain storage order. [I'm not saying the code is wrong,
> just
> that this somehow seems to a part of the symptom.]
>
> If someone wants to look at this, here's a good question to start with:
> why does the use of "natom" in the check_neutral() subroutine in
> pme_setup.fpp
> not trigger a problem, whereas the very similar use in vdw_correct_setup()
> does trigger the error? [Note: I've played with removing compiler
> optimzations, with no success.]
>
> However, it is not really a "solution" (to use Dan's phrase) to just tell
> people to go get an older compiler from intel, since (as far as I can see
> from
> Intel's web site) that is not such an easy thing to do. If someone knows
> how
> this can be done, please post, and we'll get it on the wiki or the web
> site.
>
> ....more later....dac
>
>
> _______________________________________________
> 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 Wed Mar 10 2010 - 10:00:05 PST
