Re: [AMBER] bash scripting for MD tasks

From: James Starlight <>
Date: Thu, 19 Jun 2014 17:52:51 +0400

Thanks, Jason!

It's very useful advises and you've made very great script library! I'll
try to follow your basic ideas during my own studies.


2014-06-17 23:25 GMT+04:00 Jason Swails <>:

> On Tue, 2014-06-17 at 22:16 +0400, James Starlight wrote:
> > Hi Dan,
> >
> >
> > many thanks for the bash guide- I've found it very useful. In general I'd
> > like to look at some basic bash script examples suitable for typical md
> > jobs dealing with the running of many of simulation on clusters because
> the
> > most complicated examples like replica exchange simulation have already
> > been present in the amber tutorials.
> You've gotten the most helpful responses you can possibly get about your
> question so far, so I won't belabor the points others have made. I'll
> relay my own opinions on the topic, though.
> Scripting is, at its core, simply a tool we (as computational
> scientists) use to increase our efficiency and productivity. For
> example, high-throughput work like screening a database of millions of
> compounds cannot be done unless "scripted."
> When you are designing an experiment or calculation you want to perform,
> you have a list of tasks you need to get done. Designing a script to
> carry out these tasks requires you to divide your problem up into
> simpler chunks that can be easily represented with common logic
> structures in programming/scripting, like loops and simple conditionals.
> Writing the script is easy -- if you don't know the syntax of doing
> something like looping over a list, you can google your question and see
> that it has most likely been asked and answered several times on
> StackOverflow before.
> _Designing_ the script is the real challenge (it is an art). It is not
> something easily taught in a tutorial (nor is there any one "right" way
> to do it). You can use the existing tutorials, and the scripts written
> therein, to try and reverse-engineer the design and try to understand
> the thought process that led the tutorial authors to write it that way.
> Then if you're ambitious, try improving it.
> When you are doing your own project, focus on carrying out your
> experiment. If you come up to a part that is particularly repetitive or
> something that fits conceptually into a scripting or programming
> paradigm, write a script to handle that part (Googling your question
> when you don't know how to do something). The more you do this, the
> better you will get at scripting and the more you will be able to
> automate your workflows.
> If you find yourself doing the same thing over and over for different
> projects (like imaging a trajectory or RMS-fitting your system with
> cpptraj or computing a distance and plotting the result), try to write a
> script to automate that task. As your experience in the field grows, so
> too will your library of scripts you find useful and your scripting
> ability overall. Mine is here: and
> a trained eye can clearly see which ones I wrote when I was experienced
> and which I didn't.
> 6 years ago, I had never used Unix before. I was decent at scripting
> within a few months and quite strong within a year or two -- all
> following the above advice. That which is self-learned is learned the
> best (and is remembered the longest).
> Always rambling,
> Jason
> --
> Jason M. Swails
> BioMaPS,
> Rutgers University
> Postdoctoral Researcher
> _______________________________________________
> AMBER mailing list
AMBER mailing list
Received on Thu Jun 19 2014 - 07:00:02 PDT
Custom Search