On Wed, Mar 22, 2017 at 11:52 PM, Hai Nguyen <nhai.qn.gmail.com> wrote:
> 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
>
>
Oops sorry for the noise for this circleci issue, not related to pbsa build.
Hai
> 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:05 PDT
