lloyd riggs wrote:
Dear Justin,
Dont panic.
Why would I panic? It's not my data are strange ;)
1) there in cyclic happening at 1/4 the entire run but offset by 2-6
picosecounds between runs.
2) There calculated PMF but the data comes from the origional pullf.xvg files
generated if I look at each point (same thing a - or low pullf point.)
-This is precluding the first 2 picosecounds of a 4 ns pulled run as done by
another group with similar (90% identical) protein sets (published).
-also in a few after the peak change in energy is reached (around 3.8 ns), I
do see fluctuations which I expect due to more free movements.
-I also calculated everything with a single histogram analysis, then did
statistics using ploting sofware (qti) for all runs together. The errors are
the same in either case.
-In the end the finalized data (means at any point overall, distances,
etc...) are all the same and fit values. If I exclude the data points I get
smooth curves. If I include them the single point from one of 11 or 1 of 10
runs just seems to effect the error analysis (STD deviation, Standard error)
but affects the mean(s) very little. In the end the mean is all that anyone
cares about, along with other associated analysis, but I woundered.
A mean is only as good as the error associated with it. No error estimate, no
confidence in the value.
-The errors in half the case ( say around 30 points in all across 22,000 or
20,000 points) are just the mean of the previous and next point but with a
negative sign? In the other half they are always numbers very close to zero
(ex: 0.002484890) with the prior or next point around say 30-40.
-The models dont show any wierdness if I print out the pdb for those frames
in VMD, so do not know where the error is. I dont know if its a spring
effect, which I assume not if the force is constant, as the pull force is
artificial, but I could see it causing a spring effect if the protein(s) one
tries to pull apart are strongly bound together (ie say force equivalent in
some way to the pull force applied).
This sounds to me like a periodicity issue. Were these runs conducted with
"pull_geometry = distance"? If so, were the COM distances always less than half
of the box vector along the restrained dimension(s)? Are you running with NPT?
If the answer to any or all of these is "yes," then you could have a problem
with the pull algorithm failing due to periodicity. The sign changes might
account for that. You wouldn't see any weird periodic jumps, but the size of
the box and the COM distance at the instance of the sign/magnitude change would
coincide.
-Justin
--
========================================
Justin A. Lemkul
Ph.D. Candidate
ICTAS Doctoral Scholar
MILES-IGERT Trainee
Department of Biochemistry
Virginia Tech
Blacksburg, VA
jalemkul[at]vt.edu | (540) 231-9080
http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin
========================================
--
gmx-users mailing list gmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at
http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
