Re: [AMBER] Oscillating electric fields

From: Brian Radak <radak004.umn.edu>
Date: Wed, 22 Jan 2014 11:05:02 -0500

Jason's response seems pretty thorough, but this is interesting to me. I'll
add a hop on question if I may:

Does Langevin dynamics with a time dependent force make physical sense from
a theoretical point of view? That would be combining a (presumably) regular
driving force with damping and a stochastic element. What
 is the physical framework for analyzing that? I'm a bit of a novice in the
non-equilibrium stat mech arena, so I'm genuinely curious what is happening
here.

Brian


On Wed, Jan 22, 2014 at 10:15 AM, Jason Swails <jason.swails.gmail.com>wrote:

> 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
>



-- 
================================ Current Address =======================
 Brian Radak                                             :     BioMaPS
Institute for Quantitative Biology
 PhD candidate - York Research Group       :     Rutgers, The State
University of New Jersey
 University of Minnesota - Twin Cities         :     Center for Integrative
Proteomics Room 308
 Graduate Program in Chemical Physics     :     174 Frelinghuysen Road,
 Department of Chemistry                          :     Piscataway, NJ
08854-8066
 radak004.umn.edu                                 :
radakb.biomaps.rutgers.edu
====================================================================
Sorry for the multiple e-mail addresses, just use the institute appropriate
address.
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Wed Jan 22 2014 - 08:30:02 PST
Custom Search