From: Axel Kohlmeyer (
Date: Wed May 13 2015 - 21:23:45 CDT

On Wed, May 13, 2015 at 9:35 PM, JeJoon Yeon <> wrote:
> Thanks Josh,
> I checked with the smaller size file, and it seems the each frames converted
> in right manner. Thanks. But I need a single xyz file of all converted
> frames, not the 100,000 number of converted single frame xyz files. It will
> cost heavy hard disk drive and long time to merge them to single xyz file.
> Are there anyway to print out the result as single xyz file?
> It is just for post processing and visualization. I want to "mask" some
> specific atoms with different colors and size (=different atoms) based on my
> criteria of interest, which make them easily recognized from animation or
> picture. In addition, I need to analyze those 'different type of Si atoms',
> such as RDF and angular distribution or others. So, this 'masking using
> alchemy' is a really good skill to analyze the result xyz. (Sometimes I even
> masked O atoms using 10 different atoms, based on their 10 different
> criteria = positions and vicinity to other specific atoms)
> I can do this work with fortran or python. However, sometimes I feel really
> convenient to use some options of VMD-tcl's 'atomselect' command, to target
> and differentiate the atoms of interest. Because it is easy to understand
> and straightforward to classify and convert the target atom with
> "atomselect". I don't need to write subroutines or more code lines. That is
> why I try to do this in VMD-tcl. If you could recommend me the other good
> and easy 'masking alchemy' tool for visualization, RDF and other analysis, I
> will happily accept your suggestion.

a *much* better way to deal with this from within VMD is to not change
properties that VMD expects to be immutable throughout the trajectory
but rather store them in one of the four "user" fields (user, user2,
user3, user4) which are atom properties (storing floating point
numbers for generality) that are per atom *and* per step. you can then
reference those user fields in atom selections (e.g. for using one of
two different representations) and in analysis scripts. this is the
"true VMD way" of thinking and doing things. changing atom identities
is at best an ugly hack.

using .xyz files should be avoided in general, because it is such an
extremely minimal file format where most information is lost. yet,
they have one major advantage. if you write a script that writes out
one .xyz file per loop (and uses a properly formatted file name, so
that the resulting names are properly ordered), then you can combine
those individual frames with a single "cat *.xyz >" command.

n.b.: when using assigned per-atom per-frame properties, you will have
to make sure that atom selections are updated in every step during
visualization and additional analysis. (there is checkbox for this in
the representations tab, for example, or in the g(r) GUI). normally,
this is not done to avoid the (sometimes significant) performance
impact of recomputing internal selections lists.


> Thank you
> 2015-05-13 20:00 GMT-04:00 Josh Vermaas <>:
>> My understanding of how VMD works says that it cannot be done in a single
>> xyz file. Name, type, etc, are not allowed to vary per frame (which works
>> for 99.99% of all use cases). You want to let the identity of the atoms
>> vary, which is weird, and needs a weird workaround by outputing each frame
>> into a separate file.
>> set a [atomselect top "index < 1338 and name Si and y>9 and within 5 of
>> atom O]
>> set t [atomselect top all]
>> for { set i 0 } { $i < [molinfo top get numframes] } { incr i } {
>> $a frame $i ; #changes the frame the selection will be based on
>> $a update ; #Rechecks that its selecting the right stuff
>> $a set name C
>> $a set type C
>> $a set element C
>> $t frame $i
>> $t writexyz frame$ ; #You will get a ton of individual frames where
>> the Si atoms will be renamed.
>> #Reset everything to Si for the next frame
>> $a set name Si
>> $a set type Si
>> $a set element Si
>> }
>> This will work, but I really wanna know why on earth this is a reasonable
>> thing to do. Silicon doesn't magically become carbon, which is why VMD
>> assumes that atom identities are static.
>> -Josh Vermaas
>> On 05/13/2015 06:48 PM, JeJoon Yeon wrote:
>> Yes, I want to do that "alchemy" using VMD

Dr. Axel Kohlmeyer
College of Science & Technology, Temple University, Philadelphia PA, USA
International Centre for Theoretical Physics, Trieste. Italy.