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 ... 17
Support Forum / Re: LAMMPS input file with atomic mass information?
« on: August 28, 2018, 08:22:59 PM »
I've created a feature request in our issue tracker to keep track of the planned addition:

Support Forum / Re: LAMMPS input file with atomic mass information?
« on: August 28, 2018, 08:07:41 PM »
Dear RU,

That's true, the current versions of OVITO ignore the mass values in a LAMMPS data file. Mainly this is because OVITO stores masses on a per-particle basis, while data files specify mass values on a per-type basis. But of course it would be possible to simply map the per-type masses to the "Mass" per-particle property in OVITO. And I will certainly extend OVITO in the future to do exactly this.

In the meantime, you could manually assign the masses within the program, for example using the Compute property modifier. For the example you posted, with only two atom types, you could enter the following compute expression to assign the right masses:

Code: [Select]
ParticleType==1 ? 1 : 2

A more advanced solution, requiring more work, would be to write a user-defined modifier function in Python that actually parses the masses from the data file and assigns them to the particles. 


Support Forum / Re: Question on detecting and following perticular atoms
« on: August 28, 2018, 07:26:00 AM »
Dear Ali,

You can use the Freeze property modifier for that. It lets you copy the state of a particle property from one time frame to all others.


Support Forum / Re: Save the distance between two particles
« on: August 28, 2018, 07:23:00 AM »
Yes, global attributes like the one this Python function computes can be saved to a text file as a tabulated function of time. See here:

Support Forum / Re: Utility tab in ovito 3
« on: August 22, 2018, 11:13:19 AM »
Right, that's the one function from Ovito 2.9 for which there is no replacement yet in the current development release. I am going to add a measurement function for bond angles in one of the next release iterations.

Support Forum / Re: Utility tab in ovito 3
« on: August 21, 2018, 09:39:16 PM »
Dear Ali,

The "Utilities" tab has been removed in the new program version. (Almost) all functions from this tab, which used to be part of previous versions, are now provided by the new data inspector panel of Ovito 3.0. See this section of the user manual:


Support Forum / Re: Problem with Ovito Installation
« on: August 17, 2018, 09:26:02 AM »
Dear Big,

Which version of Ovito did you install? 2.9.0?

Crashes during startup or when opening a data file are often due to compatibility problems with the graphics driver. To find out if this is the case, you can try running the ovitos.exe executable (not ovito.exe) found in the installation directory. This is the script interpreter, which doesn't open any graphics windows. Thus, if ovitos runs without problems, it would indicate that the crash is probably due to graphics driver problem, not a general installation problem.


Support Forum / Re: Bond Angle Distribution
« on: August 11, 2018, 09:14:34 AM »
Hi Ali,

This code should for work for non-periodic or mixed periodic/non-periodic cells as well. For every bond in the system, OVITO keeps track of whether it crosses a periodic boundary of the simulation. This information is stored in the data.bonds.pbc_vectors array, which contains a triplet of integers for each bond specifying which boundaries it crosses, how many times and in which directions. For bonds that do not cross any boundary, the triple will be (0,0,0). In your case, the cell is non-periodic in Z, so the third number of the triplet will be zero for every bond, because there simply are no bonds crossing the z-boundaries of the cell in your system. Due to that 0 entry in the data.bonds.pbc_vectors array, the z-components of the calculated bond vectors will be left untouched by the calculation performed in line 2 of your code.

The above statement assumes that OVITO is informed about the mixed PBCs of your system. For LAMMPS dump files this information gets automatically read from the input file. You can verify that by inspecting the pbc field of the SimulationCell object.


Support Forum / Re: Select atoms at the interface of two materials
« on: August 09, 2018, 02:50:05 PM »
Hi Mike,

yes, you're right. We wrongly assumed that you're already using OVITO 3.0, the current development version, but you are actually using OVITO 2.9.0. For future reference, in case you decide to switch to OVITO 3.0, all changes of the Python API are documented here:
One of the new features of OVITO 3.0 is that the Python programming interface gives you direct access to the vertices and triangles of a computed surface mesh (see here) --something that might be of interest to you.

