Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Alexander Stukowski

Pages: 1 2 [3] 4 5 ... 25
Support Forum / Re: Colouring of atoms
« on: April 10, 2018, 05:55:35 PM »
Yes, you can let OVITO read in per-atom color values. You will need three extra columns in your input file with the RGB components in the range [0,1].

Make sure these columns get mapped to the Color.R, Color.G and Color.B particle properties during file import. Depending on the file format you are using, it may be possible to add some metadata to the header of the input file so that this mapping happens automatically.

Support Forum / Re: How to visualize bonds?
« on: April 10, 2018, 02:08:40 PM »
You cannot hide certain bonds in OVITO 2.9, but in OVITO 3.0 you can. In the current development version of the program, the Select Type and the Delete Selected modifier operate on bonds too.

Support Forum / Re: Rendering Additional Particle Shapes
« on: April 06, 2018, 05:56:16 PM »

I'm sorry, but the current program version is not able to render more "exotic" particle shapes other then the standard shapes (sphere, ellipsoid, cube, cylinder, etc.).

In principle, you could implement a user-defined viewport overlay in Python script to render your polygonal particles using 2D drawing calls. But in my eyes that approach would not make much sense since you could achieve the same results without Ovito using pure Python and plotting frameworks such as matplotlib.

In general, I would be open to ideas and suggestions of how to extend Ovito in this direction and enable the visualisation of more complex particle shapes. But I myself am not really familiar with the corresponding simulation tools and common practices. It still seems to be a niche application with a small audience (compared to atomistic simulations, where particles are typically point-like). There are several open questions that need to be discussed in order to design a useful extension to Ovito, for instance:
  • What degree of freedom with respect to the particle shapes is desired (only regular convex polygons, arbitrary polygons, arbitrary polyhedra)?
  • How would the user specify the shape information?
  • Are there suitable file formats for transporting this information from the simulation codes to Ovito?
  • Is there a common ground between different simulation codes such as LAMMPS and HOOMD?

If you want, we can discuss these questions as you get yourself more familiar with the typical procedures (and visualisation needs) in this area of particle simulations.


You script accounts for the zoom factor of the viewport ("fov" value) and correctly computes the radius of the circle in screen space, but it currently does not take into account the position of the viewport camera. Since the viewport camera is in general not located at the origin, always drawing the circle at the center of the screen is wrong and leads to the apparent offset.

I suggest you make use of the project_point() and project_radius() helper functions that are given in the last script example on the doc page. The project_radius() function does what your own script is doing: it determines the correct radius in screen space given a radius in 3d space. The project_point() function allows you to determine the center of the circle in 2d screen space given a center point in 3d space.

Here is how the new code should look like:

Code: [Select]
    # Define geometry of circular boundary in screen space
    origin = (0,0,0)
    RingRadScaled = project_radius(origin, RingRad, painter, args)
    origin_screen = project_point(origin, painter, args)
    diameter = RingRadScaled*2
    #Draw circle on top
    rect = QRectF(origin_screen[0]-RingRadScaled, origin_screen[1]-RingRadScaled, diameter, diameter)

Support Forum / Re: Installation to get python script to work in gui
« on: April 05, 2018, 03:43:24 PM »
Here is a way to do it: Open the file ovito-3.0.0-dev155-x86_64/lib/python3.5/ in a text editor and change line 80 from




After this change, Ovito's Python interpreter should ignore your user package directory.

Support Forum / Re: Installation to get python script to work in gui
« on: April 05, 2018, 03:31:49 PM »
Ok, thanks. This shows that the problem is not related to the virtualenv. Rather the $HOME/.local/lib/python3.5/site-packages is among the default locations where Python interpreters search for modules and, unfortunately, it has a higher priority than Ovito's internal site package directory. Thus, Python modules like the PyQt5 module that are also present in your user directory shadow Ovito's internal modules.

For testing purposes, you can temporarily rename the /home/ppzmis/.local/lib/python3.5/site-packages/PyQt5/ directory to see if that solves the problem.

I am still trying to figure out a way to convince Ovito not to look in the user package directory at all.

Support Forum / Re: Installation to get python script to work in gui
« on: April 05, 2018, 03:12:22 PM »
Note that I asked you to run "bin/ovitos", not "bin/ovito" in the terminal. "ovito" is the graphical program version, "ovitos" is the interactive script interpreter, similar to "python". Please try to deactivate your virtual environment.  The following line from the error message indicates that the PyQt5 Python module was somehow imported from a directory outside of the Ovito installation:

