aslo hanging with another run on circleci I setup to build AmberTools binary
centos-5
and
gcc -v
The C version is 4.8.2
The Fortran version is 4.8.2
If you have docker, you can use the image: ambermd/amber-build-box
Hai
On Wed, Mar 22, 2017 at 11:45 PM, Hai Nguyen <nhai.qn.gmail.com> wrote:
> 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:04 PDT
