Dear developers,
Big fan of LAMMPS here :).
I use VMD to visualize my output, because I can take the latest LAMMPS dump format (generated by a dump custom) and directly feed it to VMD automagically. I can use the same file to perform post-run analysis. But, the actual element information is missing, since all the types dumped are numeric.
I see there exists a “dump_modify element” option that works only for CFG files, for the specific purpose of Atomeye being able to render with element information.
Could this feature be extended to custom dumps as well?
Dear developers,
Big fan of LAMMPS here :).
I use VMD to visualize my output, because I can take the latest LAMMPS
dump format (generated by a dump custom) and directly feed it to VMD
automagically. I can use the same file to perform post-run analysis.
But, the actual element information is missing, since all the types
dumped are numeric.
I see there exists a "dump_modify element" option that works only for
CFG files, for the specific purpose of Atomeye being able to render
with element information.
Could this feature be extended to custom dumps as well?
in principle, yes. and it should be done similarly for .xyz dumps.
this would not help you a bit unless VMD is modified to recognized
that extension. the current plugin does not (i should know 
).
i currently don't have the time to implement this (and that won't
change for a quite a bit), but i'd happily integrate and test
contributed changes to both LAMMPS and VMD to make this work.
the easiest workaround would be to include the script in
tools/lmp2vmd/lmpname2vmd.tcl into your .vmdrc file and
then type
lmptypetoname top {Name1 Name2 Name3 Name4}
at the vmd command prompt. this will set the atom names.
if you want to set "type" or "element" you'll have to modify
the script or create a variant.
to avoid having to do this all the time, you can just save the
resulting information into a .psf file with
animate write psf mysystem.psf
and then load this psf file together with the lammps dump files
in the future. the lammps dump files will not contain that information
and thus it will not be overwritten.
also, you could use the fact that the parser for lammps data
files in the topotools plugin in VMD has an extension that
allows to assign test labels to atoms and residues: those labels
can follow the normal data file as comments. to see how this
works, just load some .pdb file into VMD and save it to a
data file with: topo writelammpsdata data.mysystem full
(the full is optional and can be changed to whatever atom_style
you use, for as long as topotools supports it).
finally the latest VMD topotools beta test version (available from:
http://sites.google.com/site/akohlmey/software/topotools )
has a function "topo guessatom" that allows to guess missing
data through some heuristics. for example.
topo guessatom element mass
will try to guess the atom element name from its mass
(does not work 100% due to idiosyncrasies in the PSE).
this of course requires that the mass is known (which
should work when reading a proper topology file first.
cheers,
axel.
Dear Axel,
Thank you very much for the prompt response! 
I booted up my vmd to find your name on the splash screen. Indeed you would be the resident expert 
Indeed, there is a .tcl script, which I actually used to use in some time past. I stopped bothering, while I knew I could add it to a .vmdrc file, I just issued a command to perform replacement before loading into vmd. Here is the command I used to generate the second of the attached files.
sed “s/ 1 / C /;s/ 2 / Ar /” sample.lammpstrj > sample_withAtomType.lammpstrj
And that satisfies my needs of getting appropriate colors chosen automagically by VMD 1.8.7, also allowing me to make selections via “name Ar” instead of “name 2” (since I always would forget what 2 was since it’s different between my simulations).
The files I have provided (~250 kB total) represent the initial configuration for argon gas inside a CNT. I probably should have chosen one simulation that had water in it, since the choice of color in this example isn’t obvious. For water simulations in which I do not sed the atom types/names in or use lmpname2vmd.tcl, it’s very obvious that it chooses colors that aren’t red and white for O and H. Looking at the (very short) source code for lmpname2vmd.tcl, I fail to understand why your approach and my sed approach are different.
I completely forgot about topotools. Looks cool, I’m going to have to play with it.
And worry not! After looking at the at the source code for the dump_modify element for cfg files, I think I shall try my hand at extending this to dump custom. I can’t say that extending it for XYZ is a high priority for me, since I don’t use that file format anymore, but I’ll check it out.
Thank you once again!
sample.lammpstrj (113 KB)
sample_withAtomType.lammpstrj (113 KB)
Indeed, there is a .tcl script, which I actually used to use in some time
past. I stopped bothering, while I knew I could add it to a .vmdrc file, I
just issued a command to perform replacement before loading into vmd. Here
is the command I used to generate the second of the attached files.
sed "s/ 1 / C /;s/ 2 / Ar /" sample.lammpstrj >
sample_withAtomType.lammpstrj
this is only convenient, if you have to deal with small files.
also, it creates a lammps dump file that is non-standard.
you pretty much got lucky that it works at all (or that i was
very conservative and wrote a permissive parser, when i
rewrote that lammps molfile plugin).
And that satisfies my needs of getting appropriate colors chosen
automagically by VMD 1.8.7, also allowing me to make selections via "name
Ar" instead of "name 2" (since I always would forget what 2 was since it's
different between my simulations)
this is why a tend to create a .psf file with the namd/residue label mapping
and then use .dcd or .xtc dump files. those dumps are much more
compact and load much faster. for the size systems and length of simulations
.that we typically do, this is essential.
[...]
colors that aren't red and white for O and H. Looking at the (very short)
source code for lmpname2vmd.tcl, I fail to understand why your approach and
my sed approach are different.
my approach only changes the data stored internally in vmd and does
not require significant extra storage. if you only run sed on a single frame,
then it is not so much of a problem. if you do it on the full trajectory, your
approach is wasteful.
I completely forgot about topotools. Looks cool, I'm going to have to play
with it.
And worry not! After looking at the at the source code for the dump_modify
element for cfg files, I think I shall try my hand at extending this to dump
custom. I can't say that extending it for XYZ is a high priority for me,
since I don't use that file format anymore, but I'll check it out.
please make sure you give it a new description label when you change
the dump file output, so that tools can now it is a string instead of a number.
cheers,
axel.
If you are asking for a dump modify option that writes out
dump custom format files with element names, e.g. H, instead
of the atom type, then there are no plans to do this. That
would be changing the format of the dump custom file from
all numeric atom columns, to a mix of numeric/text. Which
would break various post-processing tools. CFG files
are different b/c they include the text in their format.
I would view what you ask as a post-processing question - i.e.
could a tool(s) change the format of a dump custom file
into something more suitable for VMD, by adding element
names, etc. This could be done in Pizza.py or other
tools.
Steve