Hi,
I tried serial build with my mac (serira 10.12.3), native clang (8.0.0),
gfortran
I don't see the output of "make install" for pbsa. This process hangs
forever (I've been waiting for few minutes and
need to interrupt that).
AmberTools/src/pbsa (master) $ make install
(also tried with "make", "make install.serial": nothing new)
PS: The install ran fine with OSX on travis (clang 7.3.0)
https://travis-ci.org/Amber-MD/ambertools-test/builds/214097774
Hai
On Wed, Mar 22, 2017 at 11:00 PM, Ruxi Qi <ruxiq.uci.edu> wrote:
> 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
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Mar 22 2017 - 21:00:02 PDT
