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 ... 15 16 [17] 18
Thanks for the helpful bug report.

I can confirm that there was an issue. It will be gone in the next program release, a fix has been implemented in the source code:

Support Forum / Re: Ovito segmentation fault
« on: March 09, 2017, 09:17:50 AM »
The macOS version of Ovito 2.8.2 uses Qt 5.7.1.

Support Forum / Re: Ovito segmentation fault
« on: March 08, 2017, 11:44:32 PM »
The stack trace you posted indicates that OVITO crashed while doing... basically nothing. That is very strange.

I checked the scene file that you posted (also on a macOS system). First, everything worked normally. But then I switched to another application, and minutes later OVITO spontaneously crashed while I was working in the other program.

I currently have no explanation for this and I haven't seen this before. So far I wasn't able to reproduce the crash again, I only observed this one occurrence. That means it happens only very infrequently (or it requires some very specific type of user interaction to trigger the crash).

I will keep an eye on this. Let me know if you are able to narrow it down, perhaps to a specific user action or element in the scene that leads to the crash.

Support Forum / Re: To select specific types of point defects
« on: March 07, 2017, 10:05:54 PM »

That code fragment looks good to me (except that you should use ">" instead of ">=" to select sites with more than one atom). Note that referencing the 'Occpancy' particle property in the selection expression only works if there is a WignerSeitzAnalysisModifier preceding the SelectExpressionModifier in the pipeline. I assume you have made sure it's there.

Please post the full error message and perhaps attach the complete Python script if you need further help.

Hi Christophe,

Let me start by giving you what I consider a better solution to your problem. To remove all particles that don't belong to any cluster, i.e. which have Cluster==0, you don't need to write a custom modifier. You can simply use the SelectExpressionModifier and the DeleteSelectedParticlesModifier modifiers to do this:
Code: [Select]
node.modifiers.append(SelectExpressionModifier(expression = 'Cluster==0'))

That being said, let me discuss what is wrong with your user-defined modifier function. The statement cluster_ID=cluster_ID[cluster_ID>0] produces a Numpy array that is shorter than the original input array. You try to assign this reduced array back to the output particle property, which fails. That is because OVITO requires all particle property arrays to have an identical length. This length, which is (must be) always equal to DataCollection.number_of_particles defines how many particles exist. Currently, the Python interface of OVITO doesn't allow you to change this number independently.

The only way to effectively reduce the number of existing particles and, as a consequence, the length of all particle property arrays (not just the Cluster property) is via the DeleteSelectedParticlesModifier. It takes care of some important things behind the scenes to keep everything in a consistent state. For example, it also removes bonds that are connected to particles being deleted. In other words, your custom modifier function can only choose which particles to delete by setting the Selection property, but it cannot actually delete them:
Code: [Select]

def SelectClusterVacancies(frame, input, output):
    cluster_ID = input.particle_properties['Cluster'].array
    sel_property = output.create_particle_property(ParticleProperty.Type.Selection)
    sel_property.marray[:] = (cluster_ID > 0)

node.modifiers.append(PythonScriptModifier(function = SelectClusterVacancies))

But as I said before, our custom modifier function has now become just a fancy version of the built-in SelectExpressionModifier modifier. So there is no point in writing it.

Hi Kristian,

The four components of the orientation quaternion computed by PTM need to be mapped to the three RGB color components for each atom. Peter Larsen, the author of the paper you referred to, gave me a Python script for this calculation (which involves mapping the quaternion to Rodrigues space). I developed a Python modifier function for OVITO from this, which you can put into the data pipeline after you calculated the per-atom orientations using the PTM modifier:

Code: [Select]
from import *
import math
import numpy as np
def elementwise_multiplication(a, b):
    a[:,0] = np.multiply(a[:,0], b)
    a[:,1] = np.multiply(a[:,1], b)
    a[:,2] = np.multiply(a[:,2], b)
def project_quaternions_into_rodrigues_space(qs):
    if len(qs.shape) != 2:
        raise Exception("qs must be a 2-dimensional array")
    if qs.shape[1] != 4:
        raise Exception("qs must be a n x 4 dimensional array")
    rs = np.copy(qs[:,:3])
    elementwise_multiplication(rs, 1 / qs[:,3])
    return rs
