VMD-L Mailing List

From: Θωμας Ευαγγελιδης (te8624_at_mbg.duth.gr)
Date: Tue Aug 07 2007 - 15:52:50 CDT

Axel,
what you proposed was my first attempt and was extremely slow. Now I am working
with successive "within $R of protein" commands and reduce $R in each step (or
increase it if the number of atoms caught at first is higher that that of the
first frame). When the number of selected atoms becomes lower than that of
frame1 then I find the redundant atoms and calculate the distances for each of
them.
In fact the original concept was to create smaller dcd files from bigger ones
and facilitate their transfer, but at the moment the program produces pdb files
,one for each frame. I will check tommorow the plugins you indicated and come
with an answer later.
thanks for your help,
Thomas

Αρχικό μήνυμα από Axel Kohlmeyer <akohlmey_at_cmm.chem.upenn.edu>:

> On Tue, 7 Aug 2007, John Stone wrote:
>
> thomas,
>
> a few additional thoughts on your strategy.
> i think that writing out a seperate trajectory
> is not a good idea to begin with (VMD would not
> be able to handle it anyways) i would rather
> write a script that flags the atoms of interest
> with numbers in the 'user' field (this way you
> can even define different regions in one go).
>
> next, using atomselect via within and exwithin does
> waste a lot of computational effort and does not really
> provide what you need. what i suggest you do is to write
> a script that computes a distances between all pairs of
> atoms in the two selections: your protein(-segment) and
> the solvent around it (the latter restricted by a within
> type selection with some safety margin to not lose any
> atoms. then you can work your way through the resulting
> distance matrix and pick for each solvent atom the shortest
> distance to a protein atom and then pick the n shortest
> of those pairs. does that make sense?
>
> john,
> given the floating point weaknest of tcl and considering
> that one usually would run this over significantly large
> selection, having VMD create this distance matrix from
> within measure may be something for the TODO list. heck
> it is so simple, this would be a good project for somebody
> who is looking into writing his/her first piece of code
> to be included into VMD.
>
> cheers,
> axel.
>
> JS> Hi,
> JS> Is there some specific reason you need to create a DCD file?
> JS> One of the problems you're going to have with attempting to write
> JS> out a time-varying set of atoms to a DCD is that you'll lose track
> JS> of which atom indices are which. Why not just emit your own file format
> JS> and use just the atoms you care about? The DCD format really isn't
> JS> suited to holding a time-varying set of atoms, even with a big hammer ;-)
> JS>
> JS> The internal code in VMD does not calculate minimums nor maximums,
> JS> but merely tests candidate atoms to see if they meet the distance
> JS> selection criteria or not, for the currently active timestep.
> JS> Calculating min, max, quantiles, or the histogram of distance for
> JS> each atom over all timesteps would have to be done with your
> JS> own script presently. If there is sufficient interest in adding
> JS> a new "measure" subcommand for computing distances we could add one,
> JS> but I haven't had any requests for such a feature thus far.
> JS>
> JS> Cheers,
> JS> John Stone
> JS> vmd_at_ks.uiuc.edu
> JS>
>
> --
> =======================================================================
> Axel Kohlmeyer akohlmey_at_cmm.chem.upenn.edu http://www.cmm.upenn.edu
> Center for Molecular Modeling -- University of Pennsylvania
> Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
> tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425
> =======================================================================
> If you make something idiot-proof, the universe creates a better idiot.
>
>