However, there seems to be a misconception regarding the Construct Surface Mesh function. This function is designed to construct a surface around a group of atoms forming a three-dimensional solid. It does not construct a surface through the selected atoms. In your case, you are passing just the surface atoms to the function, which form a planar sheet. A two-dimensional sheet has no solid volume, that's why you don't get a proper surface mesh.

In other words, you went one step too far here. Instead of extracting the atoms at the interface between the two materials yourself, you could simply pass all atoms of one material to the Construct Surface Mesh function. To do that, first select all particles of one type, then activate the Use only selected particles in the Construct Surface Mesh panel.


Support Forum / Re: running ovito on cluster
« on: August 09, 2018, 02:32:12 PM »

Under Linux, OVITO will automatically try to connect to a running X server if there is one. Even though it is not showing any graphical user interface, this also applies to the script interpreter "ovitos". That's because image rendering via hardware-accelerated OpenGL requires the GLX extension to the X window system.

The detection is based on the DISPLAY environment variable. If it is set, which seems to be the case on your compute node (maybe because you captured all environment variables from the login node during job submission), ovitos thinks an X server is running and tries to connect to it. This fails. The solution to this problem is to clear the DISPLAY variable right before running ovitos, e.g.:

   export DISPLAY=
   ovitos ...


Support Forum / Re: Void in amorphous material
« on: August 09, 2018, 01:31:53 PM »
Hi Zhen,

Since you are interested in the void size distribution, you want to identify the individual voids in the material and determine their sizes, right?

Yes, in principle you can do this by taking the triangle mesh generated by the Construct Surface Mesh modifier, decompose it into disconnected components, one component (polyhedron) per void. For each mesh component, you would then have to calculate the volume it encloses. That is probably the hardest part, because the voids may be non-convex, and calculating the volume of a general non-convex polyhedron is not trivial.

The SurfaceMesh class of the OVITO 3.0 Python interface gives you programmatic access to the vertices and triangles of the surface mesh. From here on you are on your own though. OVITO doesn't provide any built-in functions for calculating the volumes, and I am not working on any such functionality at the moment.

Best regards,

Support Forum / Re: How to coloring particles by its properties
« on: August 09, 2018, 09:49:36 AM »
Thanks for uploading the data files. I ran the script on these files and got the following error message:

Code: [Select]
moglios:eason1021 stuko$ ~/prj/ovito/build/debug/
Traceback (most recent call last):
  File "", line 349, in compute_myproperty
    locals()["px_f_%s"%k] =["px_matrix_%s"%k],locals()["px_matrix_inv_ref%s"%k])
KeyError: 'px_matrix_inv_ref0'
Traceback (most recent call last):
  File "", line 812, in <module>
    data = node.compute(frame_index)
  File "/Users/stuko/prj/ovito/build/debug/", line 178, in _Pipeline_compute
    raise RuntimeError("Data pipeline evaluation failed: %s" % state.status.text)
RuntimeError: Data pipeline evaluation failed: Modifier 'Color coding' reported: The property with the name 'myproperty' does not exist.
ERROR: The Python script '' has exited with an error.

Note that these are actually two errors. The first one occurs in line 349 of the script file ("KeyError: 'px_matrix_inv_ref0'"). The second one, in line 812, is only a subsequent error. Because the user-defined modifier function raises an error, the new particle property is never created and that's why the Color Coding modifier complains about the missing property.

The problem in your script seems to be the usage of the locals() function in various places. Note that it may return a different dictionary depending on the context from where you call it. Inside the user-defined modifier function you have a different set of locals than in the main body of the program where you process the reference structure. Furthermore, modifying the locals() dictionary is generally discouraged any, see the official Python docs:

I suggest you replace it with a simple dictionary that you create at the beginning of your program:

Code: [Select]
myvars = {}

Then replace all occurrences of "locals()" in your code with "myvars".

