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 ... 20
Support Forum / Re: Varying Number of Particles
« on: January 03, 2019, 09:22:48 PM »
I can confirm -after looking at the source code again- that Ovito should be capable of reading GSD files with varying number of particles, at least in principle. This may have never been tested though. As Constanze wrote, please send us a test file, and we'll investigate this further. Thanks.

Support Forum / Re: Lammps data file bond property coloring
« on: December 29, 2018, 12:15:27 PM »

Ovito's data file parser currently ignores the "Bond Coeffs" section in LAMMPS data files. There is no way to associate auxiliary information with bond types.

But I am wondering if this is really what you want anyway. It sounds like you would like to associate each bond with an individual property value, not each bond type. Right? Because that is also what would be needed as input for the "Color Coding" modifier. It operates on values of individual bonds, not bond types.

Let's say you first load in the bonds list from the LAMMPS data file, and you prepare a separate text file containing just the additional per-bond values which you would like to be available within Ovito. This second data file contains one line per bond and one numeric value per line. You can use a Python script modifier within Ovito to import this file (typically using the numpy.loadtxt() function) and assign it as a new property to the already loaded bonds. Subsequently, the new bond property will be available as input for the Color Coding modifier.

Do you think that approach would solve your problem? If so, I can help you with writing the Python script function for loading the bond property array and assigning it to the bonds.


Support Forum / Re: remove atom from spherical system
« on: December 29, 2018, 12:00:39 PM »

If your particle is exactly spherical, and if you know its size, you could use the "Expression Selection" modifier of OVITO to select all atoms in the interior of the particle whose coordinates are fall within a spherical region of a given radius.

If the shape of your nanoparticle is not precisely known, you need a way to adaptively determine the atoms that are located outside a certain distance from the particle's surface. A common way to do this is to use the atomic coordination number to select atoms which are fully coordinated and deselect those that are under-coordinated, because they are located close to the surface. In Ovito, you can use the "Coordination Analysis" modifier to compute the number of neighbors of each atom within a given range (let's say 3.0 Angstroms). Subsequently you can use again the Expression Selection modifier to select all bulk atoms having a coordination number above a certain threshold. Let's say 80% of the usual coordination number of bulk atoms in the interior of the nanoparticle.


Support Forum / Re: Draw and color triangles/polygons
« on: December 29, 2018, 10:39:54 AM »
Hi Botond,

Where are the data values coming from that you want to use for coloring the triangles? Are they derived from some atomic property of the vertex atoms, or should they be loaded from a separate data file?


Support Forum / Re: atomic strain calculation during the shear process
« on: December 19, 2018, 04:20:33 PM »
Dear June,

Yes, Ovito can compute atomic strains with respect to a varying reference configuration. In this case, the reference series of configurations should contain the same number of frames as the series of fully relaxed interface configurations. You can load the reference series in the Atomic Strain modifier and select the "Reference frame - Relative to current frame" option and set the "Frame offset" to 0. When the modifier calculates the atomic strains for a frame of the shear simulation, it will use the corresponding frame from the reference series.

You didn't mention how the shearing of the interface was performed. If it was done by shearing the periodic simulation cell boundaries (in contrast to moving the atoms inside the cell), then it would suffice to simply use the "Eliminate homogeneous cell deformation" option of Ovito 2.9.0 (or the equivalent "Affine mapping: To reference" option of Ovito 3.0.0-dev). The modifier will then apply an affine shear deformation to all atomic positions prior to calculating the atomic strains, basically reverting the overall shear of the interface and retaining only the internal motion of atoms due to relaxations. In this case you would not need to create and use an explicitly varying reference configuration as described above.

A third option is for you to simply work with a static reference configuration and focus on the "non-affine squared displacements" computed by the Atomic Strain modifier instead of the atomic shear strains. The non-affine squared displacement value calculated for each atom quantifies how irregular the local displacements around a central atom are, i.e. how much the neighboring displacements deviate from a perfectly affine shear deformation.


Support Forum / Re: Load file dialog problem (3.0dev)
« on: December 19, 2018, 06:38:07 AM »
Right, Ovito itself is not accessing any of the files until you press the "Ok" button of the file selection dialog. It must be the dialog box itself that is scanning the files in the current directory, probably to determine their type for displaying the correct icons and querying other metadata from the file system.

I don't think there is much I can do about it, unfortunately. It's something that happens inside the Qt library, which implements the file selection dialog (QFileDialog class). There must have been internal changes in newer releases of this library, because I did not change how this file dialog is used by Ovito when developing release 3.0. 

