On Wed, Jan 22, 2014 at 7:10 AM, Bernhard Reuter <b.reuter.uni-kassel.de>wrote:
> Dear Amber specialists,
>
> I'm new to Amber and would like to perform Langevin-Dynamics simulations
> of proteins under the influence of external static and oscillating
> electric fields.
>
> Could you please tell me, if this is possible with Amber and if it isn't
> how to do the modifications in the Amber code (which modules and
> subroutines would need to be modified).
>
This is not currently possible to my knowledge. To add this ability you
would need to modify the force routine (see force.F90 in
$AMBERHOME/src/sander if you have Amber 12) and add your force to that
subroutine. Doing everything 'correctly' will require a decent amount of
code study and a lot of debugging. The sander code is difficult to grok at
first (and has some unusual coding 'styles'), so it will probably require a
bit of study before you get your method working.
> Also I would really appreciate a organigram or flowchart of amber that
>
> tells me how the variables are handled and modified.
>
There is no really consistent way that this happens. Many variables are
declared in common blocks inside header files that are just included
wherever they are needed. Others are stored as module variables that are
simply imported where they are needed. The rest are passed in as
arguments to the subroutine (and all arguments are pass-by-reference in
Fortran as opposed to the canonical pass-by-value in C/C++ for simple
types). grep will be your friend here (particularly "grep -i" since
Fortran is case-insensitive for variable and subroutine names). In sander
there really is no rhyme or reason for choosing one over the other (the
actual reason has to do with the evolution of sander -- newer functionality
tends to use modules whereas older ones tend to go on common blocks).
pmemd, on the other hand, deals almost exclusively with modules and imports
variables from there (rather than using common blocks in header files). It
typically takes subroutine arguments designed to make it easy to change
certain behavior without having to modify the underlying module variable
beforehand. You may find pmemd a bit easier to modify, but some of the
internals (like the atom distribution in parallel) are less straightforward
than how sander does things (which is why sander is so much slower and
scales worse).
The moral of the story is that Amber is not designed to be able to add
functionality easily, and you may want to look into some alternatives.
OpenMM, for instance, makes adding new forces very easy (an oscillating
electric field may be a challenge if only conservative forces are easily
added). Some advantages with OpenMM in this case is that you can still
use Amber input files (topology and inpcrd files), you can write your
program directly in Python including the addition of custom external
forces, and the code will run directly on GPUs using either CUDA or OpenCL
(the CPU code itself will be quite slow).
HTH,
Jason
--
Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Wed Jan 22 2014 - 07:30:03 PST