Support Forum / Re: ModuleNotFoundError: No module named 'sklearn'
« on: August 09, 2018, 08:50:43 AM »
Dear Haomin,

The Python interpreter shipping with OVITO doesn't come with the scikit-learn module. Only numpy is included. Thus, you need to install the module as described in the manual here:

Please run this command from the terminal:
Code: [Select]
ovitos -m pip install scipy scikit-learn

if you are using OVITO 2.9.0, you may encounter a pip connection error due to an expired SSL certificate in the Python interpreter. In this case, please upgrade to the current development release of OVITO 3.0.


Support Forum / Re: How to coloring particles by its properties
« on: August 08, 2018, 04:18:20 PM »
I don't have an explanation for this at the moment. I took the script, removed most of the calculation code and tested it with one of my data files. I didn't see any errors in this case.

Maybe the problem only occurs with your input files, or originates from the actual calculation code which I had to remove for testing. Could you please post your input data files, at least some of them? Then I can test the script with the original input data and investigate why it stops. Please let me also know which exact version of OVITO you are using. Thanks.

Support Forum / Re: How to coloring particles by its properties
« on: August 08, 2018, 01:26:58 PM »
Your script still didn't do the right thing. I see that you have written a for-loop over all input simulation frames. Within that loop, you do the following:

  • request the output of the data pipeline
  • perform some calculation on that output data
  • define a modifier function, which takes that computed data array to create a particle property from it, and append the function to the data pipeline
  • append a Color Coding modifier to the pipeline

Note that steps 3 and 4 will have no effect during the first loop iteration, because the pipeline was already evaluated in step 1, without the two modifiers being inserted into the pipeline yet. Thus, the user-defined modifier function is never called by the pipeline system. Furthermore, in consecutive loop iterations, the pipeline will get longer and longer, because you insert the user-defined modifier function and the Color Coding modifier multiple times.

The correct approach should look as follows (I have rearranged your script accordingly, see the attached file):

  • define a custom modifier function that takes whatever input data is provided by the pipeline system and performs some calculation on it; append that modifier function to the pipeline
  • append a Color Coding modifier to the pipeline
  • loop over the simulation frames and evaluate the pipeline at each timestep

Note that in this approach, the pipeline is first set up completely. Once all modifiers have been inserted into the pipeline, the static pipeline can be evaluated multiple times, once for each frame. The pipeline system will repeatedly call the user-defined function with the correct input data.

Support Forum / Re: visualization of vectors by arrows
« on: August 07, 2018, 04:05:55 PM »
You seem to be using the "Left" viewport of OVITO. That means the y-z plane is the projection plane in this case. You can reset the x-component of the vectors to 0.0 using OVITO Compute Property modifier. This should give you "nicer" arrow heads.

Support Forum / Re: visualization of vectors by arrows
« on: August 07, 2018, 03:59:35 PM »
Dear Ilya,

The arrows would look better if the vectors were parallel to the projection plane of the viewport. In your case, I assume, the vectors have a large component perpendicular to the projection plane (i.e. along the y-axis). That's why the heads of the (flat-shaded) arrows appear degenerate in the second picture and that's why you see the circular bottoms of the head cones of the normal-shaded arrows in the first picture.

Maybe there is a way for you to reduce the out-of-plane component of the vectors and project them into the plane of the viewport. This should improve the arrow visualization.


Support Forum / Re: Error redering image python script
« on: August 07, 2018, 10:32:38 AM »
You can check which installation of the Qt libraries Ovito is being built against by running "cmake -L" in the build directory. You should look for a set of cmake variables named "Qt5*_DIR" which point to the Qt library directory. 

To find out which version of Qt the PyQt5 Python module is loading, start up your Python interpreter and execute

Code: [Select]
import PyQt5

The directory path should contain a bunch of shared library files (Qt*.so). Run "ldd" on one of these .so files in the terminal to find out which Qt installation it was linked to. If it just says "statically linked", you may have a problem. It would mean that Qt was statically linked into the PyQt5 module libraries and there is no way for Ovito to use the same Qt libraries. I think in this case it might become necessary to rebuild the PyQt5 Python module from source.

