The motivation behind using half complex fft's is performance related; Mike
Crowley gets credit for this going back to amber 7, and it is a great idea
that has been written up and used in various places. I would have to look
up some stuff to attempt to explain it, and unless you are a numerical
methods weeny, you would not care anyway. The two sets of indices are a
convenience, though there is an opportunity to shoot yourself in the foot
here, for the uninitiated. I don't know whether Mike or Tom first did it,
but there are good reasons for it; it is however indeed not well documented.
So I am not doing any criticizing on this one; just trying to make sure
there are slightly fewer self-inflicted wounds... ;-)
- Bob
----- Original Message -----
From: "Mark Williamson" <mjw.sdsc.edu>
To: "AMBER Developers Mailing List" <amber-developers.ambermd.org>
Sent: Tuesday, February 02, 2010 5:47 PM
Subject: Re: [AMBER-Developers] ips.f::aips_sumrc() is not using
nfftdim2andnfftdim3
> Robert Duke wrote:
>> 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
>
> Thanks Bob, I was not aware of this. It sounds quite esoteric; I assume
> the motivation behind this was performance related? Are there any
> documents expanding upon this?
>
> regards,
>
> Mark
>
> _______________________________________________
> 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 - 15:00:03 PST
