Hi
Speaking of our recent polarizable FF developments that uses point dipoles
and point polarizabilities we developed i_resp program that apparently
did not make through to Amber13 (yet).
The goal was to make all those iterative processes imbedded into a single
standalone program that works in same way as known "additive" resp in
terms of inputs.
So this should ease some problems at the FF development stage.
Piotr
On 8/16/13 11:34 AM, "Ross Walker" <ross.rosswalker.co.uk> wrote:
>Hi Dave et al,
>
>I think it would be good to get a discussion going on this and we should
>probably have a plan in place for how AMBER should approach polarization
>for discussion at the next AMBER workshop.
>
>My opinion is that the first thing that needs to be done is to decide
>which of the polarization models is the path to follow - it will be crazy
>and near on impossible to try to support all of the different approaches
>and so it is probably wise to select one now, but select it carefully
>within a number of constraints.
>
>Some points for discussion:
>
>It should be a 'simple' extension to existing force fields that provides a
>measurable improvement. Complexity is not necessarily a good thing. For
>example Amoeba is, I believe, probably the worst choice that could be made
>for addressing polarization for large and long timescale simulations. It
>is complex to parameterize, slow (and always will be) and in a lot of
>cases less accurate than existing fixed charge models. Certainly it has
>the flexibility to be improved but it will always suffer from being too
>complicated in my opinion - at the complexity of implementing and
>parameterizing Amoeba one would probably be better looking at ways to
>improve existing quantum methods and make those faster. So for
>polarization in AMBER, I think it should be:
>
>1) A simple extension to the existing force field and thus easy to add to
>all variants of existing code, easily compatible with our current topology
>files, coordinate files etc, compatible with as many features as possible
>as easily as possible - this includes things like QM/MM, various periodic
>boundary treatments, second derivatives for normal modes (I don't even
>want to think about what the second derivatives would look like for
>Amoeba) etc etc and be able to readily show an improvement over fixed
>charge models.
>
>2) It should be simple for the user to parameterize. A lot of MD these
>days is done to look at behavior of ligands and so it needs to be simple
>enough that one can easily parameterize for huge libraries of ligands. The
>charge derivation (including the polarization) needs to be well
>documented, fast and automated if it is expected that people will adopt
>these new force fields. Antechamber needs to be easily able to process the
>polarizable force field for all reasonable ligands. I believe that a good
>part of the reason FF02 was not widely adopted and extended within AMBER
>was because the tools were never made available to determine the charges -
>it was a manual iterative method and never very well described. Our
>automated parameter fitting tools will need to be updated to support
>fitting polarizable force fields (antechamber for example) so ideally one
>should be chosen that makes this extension simple - otherwise it will need
>substantially more effort to make this effective.
>
>See for example: http://dasher.wustl.edu/ponder/papers/jctc-7-3143-11.pdf
>which outlines the approach for Amoeba. It is at least step wise but far
>from automated at present.
>
>3) It will need to be FAST from the outset. This means it needs to be
>LOCAL. The polarization will need to be constrained to local affects such
>that it can be computed in a massively parallel fashion. Iteration is bad
>but can be dealt with if it can be done in a very local reference frame
>and thus in parallel - e.g. shake. If the polarization is such that it
>requires serialization of key steps in the force calculation and
>integration - for example requiring some form of non local knowledge
>during the iterations then it will be doomed to failure. At the end of the
>day if it can't run effectively on 10^5 or more threads it will never take
>off without custom hardware designed to support it. If the approach needs
>complex matrix algebra, or god forbid a diagonalization it is toast from a
>performance perspective.
>
>4) It should be numerically stable and ideally not require excessive
>precision in the evaluation of the equations. Hardware will likely
>continue to move further and further away from effective double precision
>support so we should keep this in mind. For example the angle term in the
>amoeba force field, expanded to order 4 with some very small pre factors
>could potentially cause all sorts of havoc unless precision is kept very
>tight.
>
>The last two are in my opinion the achilies heel of amoeba. It will never
>compete in terms of speed with pairwise additive force fields on modern
>hardware. I think to really work whatever is decided needs to be able to
>get within a factor of 2 of performance of existing classical
>non-polarizable force fields. If it doesn't then I think the impact will
>be minimal since instead of being a more accurate replacement for
>classical force fields it will be rather a 'more' approximate approach to
>doing QM calculations. This is by no means an unworthy goal, just that I
>think the goal right now should be to improve classical force fields
>rather than trying to come up with a slightly faster QM competing method.
>
>It is unfortunate that engineering considerations dominate choices in MD
>rather than pure scientific considerations but something we cannot ignore.
>
>So I think we need to take a hard look at all the available polarizable
>models, how they work, and then rank them in terms of a series of criteria
>relating to their ease of parameterization, ease of programming, potential
>massively parallelizability and performance. Sure accuracy is a key metric
>here, obviously there is no point devising a 'slower' polarizable model
>that does worse than existing classical force fields, but I think it
>should be a criteria amongst several, not the overriding factor.
>
>Ultimately 'utility' is a subtle mix of accuracy and statistical sampling
>so we need to do this in a way that tries to find the sweet spot.
>
>My 3c.
>
>All the best
>Ross
>
>
>
>On 8/16/13 5:57 AM, "David A Case" <case.biomaps.rutgers.edu> wrote:
>
>>Many exicting developments in molecular simulation revolve around the use
>>of
>>polarizable (aka non-fixed-charge) force fields. Prominent examples
>>inlcude
>>the "ff12pol" efforts from the Amber force field consortium, the Amoeba
>>force
>>field from Ponder&Ren, and the Drude particle ideas from (among others)
>>the
>>CHARMM community.
>>
>>The Amber codes are not currently set up to be very flexible or efficient
>>in
>>using such force field descriptions. I'd like to promote discussion and
>>some
>>real work in allowing greater flexibility in what we do (so that Amber
>>folks
>>can contribute more easily to ff development), and to speed up our codes
>>in
>>this area.
>>
>>I have some funds available to support a post-doc or programmer. I also
>>think
>>that coordination of efforts in various labs would also be helpful. If
>>you
>>have ideas or comments, please post to the amber-developers list.
>>Candidates
>>for a job should contact me directly.
>>
>>...thx....dac
>>
>>
>>_______________________________________________
>>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
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Fri Aug 16 2013 - 12:00:04 PDT
