From: Nifeng Guo hui (nifenggaohui_at_gmail.com)
Date: Tue Nov 04 2014 - 10:58:23 CST

Hey,
After I paly with RDF Plugin, I am still unsure about how properly use it.
First, "it suddenly becomes zero, because you run out of data. under
consideration
of minimum image conventions you usually are only able to compute the g(r)
up to half the shortest box length. " Does this mean it is not appropriate
to treat all the 36 amino acids as one whole. Second, if my conclusion that
it is not appropriate to treat all the 36 amino acids an a ball is
validated, then does this explains why the RDF always increase from
starting until a suddenly dropped point as shown in my first plot. Third,
then what is the feature of "Use PBC" in the the Plugin?
Thanks.
Peng

2014-11-03 15:49 GMT-06:00 Axel Kohlmeyer <akohlmey_at_gmail.com>:

> On Mon, Nov 3, 2014 at 4:29 PM, Nifeng Guo hui <nifenggaohui_at_gmail.com>
> wrote:
> > Hello, Axel and Tim
> >
> > I analyze RDF in production run of 10 ns. (After energy minimization and
> > NVT, NPT Equilibration simulation.) In my understanding of RDF, after
> > certain distance from the reference point, the particles will distribute
> > evenly which means water molecules are not attracted or repelled by the
> > protein molecule. Thus, the water density will appear as a horizontal
> line.
> > However, it's hard to explain that RDF increases to 28 anstrom and
> suddenly
> > becomes zero.
>
> it suddenly becomes zero, because you run out of data. under
> consideration of minimum image conventions you usually are only able
> to compute the g(r) up to half the shortest box length. the g(r)
> calculation in VMD uses a smarter normalization function that can go
> beyond that, with the maximum being half the length of the diagonal
> through the box (with limited statistical accuracy, due to the
> shrinking normalization volume).
>
> > Now, I change the code in "Section 2" as "name OH". The plot seems like
> > understandable. So does this mean the code for "water" in "Section 2" is
> > incorrect? I attach the new plot. Please take a look at it. Thanks.
>
> your question has nothing to do with the g(r) calculation but with
> VMD's atom selection language. the g(r) plugin will compute what you
> ask it to compute. whether you select the right group(s) of atoms for
> your purpose is something that you have to validate independently.
> when using macros like "water", you have to make certain, that your
> input conforms to the underlying heuristics. this is not the g(r)'s
> plugin's job, but yours. from the point of the plugin, there is no
> "right" or "wrong". it just uses your input. please revert to the VMD
> user's guide for details.
>
> axel.
>
>
> >
> > Peng
> >
> > 2014-11-03 0:58 GMT-06:00 Axel Kohlmeyer <akohlmey_at_gmail.com>:
> >
> >> On Sun, Nov 2, 2014 at 11:19 PM, Nifeng Guo hui <nifenggaohui_at_gmail.com
> >
> >> wrote:
> >> > Hi Tim,
> >> > Thanks for the explanation. Now I follow your instruction and plot it
> >> > again.
> >> > It still does not make sense. I use period boundary condition to
> >> > simulate in
> >>
> >> well, the problem is very likely not with the g(r) plugin but with
> >> your expectations. you most certainly don't have a homogeneous
> >> monoatomic fluid as your system, which will lead to the graphs more
> >> commonly seen as examples for a g(r). please review the definition of
> >> the g(r) (i.e. what the graph means, not what it typically looks like)
> >> and compare it to the structure you are feeding into VMD. i am very
> >> confident that what you see as a graph is correct. it would be
> >> consistent with a two component system that is mostly separated.
> >>
> >> > a cubic box with dimension 50. The molecule size is
> >> > cellBasisVector1 48.12900161743164 0 0
> >> > cellBasisVector2 0 42.979000091552734 0
> >> > cellBasisVector3 0 0 43.9109992980957
> >> > cellOrigin 0.5063787698745728 1.1608952283859253 0.11323882639408112--001a1135e3180270e405070b5fcf--