Hi Hai,
Thank you for thorough tests! I don't have a docker account. So from
your tests, pbsa build hangs on native OS X/clang 8 and Ubuntu 12/gnu
4.6.4; it compiles on OS X/clang 7.3 and other Linux environments. I
noticed your build hangs on a different F90 file from that of my test on
clang 6. That's a little weird. We will dig into and try to fix this ASAP.
And All, any advice if you happen to have experience on this situation
is greatly appreciated.
Best,
Ruxi
On 03/22/2017 08:45 PM, Hai Nguyen 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
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Mar 22 2017 - 23:30:02 PDT