def quaternions_to_colors(qs):
    if len(qs.shape) != 2:
        raise Exception("qs must be a 2-dimensional array")
    if qs.shape[1] != 4:
        raise Exception("qs must be a n x 4 dimensional array")
    m1 = math.radians(62.8)
    m0 = -m1
    rs = project_quaternions_into_rodrigues_space(qs)
    rr = np.linalg.norm(rs, axis=1)
    rr = np.maximum(rr, 1E-9)    #hack
    elementwise_multiplication(rs, 1 / rr)
    theta = 2 * np.arctan(rr)
    elementwise_multiplication(rs, theta)
    rs -= m0
    elementwise_multiplication(rs, 1 / (m1 - m0))
    return rs

def modify(frame, input, output):
color_property = output.create_particle_property(ParticleProperty.Type.Color)
color_property.marray[:] = quaternions_to_colors(input.particle_properties.orientation.array)

Particles never get permanently deleted. OVITO always keeps two copies of the data in memory: the original dataset loaded from the input file and the cached results from the data pipeline. Whenever you modify the data pipeline, OVITO recalculates the results. Most of this is described here.

The expression field is documented for the SelectExpressionModifier class. This modifier class inherits the enabled field from the Modifier base class.

Using node.modifiers.remove(select_point_defects) to remove the modifier from the pipeline is actually the best solution. In general the ObjectNode.modifiers field behaves like a standard Python list. That means you can also delete entries by index using the standard del statement:

Code: [Select]
del node.modifiers[0]

The idea to change the data pipeline, i.e. modifiers can be added/removed/changed as needed later on. Exactly as in the graphical program. For example, you can change the existing SelectExpressionModifier and rcompute:

Code: [Select]
select_point_defects = SelectExpressionModifier(expression = 'Occupancy == 0')

vacancies = node.compute()
... Do somthing with the vacancies (e.g. export to file)

select_point_defects.expression = 'Occupancy > 1'
interstitials = node.compute()
... Do somthing with the interstitials (e.g. export to file)

Modifiers also have an 'enabled' attribute, which allows you to temporarily disable a modifier. Or you can permanently remove a modifier from the pipeline again using the Python 'del' statement.

Support Forum / Re: GSD File Format Type Issues
« on: February 23, 2017, 07:19:38 AM »
Maybe the GSD file reader still isn't fully confirming to the standard in this regard.

I couldn't test the aspect of changing particle numbers so far, because we don't use hoomd in our group (yet). Thus, a test file would be super helpful, maybe you have one for me. Thanks.

Note that SelectExpressionModifier only selects particles. That is, it sets the Selection property of certain particles to 1, but it doesn't remove the other particles. That's why the total number of particles is still the same.

Thus, in addition to the SelectExpressionModifier, you need to add a DeleteSelectedParticleModifier. And since you want to keep the sites with occupancy == 0, the selection must be inverted first (or you simply invert the selection expression):

Code: [Select]
node.modifiers.append(SelectExpressionModifier(expression = 'Occupancy == 0'))
vacancies = node.compute()

Yeah, true. I overlooked this.

I checked the IPython documentation now. Here is the way it's correctly done:

Code: [Select]
import IPython

Regarding your question how to stay in console mode after executing a script file:

There is no such option in the ovitos interpreter, but you can try to append the following lines at the end of your script:

Code: [Select]
import IPython


As stated here in the documentation, the current version OVITO requires that scripts are executed by the ovitos interpreter. You cannot use your standard interpreter to import the ovito Python module. The main reason for this restriction is that the Python module requires a fully initialised program environment as a context. Historically, OVITO has been a graphical program and the Python programming interface was added later as an extension plugin that allows controlling the program functions programatically. A second reason is that the precompiled Python extension modules coming with the binary version of OVITO may not be compatible with all Python interpreters, because they were built specifically for the embedded ovitos interpreter.

However, this status is likely going to change. I am working on making the ovito Python package loadable from external Python interpreters without having to start ovito or ovitos first. In a first version I will make OVITO's analysis and file I/O functions available to scripts. Later, visualization and rendering functions will follow.

In the meantime you might be able to integrate the ovitos interpreter, which behaves almost like the standard CPython interpreter, into Spyder if that IDE allows you to configure the Python interpreter to use. Let me know if you have any further questions.

