Hi All,
I Just made a new push with updates of pbsa-related licenses, fftw-code
removing, mmpbsa_py and cpptraj fftw compilation error fix. We tested on
several gnu and intel platforms (as shown below) and all compiled.
Strangely on clang 6.0+gfortran 5.2/4.9, which used to work, the
compilation just hangs for some fortran90 sorce file we didn't change.
Please help testing whether the issue can be reproduced on other OS X
platform since we only have access to a Yosemite cuda machine. Thanks a lot!
cuda 8.0+gnu 5.4.0: OK
cuda 8.0+gnu 4.4.7: OK
cuda 8.0+intel 16.0: OK
cuda 7.5+gnu 4.8.2: OK
cuda 7.5+gnu 4.4.7: OK
cuda 7.5+clang/gfortran: Hangs with gfortran
Best,
Ruxi
On 3/22/17 11:22, Ruxi Qi wrote:
> 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 - 20:00:02 PDT