Support Forum / Re: Error redering image python script
« on: August 07, 2018, 08:23:42 AM »

I haven't seen this error message before and seems confusing as you probably agree:
Code: [Select]
TypeError: wrapinstance() argument 2 must be sip.wrappertype, not sip.wrappertype

My guess is that this error is due to some sort of installation compatibility problem. Maybe you are mixing different versions of the same library in the same program, perhaps the PyQt5 module libraries. In particular, make sure that the PyQt5 module installed in your Python interpreter was built against the same Qt libraries which Ovito was built against.

One question: Are you running this script through the 'ovitos' interpreter or a standard CPython interpreter?

Support Forum / Re: How to coloring particles by its properties
« on: August 06, 2018, 05:39:52 PM »
Typically, you would insert this statement right after the line that creates the pipeline, i.e. right after the call to import_file().

Support Forum / Re: How to coloring particles by its properties
« on: August 06, 2018, 05:27:13 PM »
If you intend to produce a visual output, it's important that you add the pipeline (or rather its output) to the scene. This doesn't happen automatically for datasets imported via the import_file() function. See the first note on this page in the green box:

To add the pipeline's output to the scene and make it visible in the viewports of OVITO and in rendered images, add a call to the add_to_scene() method to your script:

Code: [Select]

Support Forum / Re: How to coloring particles by its properties
« on: August 06, 2018, 04:54:25 PM »
Thanks. I got your code and I am still trying to understand what you are doing and what your goal is.

You wrote that nothing happens when you run this script. What do you expect it to do? Do you want to produce an image or a movie? Or would you like to see the computation results in the viewports of OVITO? Or do you want to produce a series of data output files?

Support Forum / Re: How to coloring particles by its properties
« on: August 06, 2018, 04:29:27 PM »
When you post a message on this forum, you have the option to attach entire files to your message (similar to attachments in emails). Other forum users like me can then download the attached file and open it in a text editor, for example.

Support Forum / Re: How ger the disorientation angle of every BCC atoms?
« on: August 06, 2018, 12:11:14 PM »
Dear Shuai,

There is no easy answer to this problem. You may know already that the Polyhedral Template Matching function in OVITO allows calculating a per-atom lattice orientation from the arrangement of the nearest neighbor atoms.

Correctly assigning atoms to different grains based on this local lattice orientation information is, however, a difficult task and we are actively working on possible solutions. It's a challenging and long-term research project, because, for example, the local lattice orientations typically fluctuate heavily due to thermal vibrations of atoms, elastic strain variations and stress fields induced by surrounding defects. Developing a robust algorithm that correctly identifies grain boundaries, in particular low-angle ones, in the presence of such fluctuations is difficult.

A collaborator of mine, Peter Larsen, has developed an experimental grain segmentation algorithm for OVITO over the past months. But we are still in an early phase and this feature is not yet publicly available. We need to do more testing and research before it can be shared with others.


Support Forum / Re: How to coloring particles by its properties
« on: August 06, 2018, 11:58:36 AM »
Dear eason1021,

The code snippet that you posted doesn't seem to be complete. It would be helpful if you could show us the entire source code of your script, otherwise it is difficult to tell what is happening exactly.

But the RuntimeError produced by the first code version is likely due to the following sequence:
Code: [Select]
    data.particles.create_property('myproperty', data=result_list)
    node.modifiers.append(ColorCodingModifier(property = 'myproperty',gradient = ColorCodingModifier.Rainbow(),start_value = 0,end_value= 19))

The variable 'data' points to a DataCollection object, which represents the computation output of a data pipeline, which has been obtained earlier through a call to the pipeline's compute() method. A DataCollection is always a static snapshot of the data that left the pipeline. You can manipulate it as you like after the fact, for example add a new particle property using a call to create_property(). However, no such changes will affect the pipeline that originally produced the DataCollection. In particular, if you add a new ColorCodingModifier to that pipeline using node.modifiers.append(), that modifier will still see the original data flowing through the pipeline, not the data copy that you manipulated separately outside of the pipeline. That's why the ColorCodingModifier complains that it cannot see the 'myproperty' particle property.

