RE: [AMBER-Developers] ips.f::aips_sumrc() is not using nfftdim2andnfftdim3

From: Wu, Xiongwu (NIH/NHLBI) [E] <"Wu,>
Date: Tue, 2 Feb 2010 19:14:10 -0500

The DFFT subroutines in ips.f were following the way that ew_recip.f was written and reused many functions in PME calculation. Exactly as Mark I was confused by NFFTs and NFFTDIMs and took a long time to understand the DFFT code through extensive debugging. I am afraid the paper by Crowley, Darden, Cheatham, III, and Deerfield, II shows mainly the concept but not the code detail. Agree with Bob and Scott that study the code is not an enjoyable thing.

Thanks!

Xiongwu

> -----Original Message-----
> From: Scott Brozell [mailto:sbrozell.rci.rutgers.edu]
> Sent: Tuesday, February 02, 2010 6:57 PM
> To: AMBER Developers Mailing List
> Subject: Re: [AMBER-Developers] ips.f::aips_sumrc() is not using
> nfftdim2andnfftdim3
>
> Hi,
>
> Rats, a missed opportunity:
>
> But I agree with Bob, dont study this unless you're
> waiting for sander to compile.
> ;:::)))))
>
> better late than never ?
> scott
>
> On Tue, Feb 02, 2010 at 06:45:49PM -0500, Scott Brozell wrote:
> > Hi,
> >
> > If you really want to study nfft vs nfftdim then start with
> > get_fftdims in ew_fft.f.
> > It might also be useful to browse spatial_recip.f and spatial_fft.f
> > since that gives a different perspective, and there may be more
> > explanations in spatial_fft.f than in the originals.
> > I think the reference on this is
> > .Article{Crowley97,
> > author = {Crowley, M.F. and Darden, T.A. and Cheatham, III, T.E. and
> Deerfield, II, D.W.},
> > title = {{Adventures in improving the scaling and accuracy of a
> parallel molecular dynamics program}},
> > journal = {J. Supercomput.},
> > volume = {11},
> > pages = {255-278},
> > year = {1997} }
> >
> > But I agree with Bob, dont study this unless your spouse is on a Roman
> Holiday.
> >
> > scott
> >
> > On Tue, Feb 02, 2010 at 05:53:36PM -0500, Robert Duke wrote:
> > > 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

_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Tue Feb 02 2010 - 16:30:03 PST
Custom Search