From: Peter Freddolino (petefred_at_ks.uiuc.edu)
Date: Tue Aug 31 2010 - 19:42:59 CDT
Hi Elia,
On 08/31/2010 07:00 PM, Zumot, Elia Nabil wrote:
> Hi again,
>
> In order to "trick" NAMD, and to avoid having to wait about 30 minutes
> to calculate the interaction between the substrate and protein (dcd
> file of just 50 frames)
This is extremely strange. For this and several other problems reported
below, it would be useful for you to run namdenergy in debug mode, which
will give you access to all of the actual input files used in the namd
runs. For this case, try running in debug mode and then check how long
it takes to run the namd command on a single frame.
> upon using the "update selections every frame" I have used "protein
> and same residue as pbwithin 200 of substrate" in the second selection
> box with "update selections" off.
What exactly are you trying to accomplish here? If you use that
selection you may as well just use "protein", which is simpler. I
thought you had said before that you just wanted the interaction energy
of residues within 5 A of the ligand.
> This way I get to include the periodic boundary conditions without
> having to update the selection every frame.
> Here I get the same results of interaction energy regardless of
> whether "update selections every frame" is clicked on/off.
>
> However, I still get some very high interaction energy values (up to
> 1'000'000) when the substrate but not the protein crosses the periodic
> cell boundry (and these values are the same regardless of whether the
> selections are updated or not).
You should carefully examine the files generated by running in debug
mode to see if the parameters make sense and the coordinates in the dcd
seem appropriate. It the excessive energy from vdw interactions? My
guess is that there's something odd going on with your boundary
conditions, but you should be able to spot that pretty easily by
inspecting the temporary files.
> And is there a way for running interaction energy calculation with the
> selections updated without having to generate a pdb/dcd file for every
> frame as NAMDEnergy does (which consumes a lot of time)?
Not with namdenergy... the pairinteractions in namd must be set upon
startup.
However, for your limited purposes you may be able to use the measure
energy command instead (see the vmd documentation), which supports a
subset of features from namd but should be fine for short range
interactions and will let you get much more rapid selection updates.
Best,
Peter
>
> Thanks in advance
>
> Elia
>
> ------------------------------------------------------------------------
> *From:* Peter Freddolino [petefred_at_ks.uiuc.edu]
> *Sent:* Monday, August 23, 2010 7:58 PM
> *To:* Zumot, Elia Nabil
> *Cc:* namd-l_at_ks.uiuc.edu
> *Subject:* Re: namd-l: possible bug with NAMD Energy plugin
>
> Hi Elia,
> periodic boundary conditions will only be taken into account if you
> use pbwithin instead of within in your atom selection text -- this is
> simply the proper way to use the vmd atom selection language. Please
> let me know if you still have difficulty after fixing your atom
> selection text.
> Best,
> Peter
>
> On 08/23/2010 04:19 PM, Zumot, Elia Nabil wrote:
>> Hi all,
>>
>> I'm calculating the energy of interaction between the ubstrate and
>> protein residues within a radius of 5A around it under PBC in an NPT
>> ensemble using the NAMD-Energy plugin.
>> The protein together with the substrate move and cross the boundry
>> only they do not do so at the same time and at the same frames so
>> at certain frames the protein could be at one end of the cell and the
>> substrate on the other even though the substrate is still bound at
>> the core of the protein.
>>
>> The problem arises at these points where I get an energy of
>> interaction that is equal to 0.0. Is this a bug with the pluging or
>> is there a way around it?
>>
>> I have the "PME" and "update selection every frame" options clicked
>> when I carry out the calculation and VMD/NAMD are the latest versions.
>>
>> Thank you in advance
>>
>> Elia
>>
This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:56:06 CST