I see. I did notice the libfftw3.a target is not triggered in AmberTools
Makefile. Will fix this. Thanks a lot!
Best,
Ruxi
On 3/22/17 11:09, Daniel Roe wrote:
> The issue is that the FFTW build is not being triggered for CPPTRAJ.
> It was previously triggered by PBSA, but since you removed that it is
> no longer being built before cpptraj. Adding the $(FFTW3) variable as
> a dependency for the 'cpptraj::' target in
> $AMBERHOME/AmberTools/src/Makefile should fix it.
>
> -Dan
>
> On Wed, Mar 22, 2017 at 1:34 PM, Ruxi Qi <ruxiq.uci.edu> wrote:
>> Hi Dan,
>>
>> But still what's confusing is the fresh version pulled from amber master
>> right now compiles with no such error, only when we deleted code inside
>> pbsa folder the error occurs. Both are compiled with './configure -cuda
>> gnu'. I checked the configure option, the variable "$has_fftw3" is
>> indeed "yes". So how does the code change inside pbsa triggers this
>> error? Since the fftw is no longer needed by pbsa, we are planning to
>> get related code removed in this release. Thanks!
>>
>> Best,
>>
>> Ruxi
>>
>>
>> On 3/22/17 5:33, Daniel Roe wrote:
>>> 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
>>>
>>
>> _______________________________________________
>> 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 Wed Mar 22 2017 - 11:30:03 PDT
