I would heartily recommend understanding just why max14 needs increasing, by
how much, and increase it only when it needs increasing. One reason that
sander is slow is that the data structures are oversized and the necessary
data for a calculation is scattered all over the place. I try in pmemd to
understand the exact storage requirement, and get data organized in such a
manner as to increase cache utilization (this is the sort of thing most
folks find to be too big a pain; that's fine if you don't really care about
performance). Bottom line here for me - I would ultimately, in pmemd, want
to understand the necessary sizes of the data. Point two - I also would not
arbitrarily increase the "symbol space" with unnecessary symbols. Point
three - has anyone tried running Lachele's stuff with pmemd - a patched
version of pmemd 10? I would like to know how it does. If it segfaults, I
may be able to figure out why. I have not wanted to get embroiled in this
stuff, as I am embroiled in other stuff, but if someone wants to shoot me a
copy of the runfiles, I will see what it does in pmemd.
Best Regards - Bob
----- Original Message -----
From: "David A. Case" <case.biomaps.rutgers.edu>
To: <amber-developers.scripps.edu>
Sent: Tuesday, November 11, 2008 7:08 AM
Subject: Re: amber-developers: Extra Points Calculation
> On Mon, Nov 10, 2008, Volodymyr Babin wrote:
>>
>> please see the patch for cvs sander attached. Does it
>> look harmless enough to be committed?
>
> Does it solve Lachele's problem (the sucrose_EP test case)? As far as I
> can
> see, that example does not include any "LP" atoms, and I don't think we
> should
> be expanding to that...my recollection was that "LP" atoms (still found in
> some old parameter/topology files) were *not* treated as extra points, but
> as
> real atoms.
>
> I tried to expand the size of max14 (not as much as you did), and was
> still
> getting segfaults on Lachele's example. But it is great if your fix
> works.
>
> ...dac
>
>
Received on Fri Dec 05 2008 - 14:25:09 PST
