Re: [AMBER-Developers] nofftw3 and MKL

From: Scott Brozell <>
Date: Tue, 14 Oct 2014 23:47:24 -0400


The legal issues are presented here:

Since we as a community want to support free software,
and since the GPL intent is to prohibit any derivative linking of commercial
software with GPL software ( note the compiler exception here ),
we probably don't want to offer any facilitation.

On Tue, Oct 14, 2014 at 05:50:14PM -0700, Ross Walker wrote:
> Huh? - IANAL but seems to me that since we don't distribute any binaries
> and we require the user to build their own copy of AMBER that by doing so
> - that is manually running ./configure themselves and then typing make
> they are themselves manually linking to FFTW3 and we are not doing
> anything 'automatic' for them so this is probably not an issue.
> If we want to be completely anal about it then we could just have
> configure (if it is including full amber) to prompt with a message that
> FFTW3 is GPL blah de blah de blah and therefore requires you, the user, to
> manually accept it's linking to pmemd - do you accept yes/no. A no would
> be logically equivalent to -nofftw3 (for pmemd).
> On 10/14/14, 6:44 AM, "David A Case" <> wrote:
> >On Tue, Oct 14, 2014, Jason Swails wrote:
> >>
> >> As for the "why don't we use FFTW for pmemd"... I think the answer is
> >>that
> >> we can't, right? FFTW is GPL and pmemd is not, correct? Users are
> >>free to
> >> link it themselves, but we can't do it automatically for them, I don't
> >> think.
> >
> >I've never understood the implications here, and have spent a lot of time
> >trying to find the answer on the web. Jason's explanation seems the most
> >correct.

On Tue, Oct 14, 2014 at 09:41:21PM -0400, Jason Swails wrote:
> On Tue, Oct 14, 2014 at 10:03 AM, Daniel Roe <> wrote:
> > On Tue, Oct 14, 2014 at 7:44 AM, David A Case <>
> > wrote:
> > > The implication of this is that we can't support pmemd using the cray
> > > compilers (right now): we can't automatically link to FFTW3 because of
> > license
> > > issues, and we can't get the Cray compilers to work with pubfft. (Not
> > sure
> > > how long ago it was that anyone tried this.)
> >
> > Jason ended up tracking down the issues in pubfft so I think the issue
> > has been fixed but I don't 100% remember.
> ???I found _an_ optimization bug on my machine (AMD FX-6100) using the GNU
> compilers. It went away by eliminating -mtune=native, which prevented some
> loop variables from being optimized away.
> The solution is to either apply the save or volatile attributes to those
> variables in order to explicitly prohibit those loop variables from being
> optimized away.

The details are here:



IANAL is that an acid trip to Amber 14/2 or like


AMBER-Developers mailing list
Received on Tue Oct 14 2014 - 21:00:02 PDT
Custom Search