Support Forum / Re: Build error: undefined reference in libbotan
« on: February 18, 2017, 07:07:32 PM »
I have moved this forum post to a new topic, because it deals with a different kind of compilation error.

Which version of Ubuntu do you work on?

The error message suggests that some dependencies of the Botan library are not met. It could be that OVITO needs to be linked against the openssl library if it's a dependency of Botan, but I am not sure.

The first thing I would try to work around this issue is to deinstall the Botan lib:

sudo apt-get remove libbotan1.10-dev

Then run 'cmake .' again and recompile. OVITO will now be built against the internal copy of the Botan lib that is included in the OVITO repository.


OVITO doesn't have a built-in function for computing global quantities from per-atom properties, but you can implemented this with a little Python modifier script. Simply apply a Python script modifier to the dataset and copy-paste the following script:

Code: [Select]
import bumpy as np

def modify(frame, input, output):
    total_pot_energy = np.sum(input.particle_properties['poteng'])
    total_kin_energy = np.sum(input.particle_properties['kineng'])
    total_energy = total_pot_energy + total_kin_energy
    output.attributes['total_energy'] = total_energy

Here I have assumed that the per-atom potential energy and kinetic energy are stored in the poteng and kineng particle properties respectively. You have to adjust the names in the script to your case.

The last line in the script saves the computed total energy in a so-called attribute. You can then use OVITO's file export function to export this quantity as a function of simulation time to a text file.

Support Forum / Re: Compile error
« on: February 17, 2017, 03:02:29 PM »
It looks like there is another user facing the same issue described in this forum thread. He created an issue on GitLab:

@krege: Can you please describe your solution. Which changes to the source code did you exactly make to fix the compilation error?


Support Forum / Re: connection error reading from remote HPC
« on: February 17, 2017, 02:57:42 PM »

The error message suggests that the SSH client of OVITO does not reach the SSH server at all. I assume you already double checked that the hostname is correct. (It might be a good idea though to also use the 'ping' command in the terminal to check if the server is responding).

What about the port? Does the SSH server listen on the default port 22?

Which Windows software do you normally use to connect to the HPC machine?

And do you have any firewall software installed on your local PC that may be blocking OVITO from connecting to the remote host?

Support Forum / Re: Building docs
« on: February 16, 2017, 08:09:00 AM »
I'm glad it worked. Thanks for letting us know.

Support Forum / Re: Building docs
« on: February 15, 2017, 10:22:30 AM »

Normally, the CMake build script takes care of building the Python documentation using Sphinx. It should be sufficient to run "make scripting_documentation" in the build directory. Is this what you were doing? The console output you posted suggests that you run Sphinx manually. But that being said, the way you ran Sphinx looks okay to me.

I haven't see this type of error before. To me it looks like an internal error in the Sphinx machinery which is not really related to OVITO. All I can say is that I didn't have any problems generating the docs with the same version of Sphinx (1.4.8 ) as you.

I'm sorry that I could not provide any real help here.

Support Forum / Re: regarding ovito use on HPC
« on: February 15, 2017, 10:10:03 AM »

I'm not sure what this error message means, I haven't encountered it before. However, I have seen a very similar type of message in the terminal: "setNativeLocks failed: Resource temporarily unavailable". It is due to a bug in an older version of the Qt library used by OVITO ( It occurs every time OVITO writes to its program configuration file in the user's home directory if it is located on a network drive. In this case locking the configuration file to prevent shared access fails due to the Qt bug. However, this warning message can be safely ignored in my experience.

This being said, let me ask you:

1) Does OVITO work normally despite the message, or is it terminating right after printing that message?
2) Did you build OVITO from source, or are you using the official binaries?


Support Forum / Re: Unit of D^2
« on: February 09, 2017, 09:46:44 PM »

Yes, this is correct. The unit of this quantity is length squared in whatever units of length your input data is.

Support Forum / Re: How to hide background atom in OVITO
« on: February 07, 2017, 09:34:16 AM »
In the reference picture you posted the hexagonal rings have been filled with semitransparent polygons. Currently, OVITO doesn't provide a function to do exactly this. You may be lucky by using OVITO's "Construct surface mesh" modifier function though. It creates a surface mesh around atomistic structures. However, it has originally been designed for solid structures, not sheet-like objects like your nanotube. I'm pretty sure it would work for a straight nanotube, but for the helical tube I'm not so sure. You probably have to play around with the "probe sphere radius" parameter.

