Re: [AMBER-Developers] Python issues...

From: Ross Walker <>
Date: Thu, 18 Feb 2016 12:53:00 -0800

> On Feb 18, 2016, at 12:12 PM, Hai Nguyen <> wrote:
> On Thu, Feb 18, 2016 at 2:01 PM, Ross Walker <> wrote:
>> Can we at least have a section in the document - and probably we'll
>> ultimately need some detailed tutorials on the website on installing - that
>> lists all of the dependencies needed for AMBER. For Redhat this would be a
>> list of packages that should be installed with yum install.
>> I would argue that if a package needed to compile AMBER (just serial AMBER
>> I am talking about here) is not available as part of the standard OS
>> packages (or at stretch also epel for Redhat) then that module, library etc
>> should really not be used and instead one should code around the need for
>> it.
> I don't think 'code around' is a good idea. Most of AMBER developers are
> not professional programmers, coding core library by our-self will
> introduce enormous bugs and required enormous amount of time in testing.
> One single AMBER developer can't beat the work-horse of 399 numpy
> developers (high performance array in Python) with decades of development.(
> Additionally, we don't want to end up that
> a written program is unusable since the postdoc had moved on and there was
> no funding to support it:

I'm not suggesting we try to beat libraries etc. What I mean is - if you only use a single feature from a 200Meg library for example (and boost is a good example of this) it might be more prudent to try and code up that one feature or find a different way of doing it. But I'm not saying a library where a lot of key features are used should be written ourselves. That would indeed be madness. The main thing is to at least try to minimize the amount of external stuff needed. Keep in mind every library we add we run the risk that down the line that library might get updated and end breaking things and we might now have the person who knows how to immediately fix it. So the less external dependencies we can have the better, especially if they are to obscure things. I'm not saying we should write lots more code - more that if there is a feature in numpy for example that, with a little work, you could get to work in place of feature Y in some super advanced extended version of numpy developed by a single person in
blah we should use the main numpy one.

> By the way, Python packages in AMBER only require well-established
> libraries like numpy or matplotlib (for plotting).

Perfect. But this needs to mean well established libraries available in code currently considered to be enterprise and deployable. This does not mean in version 97.3beta7 of Fedora for example or the very latest Ubutunu nightly build etc. It really needs to mean the major Linux distributions that are deployed and managed at scale. For most cases that means either RedHat 6 or 7 or one of the stable branches of Ubuntu, SuSe etc. Note a lot of code developers and even software shops in general use Ubuntu but very few people have Ubuntu deployed in a managed computing environment - be that a University or a company and so having, it works on Ubuntu be the requirement is not really user friendly. What this likely means in most cases is that some of the newest coolest features of a library can't necessarily be used. I know that's annoying when it comes to writing code and it would be ideal if this wasn't the case but unfortunately it.

So, the main thing is we ideally need a centralized list of easily installable dependencies through the regular installers of each of the major operating systems that are currently listed as still being officially supported. So Redhat 3, 4, 5 etc no. Redhat 6 and 7 - yes.

All the best

|\oss Walker

| Associate Research Professor |
| San Diego Supercomputer Center |
| Adjunct Associate Professor |
| Dept. of Chemistry and Biochemistry |
| University of California San Diego |
| NVIDIA Fellow |
| | |
| Tel: +1 858 822 0854 | EMail:- |

Note: Electronic Mail is not secure, has no guarantee of delivery, may not be read every day, and should not be used for urgent or sensitive issues.

AMBER-Developers mailing list
Received on Thu Feb 18 2016 - 13:00:06 PST
Custom Search