Hi,
By default, cpptraj will configure itself for the FFTW bundled with
Amber if the configure2 variable "$has_fftw3" is 'yes' (see around
line 3327). The error indicates that fftw has not been built by the
time the cpptraj build starts. The fftw compile is triggered by the
$(FFTW3) variable (which in turn is contained by THIRDPARTY), so it
will happen for serial, cray_serial, cray_parallel, cray_openmp,
openmp, and parallel targets. I suspect the easiest solution is to add
the $(FFTW3) variable as a dependency for the 'cpptraj::' target.
-Dan
PS - Long term if we are going to stop bundling fftw with Amber we may
want to add a '--with-fftw' flag to configure.
On Wed, Mar 22, 2017 at 3:30 AM, Ruxi Qi <ruxiq.uci.edu> wrote:
> Hi All,
>
> We encountered cpptraj compilation error when we removed FFTW-related
> pbsa codes under AmberTools/src/pbsa/ and in configure2, and some
> related test cases. The weird thing is the error occurred even we didn't
> touch any code outside pbsa. These errors are as follows, seems missing
> proper FFTW header file path. I didn't find any pbsa-variable in
> configure2 that could cause this. Could anybody look into this please?
> The compilation was on gnu 4.4/5.0 with cuda 7.5. Thanks!
>
> In file included from Analysis_FFT.cpp:4:
> PubFFT.h:5:20: error: fftw3.h: No such file or directory
> In file included from Corr.h:4,
> from Action_VelocityAutoCorr.cpp:7:
> PubFFT.h:5:20: error: fftw3.h: No such file or directory
> In file included from Corr.h:4,
> from Analysis_IRED.cpp:4:
> PubFFT.h:5:20: error: fftw3.h: No such file or directory
> In file included from Analysis_FFT.cpp:4:
> PubFFT.h:27: error: ISO C++ forbids declaration of 'fftw_complex' with
> no type
> PubFFT.h:27: error: expected ';' before '*' token
> PubFFT.h:28: error: 'fftw_plan' does not name a type
> PubFFT.h:29: error: 'fftw_plan' does not name a type
>
> Best,
>
> Ruxi
>
>
>
> On 3/18/17 15:13, Ray Luo wrote:
>> Jason and All,
>>
>> I think we can boot FFTW out if this is needed for the license scheme
>> to work. It's not used in sander or not used often in PBSA since we
>> have both multigrid and ICCG solvers for the periodic boundary.
>>
>> All the best,
>>
>> Ray
>> --
>> Ray Luo, Ph.D.
>> Professor of Structural Biology/Biochemistry/Biophysics,
>> Chemical Physics, Biomedical Engineering, and Chemical Engineering
>> Department of Molecular Biology and Biochemistry
>> University of California, Irvine, CA 92697-3900
>>
>>
>> On Sat, Mar 18, 2017 at 1:25 PM, Jason Swails<jason.swails.gmail.com> wrote:
>>> On Sat, Mar 18, 2017 at 2:49 PM, David Case<david.case.rutgers.edu> wrote:
>>>
>>>> On Fri, Mar 17, 2017, Jason Swails wrote:
>>>>
>>>>> So the issue here is that by licensing libsander as LGPL, we violate the
>>>>> terms of PBSA's GPL license.
>>>> I'd like to ask Jason to help us out of this mess, if he is willing. In
>>>> the
>>>> statement just above, one could replace "PBSA" with "fftw", and illustrate
>>>> a
>>>> similar problem. (In fact, fftw is really at the root of most of our
>>>> problems, since we can modify the PBSA license.)
>>>>
>>>> High-level view: we could change the licenses of anything we have written.
>>>> But we also need to be able to create create a GPL code that is allowed
>>>> to link to fftw libraries, and at the same time have a sander API and
>>>> libsander that non-GPL codes can link to. So it seems like "sander" and
>>>> "libsander" have to have different licenses.
>>>>
>>> I had forgotten about fftw. Fortunately, PBSA can be built *without*
>>> fftw. But as long as it includes fftw, the whole thing would need to abide
>>> by the GPL.
>>>
>>>
>>>> Questions:
>>>>
>>>> 1. Is there a technical reason why libpbsa and libfftw3 need to be
>>>> included
>>>> into the Makefile target for libsander? (Stated another way: how hard
>>>> would it be to eliminate these?) I think the sander API does not
>>>> expose
>>>> either pbsa or rism functionality, yet the symbols for pbsa and fftw
>>>> are
>>>> included in libsander, and I'm wondering if that can be changed.
>>>>
>>> The technical reason was ease of implementation. What might be easiest is
>>> to make it so PBSA's periodic functionality is turned off both when -nofftw
>>> is set *and* when that file is being built for the sander API. In that
>>> case, we can omit fftw from sander and release the whole thing as L-GPL
>>> (assuming we license PBSA under both the L-GPL [sans fftw] and the GPL [for
>>> versions that include fftw]). I'm not sure how straightforward this is.
>>>
>>> PBSA could also probably be eliminated from libsander altogether, although
>>> that would probably require some amount of code changes to ifdef-out the
>>> hooks into sander.
>>>
>>> The last idea is that MKL is API-compatible with fftw, so we could also
>>> permit MKL users to abide by the L-GPL (does PBSA link to MKL's FFT if MKL
>>> is specified?)
>>>
>>>
>>>> 2. Can we separate things in order to be able to make a license
>>>> distinction: libsander (and its corresponding source code) could be
>>>> LGPL,
>>>> whereas the sander (as a whole) would be GPL? Alternative: go back
>>>> to the old days, where we had separate sander.RISM (would be GPL) and
>>>> and sander (would be LGPL) builds.
>>>>
>>> Yes, we can do that.
>>>
>>>
>>>> We don't necessarily need to get this done for the AmberTools17 release,
>>>> but
>>>> should be trying in good faith to make any required changes. Weaning
>>>> ourselves from fftw might be a long-term goal, but would be far from easy.
>>>>
>>> It *would* be nice to boot FFTW from sander from a licensing perspective.
>>>
>>> Ray -- are the periodic options even available from sander? If not, that
>>> makes things easy -- just remove that part from sander altogether and fftw
>>> never enters the picture (assuming we can also get rid of from the sander
>>> API).
>>>
>>> Thanks,
>>> Jason
>>>
>>> --
>>> Jason M. Swails
>>> _______________________________________________
>>> 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
--
-------------------------
Daniel R. Roe
Laboratory of Computational Biology
National Institutes of Health, NHLBI
5635 Fishers Ln, Rm T900
Rockville MD, 20852
https://www.lobos.nih.gov/lcb
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Mar 22 2017 - 06:00:04 PDT
