On Thu, Feb 18, 2016 at 3:53 PM, Ross Walker <ross.rosswalker.co.uk> wrote:
>
> > On Feb 18, 2016, at 12:12 PM, Hai Nguyen <nhai.qn.gmail.com> wrote:
> >
> > On Thu, Feb 18, 2016 at 2:01 PM, Ross Walker <ross.rosswalker.co.uk>
> 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.(
> > https://github.com/numpy/numpy). 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: http://archive.ambermd.org/201406/0502.html
> >
>
> 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.
>
>
I agree with your points here.
> > 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.
>
>
Yes, if you can use 'yum-install', 'apt-get install', or any command you
need to remember for different Linux distributions, you can also use 'pip
install` for Python packages.
Our idea is to provide users an option to install Miniconda from Anaconda
to have all good Python packages. In my opinion, this approach is more
suitable for general users who do not have admin permission to use *sudo
for *yum install (at least help me :D).
> 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.
>
>
agree. thanks for your feedback.
Hai
> All the best
> Ross
>
> /\
> \/
> |\oss Walker
>
> ---------------------------------------------------------
> | Associate Research Professor |
> | San Diego Supercomputer Center |
> | Adjunct Associate Professor |
> | Dept. of Chemistry and Biochemistry |
> | University of California San Diego |
> | NVIDIA Fellow |
> | http://www.rosswalker.co.uk | http://www.wmd-lab.org |
> | Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
> ---------------------------------------------------------
>
> 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
> 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 Thu Feb 18 2016 - 13:30:04 PST
