Okay, be careful about dinking with nfft[123] vs nfftdim[123]. I have no
idea whether this ips code is correct, but this nfft vs. nfftdim stuff has
caused confusion before in the recip space code (notably, the guys doing the
pmemd gpu port made some assumptions and renamed some stuff and majorly
broke some code). I have not refreshed my memory by looking at code, but I
vaguely remember that these two sets of variables exist due to use of half
complex fft's in reciprocal space calcs, and you basically have to be able
to treat different fft-related data structures as if they are dimensioned
differently (I am sure that is as clear as mud - bottom line - don't dink
with these variables unless you know what you are doing, and as far as I
know, Mike Crowley, Tom Darden and I are the only folks who have done a lot
with this stuff - though looks like ips folks waded into it a bit too...).
Regards - Bob
----- Original Message -----
From: "Mark Williamson" <mjw.sdsc.edu>
To: "AMBER Developers Mailing List" <amber-developers.ambermd.org>
Sent: Tuesday, February 02, 2010 4:18 PM
Subject: [AMBER-Developers] ips.f::aips_sumrc() is not using nfftdim2
andnfftdim3
> Dear all,
>
> In the process of resolving a gfortran compiler warning in the ips.f code,
> I discovered that the subroutine aips_sumrc is not using nfftdim2 or
> nfftdim3:
>
> gfortran -Wall -c -O0 -ffree-form -o ips.o _ips.f
> In file _ips.f:1871
>
>
> nfft1,nfft2,nfft3,nfftdim1,nfftdim2,nfftdim3,eerq,eerw,rec_vir)
> 1
> Warning: Unused variable nfftdim3 declared at (1)
> In file _ips.f:1871
>
>
> nfft1,nfft2,nfft3,nfftdim1,nfftdim2,nfftdim3,eerq,eerw,rec_vir)
> 1
> Warning: Unused variable nfftdim2 declared at (1)
>
>
>
>
> The only place in which nfftdim1 is used within this subroutine is in the
> definition of some array sizes:
>
> _REAL_ q(2,nfft3,nfftdim1,nfft2),w(2,nfft3,nfftdim1,nfft2)
> _REAL_ elen(2,nfft3,nfftdim1,nfft2),vdwn(2,nfft3,nfftdim1,nfft2)
> _REAL_ qxx(2,nfft3,nfftdim1,nfft2),wxx(2,nfft3,nfftdim1,nfft2)
> _REAL_ qxy(2,nfft3,nfftdim1,nfft2),wxy(2,nfft3,nfftdim1,nfft2)
> _REAL_ qxz(2,nfft3,nfftdim1,nfft2),wxz(2,nfft3,nfftdim1,nfft2)
> _REAL_ qyy(2,nfft3,nfftdim1,nfft2),wyy(2,nfft3,nfftdim1,nfft2)
> _REAL_ qyz(2,nfft3,nfftdim1,nfft2),wyz(2,nfft3,nfftdim1,nfft2)
> _REAL_ qzz(2,nfft3,nfftdim1,nfft2),wzz(2,nfft3,nfftdim1,nfft2)
>
> I am not familar with this code, or with what this routine is meant to be
> doing, but the non-use of the nfftdim2 and nfftdim3 parameters above is
> suspicious and looks like it could be the result of a *possible* cut and
> paste typo. I am probably wrong, but can anyone comment on this?
>
>
> --
> Mark Williamson, Post Doc
> Walker Molecular Dynamics Group
> Room 395E
> San Diego Supercomputer Center
> 9500 Gilman Drive
> La Jolla, CA 92093-0505
> Email: mjw at sdsc.edu
> Office: 858-246-0827
>
> _______________________________________________
> 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 Tue Feb 02 2010 - 14:00:04 PST
