Forum Navigation
You need to log in to create posts and topics.

Atom type with Lammps dump files

Dear all,

using the Ovito 2.9.0 on MacOS Catalina I have some issues visualising Lammps dump-files. They open without any problem, but when I show the time-series, the atom-types are changing during the simulation. I use the "element" handle to identify what atom types are in each of the frames. Visualising 500 frames goes mostly well, but from time to time some of the atoms change identity from one frame to the next. Is this some known issue, and what would be the best way to prevent this from happening?

Dear Sondre,

could you please show me the lammps command you used to write your dump files or upload the header of one of these files. Then I can look further into this.


I dump the files using this:

dump trjfile all custom 1000 dump.lammpstrj id mol type element x y z ix iy iz
dump_modify trjfile element C C C C C C C C C O C C C O C C C C C C O C C C O H H H H H H H H H H H H H H H H H H H H H H H H


I would estimate that 80%-90% of the frames are displayed correctly. I could also upload a trajectory, but that would take some time, as they tend to be quite large.

As far as I remember OVITO 2.9.0 did have difficulties with dump file trajectories that use named atom types ("C", "H", "O", ...) instead of numeric types (1,2,3,...). Note that LAMMPS tends to randomly shuffle the storage order of atoms from frame to frame. Thus, in one frame an "H" atom might be first in the atoms list written to the dump file, and at a later time a "C" might be first, for example. OVITO maps the names types back to numeric types during import, which might go wrong if the order in which named atom types appear for the first time in the list changes from frame to frame.

The problem should go away if you use the "dump_modify sort id" command in LAMMPS so that the atom ordering remains stable over all frames of the trajectory. Alternatively, you can switch to OVITO 3.0.0-dev. It should do better this case.

Thanks, using the "dump_modify sort id" correction helped to make Ovito 2.9.0 work as expected. I did a test with Ovito 3.0.0-dev, and that version was not able to read the dump files directly using named atom types at all. Using:

dump_modify trjfile element 6 6 6 6 6 6 6 6 6 8 6 ...

seems to work correctly. It seems like Ovito does not use a nice colour palette using that method though, but that can easily be adjusted.




I did a test with Ovito 3.0.0-dev, and that version was not able to read the dump files directly using named atom types at all

which developer version are you using? I was able to import some test dump file which looks like the following without any problems:

0.0 50.0
0.0 50.0
0.0 50.0
ITEM: ATOMS x y z type id
26.4915 24.8711 24.8658 C 1
24.1392 23.6812 28.5037 O 2
31.6882 24.3238 25.5354 O 3
33.1067 27.224 27.7948 H 4
33.2008 27.022 24.0426 H 5

Maybe I'm missing something but could you motivate for me why you need that extra dump_modify at all? I thought the element keyword is only valid for dump cfg, xyz, and image styles not custom?

dump_modify trjfile element C C C C C C C C C O C C C O C C C C C C O C C C O H H H H H H H H H H H H H H H H H H H H H H H H

This command suggests, that you have defined 49 different particle types and try to condense them into 3, i.e. "C", "O" and "H". Is that really the case? Anyways, I just wanted to make sure that I understand the issue correctly.


I'm currently using 3.0.0-dev591 on MacOS 10.15.1.

Using the sample you pasted here, I get the same thing, as well, so it seems to read the "type" attribute correctly.

The reason I have ended up with this way of dumping information is that the molecules used are long organic chains, with several different states of carbon, oxygen and nitrogen. Though, I might not have 49 truly independent sites, it is easier to just prepare the system that way. The "type" attribute stores this information, and allow me to use the dump-files to both dump data for visualisation and for post-processing some properties not easily calculated by lammps directly. From my point of view, using the  "element" attribute, seems like the perfect way to convey the atomic identity of the various atoms to Ovito. If there are better ways of doing this, I'm all ears.



Thank you for the detailed explanation, Sondre.
I'm wondering, is the original particle type information (i.e. the set of particle types from 1-49) something you would like to preserve when you import your datasets into OVITO? If that's the case, e.g. for further analysis,  then you could dump the snapshots with the original numeric id's of the particle types and set the chemical identities after importing the data into OVITO.
Particle types in OVITO can both have a numeric id and a name. These settings can be found in the Data source panel. Simply open the Particle Types settings and click on the individual types (see attached screenshot) and edit their names. Of course that's not really a convenient workflow if you have a large set of particle types, but there is a workaround: After file import into the GUI it should be possible to run the following macroscript through File ->Run python script:

import ovito
data = ovito.scene.pipelines[0]
for type in data.particles_.particle_types_.types:
        if > 24:
   = "H"
        elif == 10 or == 14 or == 21 or == 24:
   = "O"

which preserves the original particle type ids but also associates a chemical identity with each numerical type.

By the way, you can control the color and radius of each particle type in a similar manner through type.color and type.radius.

If you don't need the original particle types anymore, though, the way you're doing it now is definitely more hassle free, I agree.



Uploaded files:
  • Particle-Types.png