Re: amber-developers: Amber/APBS module outline

From: Robert Konecny <>
Date: Wed, 12 Apr 2006 10:09:58 -0700

Hi Dave,

thanks for your comments!

> To me, it looks like there are two main things this provides:
> 1. The ability to directly and easily compare pbsa and APBS results, in terms
> of results, dependence on grid spacing, computational efficiency, memory use,
> and so on.

In the next version I'd like also to put in support for parallel APBS
execution, which is another strong feature of APBS and should enable to
perform implicit solvent calculations on much larger systems from within

> 2. This comparison might be especially interesting for the "pure implicit
> solvent dynamics", since this is a new feature for sander/pbsa, and yet is one
> that people have a lot of interest in pursuing.

Surprisingly, there is also a lot of interest in simplification of
visualization of calculated electrostatic maps, charge maps and surfaces -
all this is easily done with the sander/APBS module.

> A couple of comments:
> 1. Unlike Amber 8, in Amber 9 the "igb=6" option is no longer unused, but
> is rather used for the case of no dielectric boundary. So, I suggest that you
> turn on iAPBS with igb=11 instead. This has the advantage of being adjacent
> to igb=10, which is the analogous switch for pbsa.

That's exactly what I did initially but then I realized that with igb/=6
(.e.g, igb=10) sander does not provide all non-bonding internal energy
terms, these are left to be calculated by the solvation model module (like
Ray Luo's PB module with igb=10, or GB). Since APBS obviously does not
calculate this I would have to hack the sander routines for this and it
seemed that a bit cleaner approach would be to use igb=6. Although
admittedly, this combination of keywords is confusing. So I threw out my
initial implementation and redid this for igb=6.

Again, since I'm not an Amber expert, maybe there is an easier way to do
this with igb=11. Or a possible hack would be to use igb=11 in the &cntrl
section but internally use igb=6. This would 'hide' this inconsistency
from users and still do the right thing. I don't know. I'm open to

> 2. If it looks promising, we should incorporate this into the Amber 10 CVS
> tree, so that developers will get it automatically. This will greatly reduce
> the activation barrier for having people try it out. For now, however, we'll
> try the method you have on the web page, above.

Sounds great. The actual sander modifications are all minor and are in
'#ifdef APBS' statements so they are turned on only with 'make -DAPBS'.
Without this the normal sander code is processed.

Thanks again!

Received on Fri Apr 14 2006 - 03:25:44 PDT
Custom Search