Hi
You mean RHEL 6 does not have python?
Hai
> On Feb 6, 2017, at 7:33 AM, Ross Walker <ross.rosswalker.co.uk> wrote:
>
> So does this mean we are officially dropping RHEL 6 support?
>
>> On Feb 6, 2017, at 02:06, Hai Nguyen <nhai.qn.gmail.com> wrote:
>>
>> It seems to me that your system has only python <= 2.6?
>>
>> In AT17, the --skip-python still use Python for some programs. Basically we
>> wrap some programs requiring AMBERHOME
>> at run time (e.g nab, tleap, ...) by using a python script.
>>
>> The script AmberTools/conda-recipe/scripts/patch_amberhome/copy_and_post_process_bin.py
>> will update the binary files in $AMBERHOME/bin
>>
>> Why do we do that? Because we are thinking about distribute
>> binary-AmberTools too (mostly via conda). We only need
>> user to "conda install ambertools -c ambermd" and just it, user do not need
>> to do anything else (even source amber.sh).
>>
>> I probably need to fix copy_and_post_process_bin.py so it can be run with
>> any python version.
>>
>> (worked fine with my python 3.5 on macos
>>
>> ./configure --prefix ~/try_amber_no_python/ --skip-python -macAccelerate
>> clang
>>
>> )
>> cheers
>> Hai
>>
>> On Mon, Feb 6, 2017 at 1:16 AM, Scott Brozell <sbrozell.rci.rutgers.edu>
>> wrote:
>>
>>> Hi,
>>>
>>> In a fresh repo of the master:
>>> ./configure -mkl --skip-python intel
>>> make
>>> ...
>>> make[2]: Leaving directory `/tmp/amber/AmberTools/src/nfe-umbrella-slice'
>>> (if [ "yes" = "no" ]; then \
>>> make python_serial ;\
>>> fi;\
>>> )
>>> (python conda-recipe/scripts/patch_amberhome/copy_and_post_process_bin.py
>>> /tmp/amber/bin /tmp/amber/bi
>>> n)
>>> Traceback (most recent call last):
>>> File "conda-recipe/scripts/patch_amberhome/copy_and_post_process_bin.py",
>>> line 228, in <module>
>>> main()
>>> File "conda-recipe/scripts/patch_amberhome/copy_and_post_process_bin.py",
>>> line 224, in main
>>> script_template=script_template)
>>> File "conda-recipe/scripts/patch_amberhome/copy_and_post_process_bin.py",
>>> line 158, in copy_to_targe
>>> t_folder
>>> print('patching {}'.format(final_exe_path))
>>> ValueError: zero length field name in format
>>> make[1]: *** [serial] Error 1
>>> make[1]: Leaving directory `/tmp/amber/AmberTools/src'
>>> make: *** [install] Error 2
>>>
>>>> On Sat, Feb 04, 2017 at 08:24:01PM -0500, Hai Nguyen wrote:
>>>> after some testings, I go head merging my change for --prefix option to
>>>> master branch.
>>>>
>>>> Those commits should not affect your regular workflow (hopefully) but if
>>>> any, please let me know (or even better if make a new commit to fix :D).
>>>>
>>>> Usage example: You can try different compilers by
>>>>
>>>> mkdir $HOME/try_amber_prefix
>>>> cd amber17
>>>> ./configure --prefix $HOME/try_amber_prefix gnu
>>>> source amber.sh
>>>> make install
>>>>
>>>> After the regular install, all installed files will be in
>>>> $HOME/try_amber_prefix.
>>>>
>>>> Of course, to run programs in try_amber_prefix folder, you still need to
>>>> source $HOME/try_amber_prefix/amber.sh
>>>>
>>>> Expected failures if running the tests for "--prefix" option:
>>>> FEW.pl: I don't know Perl well to make change, so just let it be.
>>>> pymsmt: It's using some library in its source folder at run time. I think
>>>> Pengfei is working on this.
>>>>
>>>> Hai
>>>>
>>>>> On Thu, Feb 2, 2017 at 1:05 PM, Hai Nguyen <nhai.qn.gmail.com> wrote:
>>>>>
>>>>> thanks. I will look at the Python stuff.
>>>>>
>>>>> Should expect not able to run some (most?) tests (even if copying
>>>>> $AMBERHOME/test and AmberTools/test to $PREFIX)
>>>>> since some of the tests point to the source folder.
>>>>>
>>>>> cheers.
>>>>> Hai
>>>>>
>>>>>
>>>>> On Thu, Feb 2, 2017 at 1:02 PM, Daniel Roe <daniel.r.roe.gmail.com>
>>> wrote:
>>>>>
>>>>>> PS - The 'prefix' install was 328MB, compared to 2.5 GB for a full
>>>>>> Amber 16 install. Very nice.
>>>>>>
>>>>>> On Thu, Feb 2, 2017 at 1:00 PM, Daniel Roe <daniel.r.roe.gmail.com>
>>>>>> wrote:
>>>>>>> Got a chance to try this today. I haven't tested thoroughly but it
>>>>>>> seems to work well. Nice work Hai!
>>>>>>>
>>>>>>> I hit a brief hiccup during my initial attempt with python stuff:
>>>>>>> ```
>>>>>>> Checking .pth file support in
>>>>>>> /u/droe/Amber/TEMP/prefix/lib/python2.7/site-packages/
>>>>>>> /mnt/local/droe/anaconda2/bin/python -E -c pass
>>>>>>> TEST FAILED: /u/droe/Amber/TEMP/prefix/lib/python2.7/site-packages/
>>>>>>> does NOT support .pth files
>>>>>>> error: bad install directory or PYTHONPATH
>>>>>>> ```
>>>>>>> It went on to describe the problem and potential solutions which was
>>>>>>> really nice, but the real issue was I had forgotten to source
>>> amber.sh
>>>>>>> - that fixed the problem. So maybe that could be the first thing you
>>>>>>> suggest for potential solutions?
>>>>>>>
>>>>>>> -Dan
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jan 25, 2017 at 3:48 PM, Hai Nguyen <nhai.qn.gmail.com>
>>> wrote:
>>>>>>>> Oops, no "="
>>>>>>>>
>>>>>>>> ./configure --prefix $HOME/try_another_folder gnu
>>>>>>>>
>>>>>>>> On Wed, Jan 25, 2017 at 3:31 PM Hai Nguyen <nhai.qn.gmail.com>
>>> wrote:
>>>>>>>>
>>>>>>>>>> If I happen to get free time before
>>>>>>>>> now and the code freeze maybe I'll take another crack at making
>>> this
>>>>>>>>> happen.
>>>>>>>>>
>>>>>>>>> .Dan: I have working code in amber_prefix_Hai branch. Feel free to
>>>>>> try and
>>>>>>>>> update that.
>>>>>>>>>
>>>>>>>>> ./configure --prefix=$HOME/try_another_folder gnu
>>>>>>>>>
>>>>>>>>> Hai
>>>>>>>>>
>>>>>>>>> On Thu, Dec 22, 2016 at 9:44 AM, Daniel Roe <
>>> daniel.r.roe.gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On Wed, Dec 21, 2016 at 10:04 PM, David Case
>>>>>>>>> <dacase.scarletmail.rutgers.edu> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Wed, Dec 21, 2016, Dan Roe wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> But I think it is important that these tests happen at
>>> 'configure'
>>>>>>>>>>> time, and it doesn't seem to me to be that difficult....
>>>>>>>>>>
>>>>>>>>>> It may indeed be do-able, but it is not just a matter of seeing
>>> if
>>>>>>>>> "import
>>>>>>>>>> numpy" throws an error. The configure script would have to
>>> compile
>>>>>>>>> python
>>>>>>>>>> extensions in the same way the real code will (which is actually
>>>>>> several
>>>>>>>>>> ways), and make sure they all work. And since only developers
>>> will
>>>>>>>>> decline
>>>>>>>>>> the miniconda download, and since they can find out by trial and
>>>>>> error if
>>>>>>>>>> their system python works, writing and maintaining this
>>>>>> functionality
>>>>>>>>> seems
>>>>>>>>>> like a lot of work for only a small payback.
>>>>>>>>>
>>>>>>>>> I think that some users (maybe installs at HPC sites etc) may also
>>>>>>>>> want to decline the miniconda download, but it does seem like
>>> python
>>>>>>>>> detection is problematic. As long as the '--with-python' flag
>>> works I
>>>>>>>>> think it's fine anyway. It would be nice to have configure be
>>> able to
>>>>>>>>> test the python ecosystem but if it's too much work then I'll
>>> just put
>>>>>>>>> it on my wishlist.
>>>>>>>>>
>>>>>>>>>> For those who want to play with this, configure2 alreay *has* a
>>>>>>>>>> check_compatible_python() function. We commented out the call
>>> to
>>>>>> this
>>>>>>>>>> function (about line 935) since it was not reliable enough:
>>> having
>>>>>>>>>> configure say a python is OK when it is not is quite annoying
>>> and
>>>>>>>>> confusing.
>>>>>>>>>
>>>>>>>>> Agreed - that's worse from a user standpoint for certain.
>>>>>>>>>
>>>>>>>>>> Knowing I'm repeating myself: we *really* don't want users
>>>>>> installing
>>>>>>>>>> packages into their existing python just to install Amber.
>>> There
>>>>>> is too
>>>>>>>>>> much danger of creating incompatibilities with other things that
>>>>>> require
>>>>>>>>>> python: that is, we increase the danger that installing Amber
>>> breaks
>>>>>>>>>> something else on the user's computer. [numpy, in particular,
>>>>>> exists in
>>>>>>>>>> several incompatible releases; it is quite easy for program A to
>>>>>> require
>>>>>>>>>> version 1.9 and program B to require version 1.10. We can't
>>> solve
>>>>>> that
>>>>>>>>>> problem, but should not make it worse, either.]
>>>>>>>>>
>>>>>>>>> This is one of the gotchas of living in the python universe.
>>> Advanced
>>>>>>>>> users can just use the '--with-python' flag. "Normal" users can
>>> have a
>>>>>>>>> built-in miniconda. We just have to make it clear during configure
>>>>>>>>> time exactly why miniconda is a good idea instead of the vague
>>> "well,
>>>>>>>>> maybe stuff won't work" message of the past.
>>>>>>>>>
>>>>>>>>>>> I'll have to test '--with-python', but if it works there is not
>>>>>> much
>>>>>>>>>>> of a downside that I can see other than that Amber
>>> installation is
>>>>>> now
>>>>>>>>>>> the "python keystone", so I'd better not ever move it or I will
>>>>>> break
>>>>>>>>>>> every Amber install based on it (and it's another configure
>>> flag
>>>>>> that
>>>>>>>>>>> has to be specified each time).
>>>>>>>>>
>>>>>>>>> I was being a bit facetious about having to specify an extra flag
>>> :-)
>>>>>>>>> - that stuff doesn't come through in email sometimes. I think the
>>>>>>>>> '--with-python' flag is the correct solution.
>>>>>>>>>
>>>>>>>>>>>> [Next thing we know, people are going to want to be able to
>>>>>> specify a
>>>>>>>>> build
>>>>>>>>>>>> directory, separate from the sources.....]
>>>>>>>>>>>
>>>>>>>>>>> I still want this :-). For separate installs the size can
>>> really
>>>>>> add
>>>>>>>>>>> up, more because the Amber 16 source tree weighs in at 2.3 GB
>>> - the
>>>>>>>>>>> miniconda install adds 635 MB to that (sizable but not
>>> egregious).
>>>>>>>>>>
>>>>>>>>>> Has anyone tried to just make a shadow directory (using "cp
>>> -as" or
>>>>>>>>> lndir),
>>>>>>>>>> with links to a clean amber tree, then build in the shadow
>>>>>> directory?
>>>>>>>>>
>>>>>>>>> Unfortunately, this can't work for multiple parallel library/CUDA
>>>>>>>>> version builds (maybe I'm not understanding what you mean).
>>>>>>>>>
>>>>>>>>>> Realistically, I'd recommend bigger disks. You can get 500 Gb
>>>>>> external
>>>>>>>>>> SSD drives with USB-3 or USB-C interconnects that are quite fast
>>>>>> and will
>>>>>>>>>> allow you create all the Amber images you are ever likely to
>>>>>> need....
>>>>>>>>>
>>>>>>>>> Just because disk space is cheap doesn't mean we should be
>>> wasteful. I
>>>>>>>>> would like to do with Amber what I can do with every other linux
>>>>>>>>> source code package: have one giant source directory that I can
>>> point
>>>>>>>>> to an install directory with '--prefix', and then that install
>>>>>>>>> directory contains only what I need to run that version of Amber.
>>>>>>>>> AMBERHOME can point to the common source, but PATH and
>>> LD_LIBRARY_PATH
>>>>>>>>> point to the install directory. If I happen to get free time
>>> before
>>>>>>>>> now and the code freeze maybe I'll take another crack at making
>>> this
>>>>>>>>> happen.
>>>
>>> _______________________________________________
>>> 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 Mon Feb 06 2017 - 05:30:08 PST
