Just a small clarification.
The part "In this case, you specified 5 to 45 via increments of 5 (9 frames total)" is well understood.
However, I was referring to a separate run for which I set the nmstartframe=5 and the nmendframe=200 with nminterval=10.
I was expecting that the calculation would be performed on 40 frames instead of the 5 that is reported. This is what is confusing me.
A second broader question is whether it is legitimate to draw the first 50 frames for each of the 5 trajectories for the calculation. Doesn't this give biased sampling?
Thanks for the patience and explanations
George
On Oct 4, 2011, at 3:47 PM, Jason Swails wrote:
> 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
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Oct 04 2011 - 07:30:03 PDT