Support Forum / Re: GSD File Format Type Issues
« on: January 29, 2017, 02:22:30 PM »
I have fixed the loading of GSD files now. Please check out the newest development version available here.

Loading of GSD files with static data like the particle types was not correctly implemented, mainly because I didn't have appropriate test data available. Thanks for providing a file. Let me know if you notice any remaining problems with the new program version.

Support Forum / Re: Temperature in Lammps
« on: January 28, 2017, 06:33:25 PM »
OVITO cannot directly import global thermo data from LAMMPS simulations.

But you could use OVITO's Python script overlay feature for this. That means you have to write a small Python script that reads in the temperature data from a text file (or directly from the LAMMPS log file). In your user-defined viewport overlay function you then print the temperature value for the current simulation frame onto the rendered viewport image.

Support Forum / Re: GSD File Format Type Issues
« on: January 27, 2017, 09:09:59 AM »
I just want to leave a short notice here that I am currently traveling and I will look into this issue as soon as possible.
In the meantime: If you have a small example GSD file to demonstrate/reproduce this issue, it would be great.

Support Forum / Re: Including CAT in OVITO
« on: January 27, 2017, 08:59:32 AM »
Hi Iyad,

Thank you for your suggestion. Yes, in principle it is possible to integrate the more advanced structure identification algorithms of CAT into OVITO, but it would require several weeks of development work. I currently don't have the time to do it myself. Let's see, hopefully I can obtain more manpower to do this in the future.

Support Forum / Re: Compile error
« on: January 19, 2017, 12:32:25 PM »
Sorry, I'm not sure if I understand.

After my change, ViewportMenu.h now includes <gui/GUI.h>, which includes <core/Core.h>, which includes <QtGlobal>. Why does GCC 6 still not see the macros defined in <QtGlobal>?

If you can, and if you find that my solution is insufficient please open an issue or a merge request on GitLab:


Support Forum / Re: OVITO WS Python Script
« on: January 19, 2017, 09:08:37 AM »

The problem is that Ovito only allows one particle selection to exist at a time. More specifically, a DataCollection can only hold one particle property named "Selection". Particles cannot have multiple selection properties associated with them. So if you do

Code: [Select]
    # Set up a particle selection by creating the Selection property:
    selection1 = output.create_particle_property(ParticleProperty.Type.Selection).marray
    selection2 = output.create_particle_property(ParticleProperty.Type.Selection).marray
    selection3 = output.create_particle_property(ParticleProperty.Type.Selection).marray
    selection4 = output.create_particle_property(ParticleProperty.Type.Selection).marray
    selection5 = output.create_particle_property(ParticleProperty.Type.Selection).marray
    selection6 = output.create_particle_property(ParticleProperty.Type.Selection).marray

then the repeated call to create_particle_property() will always return the same particle property and all variables selection1 though selection6 will refer to the same Numpy data array and the following code will lead to wrong results.

Since your are mainly interested in the defect counts, I recommend that you do not create particle selections at all. Instead, just create temporary Numpy arrays and count non-zero entries:

Code: [Select]
selection1 = (site_type == 1) & (occupancies[:,0] == 0) & (occupancies[:,1] == 0)
selection2 = (site_type == 1) & (occupancies[:,0] == 0) & (occupancies[:,1] == 1)
output.attributes['O_Vac'] = np.count_nonzero(selection1)
output.attributes['O_Anti'] = np.count_nonzero(selection2)

If you want, however, you can still let the modifier function generate a particle selection, but only one!

Support Forum / Re: Compile error
« on: January 19, 2017, 08:50:36 AM »
Okay, great that you found out what caused this error. I now added <QtGlobal> to the list of headers that are included in every source file (

Thanks for describing your experience. I will look into this when I find some time. But it's likely a bug in the Qt library itself, which is responsible for this, and there is not much I can do about it.

Previously, another Ovito user also reported a program crash after choosing "Load File". This one turned out to be a compatibility problem between Qt and the Dell backup and Recovery software installed on his system (see Again, switching to the alternative File Selection dialog solved the problem.

Pages: 1 ... 15 16 [17] 18