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
Received on Wed Mar 10 2010 - 08:30:04 PST
