On Mon, Feb 29, 2016 at 12:15 PM, Ivanov, Maxim <maxim.ivanov.marquette.edu>
wrote:
> Hello,
>
> I know that AMBER supports extra point charges out of atomic centers.
> However, the current implementation does not support more than two extra
> points per atom, and I need more (at least six).
>
> I looked at the extra_ps.F90 code and tried to make a few hacks, but ended
> up with the segmentation faults.
>
> Concerns I have so far:
>
> 1. Easy one: in define_frames subroutine I just added an if statement for
> a number of points I want to have
> 2. Also easy one: One of the 2d arrays that is involved in the stuff with
> extra points is hardcoded to store only two elements per one of the
> dimensions (e.g. epframe) because normally you have just two extra points.
> Others arrays can store up to five elements, e.g. enghbrs, epbtyp.
> 3. Not easy: when I increase the size of the arrays throughout the code in
> extra_ps.F90, I can compile successfully but get segmentation fault during
> the execution.
>
> I feel that there could be other things that I didn’t take into account,
> but does anyone know if I can increase the number of extra points to an
> arbitrary number with the current implementation?
>
No. This is going to be exceedingly difficult in just about any code. 6
virtual sites is a *lot*. What this EP code in Amber does is automatically
set up the frame information from the local geometry defined by the bond
lengths, and it special-cases all of the various frames it supports (2 EPs
on a single atom is put into a tetrahedral geometry, 1 EP bisects the
valence angle formed from the parent atom at the center, etc.). Amber's EP
code is highly specific and challenging to modify. You might want to have
a look at mdgx (which has more sophisticated virtual site capabilities), or
codes like GROMACS or OpenMM which also focus more on virtual sites.
However, I don't know that any of those codes are equipped to handle this
situation, either.
If you must do this with Amber, then a standard debugger will be your
friend here. I remember when I was debugging a segfault with the EP code
in pmemd a few years back, I needed to use watch points to detect when and
where array overflows were occurring.
Also, if you expand these arrays too much, you may be running into a stack
overflow. One thing to try if you haven't already is to run "ulimit -s
unlimited" to make the default stack size unlimited. If I recall
correctly, these multi-dimensional arrays used for setting up and defining
the EP frames are all allocated on the stack, and tacking on extra
dimensions makes the size of the array increase exponentially. The more I
think about it, the more I think the segfault indicates an array overflow.
So either ulimit the stack, or allocate the temp arrays on the heap (just
remember to deallocate or you'll leak memory).
HTH,
Jason
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Mon Feb 29 2016 - 21:00:04 PST
