On Tue, Oct 4, 2011 at 9:35 AM, George Tzotzos <gtzotzos.me.com> wrote:
> Jason,
>
> Thanks for the explanation. There's a second point that I'd like to clarify
> - if possible.
>
> My 10ns trajectory is made up of 5 individual trajectories of 2ns and 200
> frames each.
>
> If I use an input file such as the one below
>
> &general
> endframe=50, keep_files=2,
> /
> &nmode
> nmstartframe=5, nmendframe=45,
> nminterval=5, nmode_igb=1, nmode_istrng=0.1,
> /
>
> I get
>
> Calculations performed using 250 frames.
> |NMODE calculations performed using 9 frames.
>
> Setting the endframe=200 and
> nmstartframe=5, nmendframe=200,
> nminterval=10
>
> I get "Master thread is calculating normal modes for 5 frames".
>
> It's a bit esoteric for me the way the program works out the number of
> frames. Any explanation would be most welcome.
>
I agree. It applies "startframe, endframe, interval" to all of the
trajectories for the solvation free energy terms. That is, if you have 5
total trajectories, then your input file will draw the first 50 frames of
each one (for 250 total). Note that this will change with the new version
to behave more like you expect (it will draw the first 50 frames of the sum
of all trajectories, leading to 50 frames total).
For normal mode calculations, the nmstartframe, nmendframe, and nminterval
are applied to the _MMPBSA_complex.mdcrd (or _MMPBSA_complex.nc) file, since
it's assumed you'd only ever want to do nmode calculations on a subset of
the frames you do all other calculation types on. In this case, you
specified 5 to 45 via increments of 5 (9 frames total).
Afterwards, it says that the master thread is calculating normal modes for 5
frames, which tells me that you're using 2 processors. In this case, it
splits up the frames as evenly as possible, but you can't divide 9 frames
evenly between 2 processors, so the master gets 5 and the other one gets 4.
HTH,
Jason
> Regards
>
> George
>
>
> On Oct 3, 2011, at 9:47 PM, Jason Swails wrote:
>
> > On Mon, Oct 3, 2011 at 2:01 PM, George Tzotzos <gtzotzos.me.com> wrote:
> >
> >> I'm running MMPBSA.MPI on 12 processors. I'm trying to compute the
> entropy
> >> (nmode) of a protein/ligand complex from a 10ns trajectory (1000)
> frames.
> >>
> >> My entropy.in is:
> >>
> >> Input file for running entropy calculations using NMode
> >> &general
> >> endframe=1000, keep_files=2,
> >> /
> >> &nmode
> >> nmstartframe=10, nmendframe=990,
> >> nminterval=10, nmode_igb=1, nmode_istrng=0.1,
> >> /
> >>
> >>
> >> My estimate is that it'll take at least 10 hours to get results.
> >>
> >
> > Normal mode estimates are fairly unreliable. As expensive as the Hessian
> > construction/diagonalization is (we're helped by the fact that it's an
> > analytical Hessian, I think), in my experience the minimization takes
> > significantly longer. However, the number of steps required to minimize
> > within tolerable limits obviously depends on how close the structure is
> to a
> > minimum initially. MMPBSA.MPI's parallelization scheme is naive, though,
> > and assumes each will take the same amount of time, which hurts parallel
> > scaling for normal mode calcs in most cases.
> >
> >
> >>
> >> My question is whether increasing nminterval to 100 would compensate the
> >> accuracy of the calculation.
> >>
> >
> > Unlikely (though maybe increase it to 50 instead). Keep in mind that
> NMODE
> > frames are minimized, so in all likelihood many of your snapshots are
> very
> > structurally similar to others (if they reduce to the same local
> minimum).
> > A better approach may be to perform normal mode analysis on clustered
> > trajectories, and only take one snapshot from each cluster (or something
> > like that). You can always check existing literature to see what they've
> > done as well.
> >
> > HTH,
> > Jason
> >
> >
> >> Thanks in advance
> >>
> >> George
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> AMBER mailing list
> >> AMBER.ambermd.org
> >> http://lists.ambermd.org/mailman/listinfo/amber
> >>
> >
> >
> >
> > --
> > Jason M. Swails
> > Quantum Theory Project,
> > University of Florida
> > Ph.D. Candidate
> > 352-392-4032
> > _______________________________________________
> > 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
>
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
352-392-4032
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Oct 04 2011 - 07:00:03 PDT