To avoid this error, the addition of the new property to the DataCollection must happen as part of the pipeline. Then subsequent modifiers will see the extended dataset and can work with the new property. One way to accomplish this is by writing a user-defined modifier function adding the new property to the DataCollection as it flows through the pipeline, and insert that function into the pipeline as a PythonScriptModifier. Here is a sketch of that solution:

Code: [Select]
# Initial data import and creation of the pipeline:
node = import_file(...)

# Append any modifiers here to the pipeline which compute information that you will need as input for 'myproperty'...

# User-defined modifier function which computes and adds the 'myproperty' particle property:
def compute_myproperty(frame, input, output):
    mydata = ...  # Compute the property values...
    output.particles.create_property('myproperty', data=mydata)

# Insert the user-defined modifier function into the pipeline.
# The system will call compute_myproperty() automatically later as soon as the pipeline is evaluated.
node.modifiers.append(PythonScriptModifier(function = compute_myproperty))

# Finally, append a coloring modifier to the pipeline which uses 'myproperty' as input, e.g.
node.modifiers.append(ColorCodingModifier(property = 'myproperty',gradient = ColorCodingModifier.Rainbow(),start_value = 0,end_value= 19))

# Optional: Evaluate the full pipeline to get the colored particles.
data = node.compute()

Have you already tried applying the Slice modifier? It lets you cut out thin slices of configurable width from an atomistic structure.

Dear RMCtestFYP,

Sorry, but your question is confusing. On one hand, you write that you cannot make a cut of such a small size. In other words, you would like the cut to be smaller than it currently is. On the other hand, you write that it (I assume you mean the Slice function of OVITO) cuts at most half of the size you want, but not more.

Please attach a picture showing what you have been doing so far, and add a graphic to clarify how you would like it to be. please also describe more precisely what tools in OVITO you have been trying so far. 


I found the following statement in section C.2.7. of the RMC user guide:

The coordinates are reduced, going between –1 and +1 and the box half-length and other distance related properties are given in Ångstrom in RMC.

So I assume that the 43.62 value found in the header of your .cfg file denotes a half box length, right?
Note that OVITO assumes the cell sizes in the POSCAR header to be full lengths and the reduced atomic coordinates to be in the range 0-1. That means, after import in OVITO, the atomic coordinates will already be correctly converted to Angstroms by chance, but the cell size will come out too small by a factor 1/2. You should be able to fix this by applying the Affine Transformation modifier with a 2x scaling matrix just to the simulation cell but not the particle coordinates. Do you agree?

Support Forum / Re: ScatterPlotModifier
« on: July 31, 2018, 10:49:16 AM »
Dear Haomin,

Currently, the Python binding ScatterPlotModifier is not implemented. This Python class has no methods or properties that would allow controlling the modifier's settings from a script. The reason for this (deliberate) deficiency is that the plot produced by this modifier is only displayed in the graphical interface to the user. There is no way for the script to access the graphical plot.

But it would be easy to generate a scatter plot from a Python script using the matplotlib Python module directly from the particle property data. The ScatterPlotModifier is not needed in this case. Have you considered this alternative already?


Dear RMCtestFYP,

I took a look at your input file "Example .cfg file.cfg". Unlike the file extension suggests, this file actually follows the POSCAR format (as used by the VASP simulation code), not the "CFG" format used by the AtomEye software.

The number in the second line of the file is the global scaling factor. If you change it from "1" to "2", the simulation box gets larger. However, since all atomic positions are given in reduced coordinates (as specified by the "Direct configuration" keyword), they get scaled along with the cell. Note that reduced coordinates must all lie in the range [0,1]. However in your file, they range from -1 to +1. This is why some of the atoms appear outside of the box, irrespective of the global scaling factor. To solve the problem, please change the reduced coordinates in your file to be in the range [0,1].


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