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 ... 18
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.

Support Forum / Re: Time average Positions
« on: November 14, 2018, 09:28:23 AM »

Ovito currently doesn't have a built-in function for doing this. So there is no "easy way", sorry.

If I was you and you are working with LAMMPS dump files, I would use LAMMPS to do the time-averaging using the "fix ave/atom" and "rerun" commands. Otherwise, I would use OVITO's scripting interface to load the trajectory data and implement the time-averaging using Python code. That's kind of a "hard way" of course.

If you think that this is a very common problem for which Ovito should provide a built-in solution, let us know. Perhaps I can add it in the future. Computing time-averaged atomic positions is technically not much different from computing interpolated atomic positions, which the new Interpolate Trajectory modifier of Ovito 3.0.0 already does. 


Support Forum / Re: Not Able to Print a Variable While Looping Over Frames
« on: November 12, 2018, 12:05:20 PM »

First note that the following code line should not be indented:
Code: [Select]
That is because this statement needs to be part of the main program and not the compute_max_z() function.

The error occurs, because you did not specify an absolute path of the output file when calling the export_file() function. Without specifying a path, the function will probably try to write the output file to the root directory of your machine, which is a write-protected location. To avoid the error message, specify a full path for the output file, like you did for the input file when calling import_file().


Support Forum / Re: Not Able to Print a Variable While Looping Over Frames
« on: November 08, 2018, 09:55:22 PM »

When loading a legacy-type XYZ file, you need to tell Ovito what the meaning of the file columns is. This is done using the "columns" keyword parameter. See the section on "File columns" here.

For example:

Code: [Select]
node = import_file("", columns=["Particle Identifier", "Particle Type", "Position.X", "Position.Y", "Position.Z"])

The error occurred, because Ovito didn't now where to take the data for the "Position" particle property from. Particles must have a "Position" property, filled with the data from three columns of the input file.


Support Forum / Re: Not Able to Print a Variable While Looping Over Frames
« on: November 08, 2018, 05:46:20 PM »
Thanks for letting us know that you were able to solve the problem.

Yeah, additional pages are easy to miss in the forum. I'm sorry about that. I just bumbed up the maximum number of posts per page to 30 to reduce the likeliness of additional pages showing up.

Support Forum / Re: Atoms Shifting to one end
« on: November 07, 2018, 08:38:07 AM »
Thanks for sending me the POSCAR files. The simulation cell flips in the 9th frame, because the corresponding POSCAR file contains a cell matrix with negative elements (which is not the case for the first 8 files):
Code: [Select]
 -2.464513105012   0.000000374102  -0.000000000000
  0.000000620222   4.267423898079  -0.000000000000
 -0.000000000000  -0.000000000000 -19.658225471601
Ovito is operating normally, I would say. This likely is an error in the code that wrote the POSCAR files.


Support Forum / Re: Problems with the access of property data
« on: November 05, 2018, 08:05:19 AM »
Dear Linyuan,

I'm sorry for the confusion. This error is due to recent changes to the Python data access interface of OVITO and also the underlying data model (introduced with build 3.0.0-dev264), which have not been documented yet. I will try to update the documentation within the coming days (maybe weeks) to explain this important change in more detail.

Here is the main rule you need to follow according to the changed data access interface:

Whenever you are going to modify a data object in a data collection in any way, you need to explicitly request a mutable version of that object. This is done by appending a '_' to the end of the identifier of the object.

In your particular case, you need to write:
Code: [Select]

pos_property = data.particles_['Position_']
with pos_property:
    pos_property[0] = (0,0,0)

A _ has been appended to the particle property name "Position", because you are going to modify the per-particle values stored in that Property object. And note that the _ was also appended to the DataCollection.particles accessor, because you are going to modify one of the sub-objects of this PropertyContainer.

This brings me to the second rule:
A mutable version of a data object can only be requested from a parent data object that is mutable itself. In other words, when modifying a sub-object in the hierarchy of data objects, the container object needs to be made mutable as well using the _ notation.

