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: https://github.com/swails/jmsscripts/ 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.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Jun 17 2014 - 12:30:02 PDT
