Aslo get "hanging issue" on Linux on travis build:
https://travis-ci.org/Amber-MD/ambertools-test/builds/214097796
gfortran -DBINTRAJ -DEMIL -c -O3 -mtune=native -fPIC -ffree-form
-I/home/travis/build/Amber-MD/ambertools-test/amber17/include
-I/home/travis/build/Amber-MD/ambertools-test/amber17/include -o
pb_fdfrc.o pb_fdfrc.F90
gfortran -DBINTRAJ -DEMIL -c -O3 -mtune=native -fPIC -ffree-form
-I/home/travis/build/Amber-MD/ambertools-test/amber17/include
-I/home/travis/build/Amber-MD/ambertools-test/amber17/include -o
pb_read.o pb_read.F90
No output has been received in the last 10m0s, this potentially
indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on:
https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received
The build has been terminated
Hai
On Wed, Mar 22, 2017 at 11:41 PM, Hai Nguyen <nhai.qn.gmail.com> wrote:
> 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:03 PDT
