Centering XTC Trajectory in OVITO

Hi, I am outputting XTC files with LAMMPS with an unconventional conversion factor of 100 (ie the correct transformation back to float of all coordinates is dividing by 100). The box dimensions are not constant.
When I open them in OVITO the box starts at the origin and extends in the positive axis directions. However I would like to center the box on the origin.
With affine transformations I can rescale both box and coordinates, and then I can translate by a constant value, however the box dimensions are not constant.
I would rather not change the file format since I found that other formats are less compressed or slower to seek on OVITO (for instance tried netcdf with the same float->integer compression, and while ovito was faster at opening, it was much slower at seeking through the file).
Is there any other modifier I can use to center a simulation box with changing dimensions? Perhaps using the python API?


You can dynamically recenter the simulation box using the following Python modifier function:

from import *
from ovito.modifiers import *
import numpy as np

def modify(frame, data):
    cell_matrix = np.array(data.cell)
    cell_matrix[:,3] =, -0.5, -0.5), data.cell[:,:3])
    data.apply(AffineTransformationModifier(relative_mode=False, target_cell=cell_matrix))

The function employs the AffineTransformationModifier as a subroutine and applies a dynamically computed translation.

I have noticed too that the XTC file format stores strictly positive atomic coordinates, i.e., the system is not centered at the coordinate origin. This convention seems not very useful. Maybe it makes sense to add a user option to the XTC file reader in OVITO which directly performs the centering of the dataset to the coordinate origin. Then a translation of the system within OVITO wouldn’t be necessary anymore. What do you think?

Just being curious: I am wondering what you mean with “netcdf with the same float->integer compression”. Is this a special option of the LAMMPS dump netcdf command? I am trying to understand why seeking in such files is slower than expected.


Hi, thanks for the quick response. I just tested the script, it works via the conda python module. Sadly I don’t have the pro version, so I can’t use it on desktop.
I think it makes sense to add this option to the XTC file reader.

Regarding netcdf: lammps indeed does not use any compression option on the output of the ‘dump netcdf’ command. I applied compression in a post-processing step via the options listed in netcdf4 (the least_significant_digit keyword here ). I also experimented with using chunk sizes. However while opening a NetCDF file was instant compared to a XTC file, seeking was much slower. I can do a better job of documenting this (sample files, the code used to generate them) , but working on it is akin to supporting a very specific case, compared to centering the XTC files.

Thanks for the additional info. I can imagine that turning on compression of NetCDF files interferes with the random access capability of the format, making jumps between trajectory frames much slower. But this not really my concern right now, I agree.

When opening an XTC trajectory, OVITO parses the entire file from beginning to end to index all frames and determine their byte offsets in the file. Maybe there is a way to accelerate this step, I need to do some more research on the XTC format to find out.

Now regarding the centering of the simulation box: I’ve extended the XTC, GRO, PDB(x), mmCIF and CIF file readers of OVITO to provide a new user option that automatically centers the simulation box and its contents on the coordinate origin. This option is turned on by default for the XTC and GRO file readers.

Here are development builds of OVITO Basic and OVITO Pro. Please give them a try and check if the new centering option solves your problem. Let me know if you encounter any issues. Thanks.

Re. NetCDF: I was hoping that by using the simplest compression analogous to the one used by XTC it would work as well as XTC does.
Re. initial parsing of XTC file: the MDTraj python package does something like caching/extrapolating byte offsets from the first frame, although I have seen it fail with files whose last frame was partially written.

I just tested the development build of OVITO Basic with my XTC files.
The XTC file format stores the box as just three vectors, or three lengths in case of a rectangular box, and has no information regarding box size. I should have read your reply with more care; the atom coordinates can be negative; for instance to encode the image coordinates of the atom ( see , specifically the ‘unwrapped’ option ), but in my case they also are a mix of negative and positive at step 0 (no atom outside the lammps-defined box) because the lammps box has its center at (0,0,0).

I had before applied a scaling modifier (to correct the default /1000 to /100 scaling), then ComputeProperty to do ‘Position.X+CellSize.X/2’ for X,Y,Z; then a Wrap at Periodic Boundaries; this last step failed because while the positions were correct, the cell origin remained uncorrected.
With the new center box option, the cell gets corrected at the start, and the modifiers I described do the rest.

In short, the new option works perfectly for XTC files with coordinates taken from a box with origin at (0,0,0), while for my specific case with coordinates taken from a box centered at (0,0,0), I can combine the new option with existing modifiers in OVITO Basic to make it work. Thanks!