I already looked online for more information on this, but couldn't find anything substantial. It looks like there exists an optional flag that can be specified: QFileDialog::DontUseCustomDirectoryIcons. It is supposed to speed up the dialog when browsing network directories under Windows. But it sounds like it only avoids unnecessary accesses to subfolders, not to actual data files in a directory.

I've just put Ovito version 3.0.0-dev322 online. It comes with a newer version of the Geogram library (now supporting >100 million atoms) and a new patch for that library that should give fully deterministic behavior.

Support Forum / Re: animation problem
« on: December 18, 2018, 12:57:47 PM »
Thanks for letting me know. Looks like I wasn't fully successful in fixing the problem.

Please download Ovito 3.0.0-dev322 -it should correct the problem- and try again.

Hi Chris,

It may be that these differences are actually due to the DXA producing non-deterministic results in general (i.e. it's not related to the CA file export). This has been an older problem (which I thought was solved up until now): When you re-run the DXA analysis on the same input data, the resulting dislocation network may slightly vary. I just tested this with Ovito 3.0.0-dev on my Mac. You can manually force a recalculation of the DXA results by refreshing the input data from the external simulation file (see here). Every time I do this, the resulting dislocation lines slightly change (and with them the reported line lengths).

The reason for this behavior doesn't lie in the DXA itself (I made sure it is deterministic) but rather in the Geogram library that is used by the DXA to compute the Delaunay tessellation of the atomistic system. The Delaunay routine randomly shuffles the input atoms, affecting all subsequent steps of the DXA algorithm.

Several years ago I developed a workaround for this issue, and back then I had confirmed that DXA delivers stable, deterministic results. I'm not sure why this has recently changed. Perhaps I had checked it only under Linux but not macOS. Which platform do you work on?

Incidentally, I am currently working on replacing the Geogram library with a newer version (in order to support >200M atoms, which currently blow up DXA). As part of this, I will investigate this problem again and hopefully provide a solution soon. I'll let you know.


Support Forum / Re: Load file dialog problem (3.0dev)
« on: December 17, 2018, 11:46:29 AM »
We just tested the official Ovito binaries (v2.9.0 and v3.0.0-dev from the website) on two different Ubuntu Linux machines, but we could not observe any significant differences in the behavior of the file selection dialog between the two program versions. Both seem to operate reasonably fast (dialog pops up quickly and browsing directories containing 2k files is not associated with waiting times).

This would mean it could be a local problem on your machine. Let us know if you find out more.

Support Forum / Re: Load file dialog problem (3.0dev)
« on: December 16, 2018, 09:17:39 AM »

You are using the Ovito version for Linux, right? The current development versions of Ovito use a newer release of the Qt library. This library provides the file selection dialog, and I'm afraid as an application developer there is not much I can do about its behavior. I haven't noticed any performance differences so far, but we'll check if the reduced performance can be observed on our systems too.

There is one thing you should try: In the application settings dialog of Ovito, on the "General" tab, there is a switch that enables an "alternative" file selection dialog. Please check if changing this setting (and restarting Ovito) makes any difference. Let me know if it does.


Support Forum / Re: animation problem
« on: December 15, 2018, 01:34:14 PM »
Ovito 3.0.0-dev312 and newer versions (available here) contain a fix for this issue.

Support Forum / Re: X server necessary using ovitos?
« on: December 14, 2018, 11:54:25 AM »

ovitos automatically connects to the X server on startup if there is one, because it might require it for OpenGL rendering (of images/movies). However, you can "hide" the X server from ovitos by clearing the DISPLAY environment variable using the following shell command before starting ovitos:

   export DISPLAY=


Support Forum / Re: animation problem
« on: December 13, 2018, 12:16:44 PM »
Hmm, an XYZ file with varying types of atoms... This could be the same issue reported here:

I am investigating it.


Support Forum / Re: Matplotlib crashes with OVITO
« on: December 12, 2018, 12:03:57 PM »
I'm not sure if this will suffice to work around the problem, but you can try the following. Both Ovito and matplotlib use the Qt libraries for their user interface and graphical output. This can leads to certain conflicts, because both initialize the Qt system in different ways and results may depend on the order in which you import an initialize the ovito module and the matplotlib module.

Please add the following code line to the very top of your Python source file:

Code: [Select]
from PyQt5.QtWidgets import QApplication
app = QApplication([])

This will initialize the Qt system before anything else, in a way that should be compatible with matplotlib. When you do "import ovito" later, Ovito should detect that it is already initialized and not do it again.

I couldn't test this workaround myself. I don't have access to a Linux machine at the moment. Let me know what happens.

In any case, it should be possible to run matplotlib with a non-interactive backend to avoid the Qt conflict. A non-interactive backend doesn't display any window interface and only outputs the plot to a file. For example:
Code: [Select]
import matplotlib
import matplotlib.pyplot as plt

Support Forum / Re: Matplotlib crashes with OVITO
« on: December 12, 2018, 08:57:30 AM »
Hi yketa,

how did you execute this script? Using the 'ovitos' interpreter or the standard Python interpreter on your machine?


Dear avik,

The atomic angle of rotation is calculated from the atomic deformation gradient, which in turn is the key quantity calculated by the Atomic Strain modifier function in Ovito. This modifier provides the Output rotations option, which activates the calculation of the microrotation angle for each atom. Please see the current documentation for more info:


Support Forum / Re: OVITO crashing while loading LAMMPS dump file
« on: December 04, 2018, 10:34:08 AM »
Hi Abu,

Thanks for posting the system info. I checked my notes and saw that I had received reports from two other users before, who encountered the same problem and who had the same graphics driver on their systems (Intel graphics driver build for Windows). This suggests that there exists some incompatibility between this driver and Ovito, but I am not sure what it is. To further diagnose the problem (and find a workaround), I will need a test machine with the same kind of graphics hardware and driver configuration. We'll try to find one in our department, maybe we are lucky.


Support Forum / Re: Different results for the same data file
« on: November 30, 2018, 05:59:32 PM »
Dear ad,

Please check again the value of the "RMSD cutoff" parameter of the PTM modifier. My suspicion is that you have been using different cutoff values (0 in Ovito 2.9.0 but a non-zero cutoff in Ovito 3.0.0).

It is always a good idea to use a non-zero RMSD threshold value (e.g. 0.1, which is the default value in Ovito 3.0.0) when performing the PTM. Without a cutoff, the PTM will try to assign a crystalline structure to any atom, even if the atomic structure is very far off from the ideal lattice structure. The tolerance is basically infinite in this case and that is why you see many crystalline atoms even though your system is amorphous.

With a cutoff value of 0.1, as in Ovito 3.0.0, you get more reasonable results. You will also see that other structure identification algorithms such as Common Neighbor Analysis (CNA) will agree with the PTM in this case. All atoms are classified as "Other", which is typical for amorphous or liquid structures.   


Support Forum / Re: Different results for the same data file
« on: November 29, 2018, 04:13:44 PM »

I compared Ovito 2.9.0 and Ovito 3.0.0-dev307 and they give identical PTM results for my test datasets. Are you sure you used the same settings for the PTM modifier in both cases? If yes, please send your dataset so I can reproduce your results.


Support Forum / Re: VTK export format
« on: November 28, 2018, 07:15:35 PM »
Yes, the Python API gives you access to the surface mesh only. In fact, the SurfaceMesh data structure represents the original periodic mesh, which is still embedded in the periodic simulation domain and which has not been cut open at the simulation cell boundaries yet.

The cutting only happens during export to a VTK file or when the surface mesh is rendered. Then triangles that cross a periodic cell boundary get split into several truncated pieces, and that's also when the cap polygons are computed. The periodic mesh typically has fewer vertices than the non-periodic version that is exported to the VTK file, because extra vertices must be created at the intersections with the simulation box boundaries. 

Support Forum / Re: VTK export format
« on: November 28, 2018, 04:15:53 PM »
Internally, Ovito operates with two separate triangle meshes: one for the actual surfaces and one for the "cap" polygons, which are generated at the intersections of the surface with the periodic cell boundaries. Each triangle mesh consists of a set of vertices ("POINTS") and a set of triangles ("CELLS") that connect these vertices.

During export to a VTK file, Ovito 3.0.0-dev (!) fuses the two meshes into a single output mesh by combining the points list and the cells list of the surface and cap meshes. However, the code is very lazy: It doesn't check for duplicate vertices that are shared by the surface mesh and the cap mesh. It simply outputs these vertices twice. In fact, you will find two copies of a vertex in the VTK file if it is located exactly on a periodic cell boundary.

As you mentioned, the VTK file contains two sections, POINT_DATA and CELL_DATA, which indicate for each vertex and for each triangle cell whether it originally was part of the surface mesh or the cap mesh using 0's and 1's. What might have confused you is the existence of the two vertex copies. One of them is marked as belonging to the surface mesh (0) while the other copy, coming later in the list, is marked as belonging to the cap mesh (1).

All these statements apply to the current development version (3.0.0-dev) of Ovito. If you are interest in further details, you can take a look at the source code of the routine that writes the VTK files:


Support Forum / Re: OVITO crashing while loading LAMMPS dump file
« on: November 27, 2018, 08:16:14 AM »
I would like to ask you to also try the current development build of Ovito 3.0.0-dev to see if it shows the same problem. If yes, please select 'OpenGL Information' from the Help menu of Ovito. Post the information displayed by the dialog box here.


Support Forum / Re: Not Able to Print a Variable While Looping Over Frames
« on: November 21, 2018, 07:27:09 PM »
If the selection set may be empty, because are no particles of type 2, for example, then you have to handle this special case appropriately in the code. The numpy.any() function can be used to test whether the selection set is empty:

Code: [Select]
selection2 = (input.particles["Particle Type"] == 2)
if numpy.any(selection2):
    output.attributes["High_Z(2)"] = numpy.max(input.particles["Position"][selection2,2])
    output.attributes["High_Z(2)"] = 0.0

If you have more questions, I would prefer that you ask them here in the forum. I have only very limited time at the moment to provide technical support for Ovito as my other jobs take up more and more of my time.

Support Forum / Re: issue with importing matplot and ovito
« on: November 20, 2018, 11:03:03 AM »
Hi Leila,

I am not entirely sure what is happening here, but there probably is a conflict between multiple versions of the zlib library on your system: one in the system directory and one in the Anaconda installation directory.

Ovito should use only the library version from the Linux system directory. By setting the LD_LIBRARY_PATH environment variable you seem to be creating a new problem: Now Ovito may load some of the Qt libraries from the Anaconda directory, which leads to a compatibility problem with the internal Qt libraries of Ovito and the initialization of the application fails completely.

Please try running ovitos without the LD_LIBRARY_PATH and PYTHON_PATH environment variables set, e.g.:

   LD_LIBRARY_PATH=  PYTHON_PATH= ./bin/ovitos

Instead of clearing these variables during invocation of ovitos, you can also use:

   export LD_LIBRARY_PATH=
   export PYTHON_PATH=

Note that ovitos comes with its own copy of the matplotlib module. Thus, you don't need to pull anything in from the Anaconda installation, which typically includes modules and libraries that are incompatible with the Python interpreter shipping with Ovito.


Support Forum / Re: Not Able to Print a Variable While Looping Over Frames
« on: November 19, 2018, 08:50:58 AM »
I assume you are currently using the following code line to determine the max. z-coordinate of all particles:

Code: [Select]
output.attributes["High_Z"] = numpy.max(input.particles["Position"][:,2])

Here the ':' selects all particles. You can replace it with an index list which selects only particles of a specific type:

Code: [Select]
selection1 = (input.particles["Particle Type"] == 1)
selection2 = (input.particles["Particle Type"] == 2)
output.attributes["High_Z(1)"] = numpy.max(input.particles["Position"][selection1,2])
output.attributes["High_Z(2)"] = numpy.max(input.particles["Position"][selection2,2])

What is being used here is a technique knows as Boolean indexing of a Numpy array. The first two lines generate two selection arrays using Boolean expressions, which refer to the "Particle Type" property. The following two code lines use these selection arrays to filter the "Position" property array.

Support Forum / Re: Not Able to Print a Variable While Looping Over Frames
« on: November 17, 2018, 07:56:42 PM »
Please attach the script code. Without it, it is hard to tell what went wrong.

Support Forum / Re: Updating Molecule IDs in Replicate Copies
« on: November 16, 2018, 08:45:44 AM »

This appears to be an accidental slip in the implementation of the replicate modifier. Thanks for reporting this.

I fixed the issue in the source code of Ovito today.

You can work around this problem by applying the Compute Property modifier after replicating the atoms. Use the following formula to recompute the Molecule Identifier property:

Code: [Select]

This will assign new unique molecule IDs to the atoms. Note, however, that the Compute Property in the current dev build Ovito 3.0.0-dev contains another bug that sets the expression variable 'N'  to zero. Thus, in this program version you might have to replace the dynamic variable 'N' in the formula above with the literal number of (replicated) atoms.


Support Forum / Re: Name on the particle
« on: November 14, 2018, 02:52:47 PM »
Please subscribe to this GitLab issue in case you want to get notified of any developments regarding particle text labels or if you have any suggestions:

Support Forum / Re: Name on the particle
« on: November 14, 2018, 11:26:33 AM »
No, sorry, this feature is not implemented yet. I am currently working on completing the 3.0 release, not adding any significant new features beyond what is already there. Text labels for particles is something that is planed for a later program version, e.g. Ovito 3.1, which I will be working on sometime in 2019. My day job doesn't leave me as much time to work on Ovito as I'd like to.

For the time being, the only solution is for you to use the Python viewport overlay function and write script code to draw the text labels yourself.

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