Any attempt to modify a data object that is marked as read-only (immutable state) will raise an error like the one you saw. By default, all data objects that get passed to a user-defined modifier function by the system, or which are contained in a DataCollection produced by the Pipeline.compute() method, are immutable. The reason is that these data objects are owned by the data pipeline system and must be preserved in their original state to avoid unexpected side effects. Requesting a mutable version of these objects using the _ notation creates a data copy that is safe to modify by the user code.


Support Forum / Re: Problems starting Ovito on Linux Centos 7
« on: November 04, 2018, 08:18:31 AM »
Thanks for posting the LD_DEBUG output. This gave me a first idea what is failing during startup. It seems like the (incompatible) library file /lib64/ is getting loaded instead of the internal version ovito-3.0.0-dev284-x86_64/lib/ovito/lib/ for some reason.

On your system, the LD_LIBRARY_PATH environment variable is set to the value /lib64:/usr/lib64. Do you know whether this is the default value under RHEL 7, or did you set LD_LIBRARY_PATH yourself? I am wondering if it makes a difference when you run Ovito without LD_LIBRARY_PATH being set (like it is the case under Ubuntu, for example):

  LD_DEBUG=libs LD_LIBRARY_PATH= ./bin/ovito

Another fix you could try (not sure if it will work):

  cd ovito-3.0.0-dev284-x86_64/lib/ovito/plugins_qt/platforms/
  ln -s ../../lib/ .

Support Forum / Re: Atoms Shifting to one end
« on: November 04, 2018, 07:15:20 AM »
Hi Anuja,
So far, I don't have an explanation for this behavior. Can you send us the data files (or attach them to a reply posting) and tell us how to reproduce the problem?

Support Forum / Re: Problems starting Ovito on Linux Centos 7
« on: November 02, 2018, 10:37:46 AM »
Hi Tanh,

Thanks for letting me know that the problem persists. I'm not sure, this time it may be a different library issue.
Perhaps I will find some time to install RHEL on one of our machines to test this myself, but in the meantime it would be helpful if you could execute Ovito with the LD_DEBUG environment variable set. This should produce log output that can help me diagnose (and perhaps solve) the problem:

  LD_DEBUG=libs ./bin/ovito

Please save the generated output to a text file and attach it when posting a reply. Thanks.


Support Forum / Re: Problems starting Ovito on Linux Centos 7
« on: November 01, 2018, 12:28:48 AM »

Thank you for sharing your solution of the problem, which seemed to be due to a library path configuration issue in the older Ovito program packages. I hope I was able to fix this issue in the latest Ovito package (development build v3.0.0-dev284) that is available now. It should run out of the box, without the need to change the LD_LIBRARY_PATH variable on CentOS Linux. Let me know if it doesn't.


Then how about using the Slice modifier to select atoms within a plane? This modifier lets you specify the width of the slab of atoms that should be selected. Furthermore, you need to specify the normal vector of the selection plane (in spatial coordinates though, not in crystal lattice coordinates). Subsequently, you can apply the Assign Color modifier to give all atoms selected by the Slice modifier a new color of your choice.

Support Forum / Re: Quantum espresso files
« on: October 25, 2018, 08:36:24 AM »
Yes, we may be able to add I/O support for QE files to Ovito in the future.

I am not familiar with the QE software myself and the data file formats it uses. Would you be interested in reading just the input files of QE with Ovito, or also the output files? Perhaps you can post an example file that you would like to open with Ovito. That would be helpful.

It's likely that the error only occurs for files fetched via SFTP, but I cannot promise that it doesn't also occur for files stored locally.

I would be interested in knowing how many files you are processing and after how many the error occurs. You can find out by adding a print statement to your modifier function to print the current frame being processed:

Code: [Select]
def compute_max_z(frame, input, output):

As a workaround, you could process the frame sequence in chunks. Call ovitos several time to process one chunk at a time and then combine the generated output files into one using a text editor. The export_file() function allows you to specify a (sub-)range of frames to process. Let's say the error occurs only after 1000 frames have been processed succesfully, then you can limit the script to frames 0-999:

Code: [Select]
export_file(node, "max_z2.part1.txt", "txt", columns=["Ocount", "x_coord"], start_frame = 0, end_frame = 999, multiple_frames = True)

Pages: [1] 2 3 ... 18