Hello Maxim,
The extra points code in mdgx can handle any arbitrary number. However,
the way you'll specify the virtual sites is not via the standard tleap
instructions but instead by producing your own file containing namelists of
what you want to add and then including this at run time. (You will not get
a topology with the extra points, nor a trajectory containing them--rather,
mdgx will know where to place them at each time step, and just print
coordinates for the "official" atoms). mdgx will scale to eight CPUs at a
speed competitive with CPU-pmemd, and in fact with denser systems (TIP5P,
for example, and perhaps your case with many virtual sites, if they are
present throughout the system) mdgx will overtake CPU-pmemd in speed.
However, it's still not highly parallel, and of course it's nowhere near
the GPU-pmemd. But, if you just want to see what something would look like
for a few ns, mdgx is a good solution.
Maybe if we can take this offline, you can help me understand how to
specify extra points to add to Amber residue libraries so that I can get
objects with a few off-site charges, and I can help you understand more of
the mdgx implementation (the AmberTools manual also contains a decent
example).
Dave
On Mon, Feb 29, 2016 at 11:34 PM, Jason Swails <jason.swails.gmail.com>
wrote:
> 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
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Mon Feb 29 2016 - 21:30:04 PST