ImportError: /home/ppzmis/Documents/SimData/ovito-3.0.0-dev155-x86_64/bin/../lib/ovito/ version `Qt_5.9' not found (required by /home/ppzmis/.local/lib/python3.5/site-packages/PyQt5/

Instead, this module should have been imported from the internal package directory:


I am not really familiar with how virtual environments work, but something in the environment must be convincing Ovito's interpreter to load modules from /home/ppzmis/.local/lib/python3.5/ instead of the internal package directory.

The file descriptor bug has been resolved by the upstream GSD developer and I have built a new development release of Ovito 3 (3.0.0-dev180), which is available on the download page.

In case you want to switch to the 3.x release already: The existing Python script should still work, but the backward compatibility layer may not be perfect. It is advisable to adapt the script to the new programming interface of Ovito 3.x. Here is a template:

Code: [Select]
from import import_file
from ovito.vis import *
from import *
import sys
import os

files = sys.argv[1:]
outdir = "output"

# Import data of first frame
pipeline = import_file(files[0])

# Configure visual appearance:
pipeline.source.particles['Position'].vis.radius = 1.0
pipeline.source.expect(SimulationCell).vis.line_width = 0.3

# Configure viewport:
vp = Viewport(type = Viewport.Type.Ortho)
vp.camera_dir = (1, 1, -1)

# Configure renderer:
renderer = TachyonRenderer(shadows = False)    # hi-res
#renderer = OpenGLRenderer()    # lo-res

# Rendering loop:
for i,infile in enumerate(files):
outfile = "%s/%s.png" % (outdir,os.path.basename(infile))
print("%s --> %s" % (infile,outfile))

vp.render_image(filename=outfile, size=(320, 240), renderer=renderer)

Support Forum / Re: Installation to get python script to work in gui
« on: April 05, 2018, 02:14:04 PM »

Ovito ships with its own Python 3.x interpreter and under normal circumstances it should work out of the box. However, the isolation from the system environment may not be perfect. In your case, there seems to be something unusual on your system that interferes with Ovito's Python interpreter. My current hypothesis is that there are some environment variables being picked up by the Ovito interpreter, making it access config files or packages from another Python interpreter on your system, which is incompatible. I would like to find out what it is.

Have you already tried running the "bin/ovitos" interpreter executable from the terminal? Perhaps if shows some additional log output on why the initialization fails. Then check the environment variables set on your system. Perhaps there are some Python related variables that you can clear first before executing Ovito or "ovitos". If possible, please post the output of the "printenv" terminal command here.


Support Forum / Re: problem with scipy package
« on: April 05, 2018, 02:02:15 PM »
I have built a new version of Ovito for Windows (3.0.0-dev180), which allows to install the scipy package using pip. You can find it on the Ovito download page.

Support Forum / Re: eliminate homogeneous deformation
« on: April 04, 2018, 10:46:10 PM »
Yes, correct. With this option active, the calculated atomic strain/displacement values will no longer include the affine deformation described by the simulation cell.

You may want to take a look at the updated doc page for the Atomic Strain modifier in Ovito 3.0.0 (development version) for a more detailed description:

Here, the Eliminate homogeneous cell deformation option has been replaced with a new option, which allows controlling the affine cell transformation in a more refined way, similar to the Displacement Vectors modifier in Ovito 2.9.0.

Support Forum / Re: eliminate homogeneous deformation
« on: April 04, 2018, 04:10:31 PM »
Dear Zhen,

Yes, I think you understood correctly. If this option is active, then the deformed cell including all particles is rescaled to match the shape of the reference cell. After that, the atomic strain is calculated.

And no, the macroscopic strain corresponding to this rescaling is not added to the computed per-particles strains. This would not make any sense in my eyes. The whole point of this option is to exclude any strain coming from the cell deformation. If you want that macroscopic strain to be included in the atomic strain tensors, then you should turn the option off.


Ok, great.

I have reported the problem to the upstream developers of the GSD I/O layer:

In the meantime, I also implemented a workaround for the bug in Ovito. Future versions of the program will no longer suffer from this issue.


Support Forum / Re: Reading Particle Orientation from GSD File
« on: April 03, 2018, 11:15:51 PM »
Yes, it's a pitfall: In "square" mode, the orientations are ignored.

In this mode, the particle squares always face toward the viewer. In other words, the camera orientation already dictates the orientation of the squares in the three-dimensional space. There is no way to combine this scheme with the orientations loaded from the GSD file.

I was able to reproduce the problem. Unfortunately, it turned out that the rearrangement of the for-loop doesn't solve the problem.

This issue seems to be caused by a bug in the GSD library, which is used by OVITO to read GSD simulation files (produced by the HOOMD code). Even though you are loading files with a different format, OVITO still tries to open them with the GSD I/O functions as part of the format auto-detection routine. Apparently, the GSD I/O function doesn't close the file handle properly in case it is not a GSD file.

I will try to update the copy of the GSD library shipping with Ovito to resolve this issue. In the meantime, you can only work around the problem by hacking the FileSource.load() Python function of Ovito. For that, open the file ovito-2.9.0-x86_64/lib/ovito/plugins/python/ovito/io/ in a text editor and go to line 143. Replace the following three lines

Code: [Select]
    importer = FileImporter.autodetect_format(self.dataset, location)
    if not importer:
        raise RuntimeError("Could not detect the file format. The format might not be supported.")

with the this code

Code: [Select]
    importer = self.importer

This disables the format auto-detection and Ovito will assume that subsequent files always have the same format as the file loaded initially. Note that you need to work with the rearranged for-loop I posted earlier.

Pages: 1 2 [3] 4 5 ... 25