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 ... 18
Dear Jatink,

I am glad I was able to help a bit.

I am currently on vacation though, that's why I can provide only very limited support at the moment. WHat you described sounds like a more complicated problem that I cannot address before I return to Germany (in a week from now).

Maybe my colleague Constanze will be able to provide you some support in the meantime -or other users in this forum. In general, however, I suggest you contact us directly if you are interested in a scientific collaboration, receiving direct technical support and/or more in-depth training on Ovito's analysis and scripting capabilities.


Support Forum / Re: Problem in executing OVITOS
« on: October 09, 2018, 12:17:36 AM »
Dear ad,

Which version of Ovito did you install? And what is your current macOS version?


Answer to your 1st question is a yes. And the append() instruction adds the user-defined modifier function to the data pipeline. This is similar to what happens when you insert a modifier in the graphical user interface of Ovito. All the modifier functions in the current pipeline get called by the system to process the input data and compute the resulting output data.

There are several ways of counting the O-atoms. In the present case it's easiest to extend our user defined modifier function to emit a second global attribute:

Code: [Select]
def compute_max_z(frame, input, output):
    output.attributes["High_Z"] = numpy.max(input.particles["Position"][:,2])
    output.attributes["Ocount"] = numpy.count_nonzero(input.particles["Particle Type"] == 2)

Replace the literal "2" in this code, which I just used as an example, with the atom type ID for O atoms.

Note that in Ovito the term "property" typically refers to local per-atom information, whereas the term "attribute" refers to a global value, i.e. information not related to individual particles. You would like to calculate an attribute from the local per-atom information and export it to a file.

The ComputePropertyModifier is not the right tool for that as it can only compute new per-atom properties. When calling export_file() with the "txt" output format, Ovito expects you to specify a list of attributes to export. However, "High_Z" computed by the ComputePropertyModifer will be a particle property, not a global attribute. That's why you see the error.

You need to write a user-defined modifier in Python instead. Here is a draft for a script. Note that I cannot test it myself, because I am on vacation without access to a computer running Ovito:

Code: [Select]
import numpy
node = import_file(...)
def compute_max_z(frame, input, output):
    output.attributes["High_Z"] = numpy.max(input.particles["Position"][:,2])
export_file(node, "max_z.txt", "txt", columns=["Frame", "High_Z"], multiple_frames = True)

A for-loop is not needed in this simple case, because export_file() will automatically step through the animation frames thanks to the multiple_frames=True option. The system will evaluate the data pipeline for every animation frame. As part of a pipeline evaluation, the compute_max_z() function will be invoked by the system, which computes the maximum of the z-component of the "Position" particle property, storing the result in a new output attribute with the name "High_Z".

Dear jatink,

The ObjectNode.output field has been deprecated in Ovito 3.0.0. It's still there for some limited backward compatibility, but It only reflects the output of the data pipeline at frame 0 of the loaded simulation sequence.

Instead of

Code: [Select]
coordinates = node.output.particle_properties.position.array

You should now use

Code: [Select]
data = node.compute(frame)
coordinates = data.particles["Position"]


Support Forum / Re: Steinhardt order parameters
« on: October 05, 2018, 05:08:02 PM »
OVITO doesn’t have a function with this name. I’m not sure what is meant with that. Please let me know where you found the term “bond order parameter analysis”. The I can tell you if it is available in OVITO, perhaps under a different name.

Support Forum / Re: How to get hcp orientation out of quartenions?
« on: October 05, 2018, 04:49:08 PM »
Hi Alex,

Please take a look at this updated version of the PTM doc page:

Peter Larsen (user ‘pmla’ in this forum) has included a table that precisely defines the reference orientation for each lattice type. I’m not sure, but I was convinced that for HCP the reference orientation is indeed defined such that [0001] is parallel to the z-axis.

A possible source of error (please check yourself) may be the representation of quaternions. OVITO employs a (x,y,z,w) representation, but other codes use a (w,x,y,z) representation.

If you want to calculate an average orientation for a crystal, you can do that by computing the arithmetic mean of the atomic quaternions as long as their orientations are not close to a boundary of the fundamental zone, where symmetry flips occur. Currently, OVITO doesn’t provide a function for computing an average orientation from the per-atom orientations which takes into account the lattice symmetries. I hope we can add something like this in the future.

Let me mention that the existing DXA function of OVITO also calculates mean orientations of crystallites as a side product of the dislocation identification. These grain orientations are currently not accessible via the public Python API though. The only way to obtain them is to export the DXA results to a .ca file. Here you will find the mean orientation matrices for each crystallite identified by the DXA.



The problem you encountered in "Phase 1" is due to a typo. You ran the command "tar xzf ovito-3.0.0-dev234-x86_64" to extract the archive file, but forgot the ".tar.gz" file extension. Obviously, there already was an existing subdirectory named "ovito-3.0.0-dev234-x86_64", that's why you got that weird error message.

Running "tar xzf ovito-3.0.0-x86_64.tar.gz" should work. You wrote that you used the flags "xvf" instead. But under Ubuntu Linux, the "z" (uncompress) is option for tar.gz archives, and the "v" flag (verbose mode) doesn't affect the behavior. So "xzf" and "xvf" should lead to the same result.

The Ubuntu package repositories contain an outdated program version of OVITO (v2.3.3), which doesn't fully support the CFG file format. That's the version you had installed initially and it's the one that is invoked when you simply run "ovito" in a terminal or if you use the program menu to start up OVITO. Please uninstall this outdated version, e.g. by running "sudo apt-get remove ovito" or using the Ubuntu software center. 

The latest OVITO versions are only available as archive files that need to be manually downloaded from and extracted. It looks like you accomplished this already, aside from the little problem during the extraction step.


I loaded your file in OVITO 2.9.0 and OVITO 3.0.0-dev, without any problems. Which version of the program are you using?


Support Forum / Re: can ovito movie rendering be paralleled?
« on: September 23, 2018, 07:41:30 PM »
Dear Kyu,

Several computational analysis algorithms are parallelized in OVITO, for example CNA, Compute Property, Wigner-Seitz analysis, and more. They will already make use of all processor cores. Also the Tachyon renderer is multithreaded and will use all cores during image rendering. So there is no point in parallelizing the rendering of a movie across frames.

However, what you can do, if you really want to squeeze out the last bit of performance, is to restrict Ovito (or ovitos) to a single processor core using the --nthreads command line option and run multiple Ovito instances in parallel, letting each instance render a different subset of the animation frames. Finally, you have to manually create a video from the saved animation frames using an external video encoding tool of your choice.

Support Forum / Re: dislocation analysis
« on: September 20, 2018, 11:52:10 AM »
I see. So you actually would like to identify dislocations in a hexagonal lattice.

The DXA function in OVITO does not support any 2D crystals, i.e. sheet-like materials like graphene and your hexagonal lattice. The algorithm was only implemented for three-dimensional crystals such as fcc and bcc, where dislocations are 1-dimensional (line-like) defects.

Identifying dislocation in 2d crystals requires a different method, but happens to be much easier, because here dislocations are 0-dimenesional defects. Here is a paper describing a simple algorithm for finding dislocations in 2d lattices:

I cannot give you a ready-to-use code for this, but it should be relatively easy to implement this algorithm in a Python script. Maybe this is something you can do yourself.

Support Forum / Re: dislocation analysis
« on: September 20, 2018, 10:43:35 AM »
Dear Bahman,

I'm not sure if I understand: What exactly is a "2D fcc model"? Face-centered cubic crystal lattices are by definition three-dimensional.


Support Forum / Re: Save the distance between two particles
« on: September 19, 2018, 09:42:38 PM »

Note that in your Python script you are subtracting two particle identifiers instead of two particle positions:

Code: [Select]
distance = np.linalg.norm( input.particles["Particle Identifier"][655] - input.particles["Particle Identifier"][679] )

The expression "input.particles["Particle Identifier"][655]" gives you the numeric ID of the 655th particle in the particles list. Obviously, it doesn't make sense to subtract two IDs. What you want, is the difference between two particle positions. XYZ coordinates are stored in the "Position" particle property:

Code: [Select]
distance = np.linalg.norm( input.particles["Position"][655] - input.particles["Position"][679] )

But note that this will subtract the position of the 679th particle from the 655th particle. But these are probably not the ones you are interested in. There is a difference between particle identifiers and particle indices. The ID is an explicit property of each particle, which sticks to a particle even if the storage order of particles changes or when you delete some particles. The particle index, on the other hand, is an implicit property since the index only specifies the position of the particle within the current list of particles. If you delete some particles using the Slice modifier or the Delete Selected modifier in OVITO, the indices of the remaining particles typically change, because the indices always form a consecutive sequence from 0 to N-1, where N is the current number of particles.

You can find the particle IDs in the "Particle Identifier" column of the particle data inspector (see your screenshot). Particle indices are shown in the left most column of the table.

(As a side note: The simulation code LAMMPS assigns unique IDs to atoms ranging from 1 to N. But during a simulation run, it tends to reorder particles and when they are written to a dump snapshot, the current ordering is typically random (you can change that behavior using the dump_modify sort command). That's why there is generally no well-defined relationship between the ID of a particle and its index, i.e. its position in the list of particles loaded from the dump file).

You want to compute the distance between the two particles with IDs 655 and 679. However, in Python you can access particles only by index! That means you first have to determine the indices of the two particles before you can access their position vectors. You do it as follows:

Code: [Select]
index1 = np.nonzero(input.particles["Particle Identifier"] == 655)[0][0]
index2 = np.nonzero(input.particles["Particle Identifier"] == 679)[0][0]
distance = np.linalg.norm( input.particles["Position"][index1] - input.particles["Position"][index2] )

Note that the np.nozero() function is the typical Numpy way of finding the first occurrence of a particular value (in this case the ID) in an array. In other words, it searched for the value 655 in the ID array and gives back the 0-based index. This index can then be used to access the corresponding value in the coordinates array.

Support Forum / Re: which gcc is used to compile ovito?
« on: September 17, 2018, 10:59:59 AM »
I think the file you uploaded in the previous comment is included in "lib/ovito/lib" directory.
Yes, thanks for noticing, I almost forgot. The file is indeed included in a subdirectory. For some reason, however, it is not found during the startup process.

There are two more things you could do:

1. Run "LD_DEBUG=libs bin/ovitos". The LD_DEBUG environment setting will produce a lot of output, telling what libraries are being searched and in which locations. It would be helpful if you could pipe the produced terminal output to a file and upload it here.

2. Maybe it helps, at least as a workaround, to preload the sheared library using the LD_PRELOAD option when running ovitos:

LD_PRELOAD=/opt/ovito/ovito-2.9.0-x86_64/lib/ovito/lib/ bin/ovitos

Support Forum / Re: which gcc is used to compile ovito?
« on: September 17, 2018, 09:46:51 AM »
The log output says

Code: [Select]
... (required by /software/centos7/lib64/

This suggests that the library gets loaded during the startup process for some reason. This library module is not included in the standard OVITO installation packages, because I thought it isn't needed by OVITO. But for some reason it is in your case.

Since the module is not included with OVITO, the system version gets loaded, which is not compatible with the other modules from OVITO. That's at least my assumption.

I have attached the matching version of the Qt module from my development machine. Please put it to the others in the OVITO lib directory and see if it gets loaded correctly.

Support Forum / Re: which gcc is used to compile ovito?
« on: September 17, 2018, 08:43:25 AM »
Note that when you run "ldd" from the terminal, the "ldd" command will only look in the system directories for the needed libraries. For example, in your case it finds the libQt*.so libraries installed in "/software/centos7/lib64/" instead of the ones that ship with OVITO, which are located in the "ovito-3.0.0-dev234-x86_64/lib/ovito/" directory. You need to make ldd look in the latter directory by settings the LD_LIBRARY_PATH variable. For example, on my Ubuntu Linux system:

Code: [Select]
stuko@mogli9:~/progs/ovito-3.0.0-dev234-x86_64/lib/ovito/plugins_qt/platforms$ LD_LIBRARY_PATH=../.. ldd =>  (0x00007ffd2216f000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbecd43d000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbecd1fa000) => /nfshome/stuko/progs/ovito-3.0.0-dev234-x86_64/lib/ovito/plugins_qt/platforms/../../ (0x00007fbeccbfa000) => /nfshome/stuko/progs/ovito-3.0.0-dev234-x86_64/lib/ovito/plugins_qt/platforms/../../ (0x00007fbecc626000)

Note that I have added "LD_LIBRARY_PATH=$PWD/../..[/I]" above to let ldd search in the parent directory for .so files. Without that, ldd finds the wrong Qt library versions in the system directory and I get error messages:

Code: [Select]
stuko@mogli9:~/progs/ovito-3.0.0-dev234-x86_64/lib/ovito/plugins_qt/platforms$ ldd
./ /usr/lib/x86_64-linux-gnu/ version `Qt_5.10' not found (required by ./
./ /usr/lib/x86_64-linux-gnu/ version `Qt_5' not found (required by ./
./ /usr/lib/x86_64-linux-gnu/ version `Qt_5_PRIVATE_API' not found (required by ./
./ /usr/lib/x86_64-linux-gnu/ version `Qt_5_PRIVATE_API' not found (required by ./
./ /usr/lib/x86_64-linux-gnu/ version `Qt_5' not found (required by ./ =>  (0x00007fffb198d000) => /usr/lib/x86_64-linux-gnu/ (0x00007fe980c29000) => /usr/lib/x86_64-linux-gnu/ (0x00007fe9809e6000) => /usr/lib/x86_64-linux-gnu/ (0x00007fe98049e000) => /usr/lib/x86_64-linux-gnu/ (0x00007fe97ffc8000)

In your case, the same applies to the library that you copied to the OVITO lib directory. ldd simply doesn't see it and falls back to the system version of libstdc++. That's why you get the error message "./ /software/centos7/lib64/ version `CXXABI_1.3.9' not found (required by ./".

The above only matters when running the ldd command. When running ovitos, the program should automatically make sure that libraries are first searched in the OVITO lib directory. libstdc++ and the libQt5*.so libraries should get loaded on startup. Later, when the platform plugins such as get loaded, the library search path should not matter anymore, because libstdc++ and the libQt5*.so libraries already reside in memory.

The platform plugin is only used when running ovitos in headless mode without an X server, for example when logged into a remote machine via SSH without active X forwarding. The platform plugin will be used instead when running on a local machine with an X display, or when logged in to a remote machine with active X forwarding ("ssh -X").

Qt provides a debugging option, which can provide some additional log output:

Please try running "QT_DEBUG_PLUGINS=1 bin/ovitos" to see if that produces any additional information that can help us understand what is going wrong.

Support Forum / Re: which gcc is used to compile ovito?
« on: September 16, 2018, 11:09:57 AM »
Dear Kyu,

please note following statement on the OVITO download page:

Note to users of RHEL and similar Linux distributions:

In case program startup fails with the error message "ovito: /usr/lib64/ version `CXXABI_1.3.8' not found", please download this version of and copy the two .so files in the lib/ovito/ subdirectory of the OVITO installation. They are required, because the existing version of libstdc++ on your system is not compatible with the OVITO binary.

On your Linux system it may be necessary to install the mentioned libraries to run ovito/ovitos.

I build the official binaries for Linux using gcc 5.1.1 under Ubuntu Linux 10.04.


Support Forum / Re: Steinhardt order parameters
« on: September 15, 2018, 10:44:01 AM »
This is not related to OVITO, but here is a simple C++ code I wrote more than 6 years ago for a review paper which can calculate the Steinhardt parameters (at least some of them):

Support Forum / Re: Steinhardt order parameters
« on: September 15, 2018, 10:39:00 AM »
No, Steinhardt parameter calculation is currently not a built-in function of OVITO.

If you are interested in doing this calculation with OVITO, it would be possible to write a user-defined modifier function in Python that implements the calculation of the Steinhardt parameters. The scripting documentation contains a code example demonstrating the calculation of a local order parameter from the neighbor vectors of an atom, which can serve as a good starting point:

Ovito 3.0-dev:

Ovito 2.9.0:

Support Forum / Re: CNA and bond-angle analysis criterion
« on: September 15, 2018, 08:53:28 AM »
The CNA is essentially based on a per-bond classification. In proceeds in three steps:

1. Generate the network of neighbor bonds, for example using a distance-based cutoff criterion.
2. Compute a triplet of integers for each bond in the network, which represents a fingerprint of the local topology of the network surrounding the bond.
3. Classify each atom based on the types of the bonds it has.

For example, those atoms which have exactly 12 bonds of type "4-2-1" are taken as FCC in the standard CNA method.

What you could do in OVITO is the following: The CNA modifier has a "bond-based mode". When activated, the modifier will skip step 1 above and instead use the existing explicit bond network. For instance, you could create the bonds explicitly by adding the Create Bonds modifier of OVITO before the CNA modifier. Furthermore, the CNA modifier will output the computed triplets for each bond as a new bond property. This gives you the opportunity to perform step 3 in the algorithm above yourself and implement different classification schemes. For this step, you'll have to write a user-defined modifier function in Python which gets executed after the CNA modifier.

I'm not sure how well it will work and what would be a good "relaxed" criterion for FCC atoms. For example, you could require them to have at least eight 4-2-1 bonds instead of exactly 12. It's probably a good idea to first manually inspect the CNA fingerprints computed for the bonds of atoms at the surface for which you think they should be classified as FCC and then derive appropriate criteria from that observation.

Support Forum / Re: Dislocation Analysis- tetragonal
« on: September 13, 2018, 07:41:03 PM »
Dear Bahman,

Currently, the rutile structure is not directly supported by the dislocation analysis function in OVITO. The main reason for it being that we don't have a good crystal structure structure identification method yet for this lattice type. For the dislocation identification to work, the perfect crystal material surrounding the dislocation cores must be properly identified by means of some algorithm.

What you can try though -if the crystal has a well-defined orientation- is to stretch the crystal along the c-axis to obtain a unit cell that is roughly cubic (you can use the Affine Transformation modifier of OVITO for that). Then select the Ti-atoms and apply the DXA dislocation analysis just to the selected atoms, which will look like a bcc lattice.


Support Forum / Re: Python Script Loop
« on: September 12, 2018, 09:57:41 AM »

Here is how it is typically done: Put the existing call to export_file() into a Python for-loop and repeatedly use FileSource.load() to replace the input of the data pipeline with a new file:

Code: [Select]
import os

# ... do the pipeline setup here

for filename in files_to_process:

    # Set a new input file for the current data pipeline:
    node.source.load(filename, multiple_frames = True)

    # Derive the name of the output txt file from the input dump file:
    output_filename = os.path.splitext(filename)[0] + ".txt"

    # Let OVITO do the processing:
    export_file(node, output_filename, "txt",
        columns = ['Timestep', 'Ca_Vac'],
        multiple_frames = True)

The list files_to_process should contain the names of the dump files you want to process.


They are the 4 components of the quaternion used to express the local lattice orientation computed by the PTM modifier for each identified crystal atom. Please see the Wikipedia if you are not familiar with quaternions and how they can be used to express orientations:

The PTM paper mentions a "right-handed orthogonal matrix Q" being computed for each atom, which is basically a 3x3 rotation matrix. In OVITO, this orientation information is translated into the more compact quaternion representation and stored in the "Orientation" output particle property.


Support Forum / Re: Scripting Every Nth frame
« on: September 10, 2018, 03:39:52 PM »
I think the font size of the text label is too large in your case:

Code: [Select]
    font_size = 444.03,

Note that the font_size parameter must be specified as a fraction of the rendered image height. In your case, the resulting characters are so huge that they no longer overlap with the visible viewport region. Rather use a font_size in the range of 0.05 or so.

Support Forum / Re: Scripting Every Nth frame
« on: September 07, 2018, 11:30:50 PM »
I think if you set everyNthFrame to render only every 5th frame, and set dataset.anim.frames_per_second=1, you should get what you want. The frames per second setting determines the playback rate of the rendered video file, irrespective of the everyNthFrame setting. So if you render fewer frames of the animation, it will appear to play faster than if you render all frames.

Support Forum / Re: Scripting Every Nth frame
« on: September 07, 2018, 11:21:37 PM »
This time it's not a bug in Ovito :) It's a typo in your script:

Code: [Select]
dataset.anim.frames_per_second = 2,

Remove the trailing comma at the end of the line. Python interprets this expression as a one-element tuple, not an integer value. See

Support Forum / Re: Scripting Every Nth frame
« on: September 07, 2018, 09:11:06 AM »

Probably this is due to a bug in the old OVITO version, see this discussion thread:

Maybe it helps to insert a call to Viewport.zoom_all() right before rendering the animation.


See this part of the documentation:

In your particular case:

Code: [Select]
from ovito.vis import TextLabelOverlay
from PyQt5 import QtCor

overlay = TextLabelOverlay(
    text = '[SourceFrame]',
    alignment = QtCore.Qt.AlignRight ^ QtCore.Qt.AlignBottom,
    offset_y = 0.1,
    font_size = 0.03,
    text_color = (0,0,0))

Support Forum / Re: Scripting Every Nth frame
« on: September 06, 2018, 06:34:20 PM »

The answer depends on which version of OVITO you are using. In the old 2.9.0 release, there has been an undocumented parameter in the RenderSettings class, which you can set, e.g.

Code: [Select]
render_settings.everyNthFrame = 5

If you already switched to OVITO 3.0.0-dev, the new Viewport.render_anim() method provides the every_nth keyword parameter.


Support Forum / Re: CNA and bond-angle analysis criterion
« on: September 04, 2018, 02:01:14 PM »
Dear spar,

The CNA and the bond-angle analysis (also known as Ackland-Jones structure identification method) both use fixed rules for identifying crystalline and fully coordinated bulk atoms. There is no way to change these rules without touching the source code of the actual algorithm.

The CNA, for example, requires an atom to have 12 nearest neighbors to be identified as FCC. Additionally, these 12 neighbors must be arranged in a particular way. In other words, the coordination number is not the only criterion used in the CNA.

If you are interested in identifying surface atoms just by the number of neighbors, you can do that in OVITO using its Coordination Analysis modifier, which counts the number of atomic neighbors within a given spherical range, followed by an Expression Selection modifier. The latter lets you select those atoms which have a coordination number within a certain range.

More sophisticated identification and selection schemes are possible to catch specific surface atoms. For example, you could combine the CNA and the coordination analysis. First use CNA to identify and select the bulk FCC atoms, then use the Expand Selection modifier to select their nearest neighbors and refine the selection based on the computed coordination numbers.

I am not sure what you are looking for exactly. If possible, please specify more precisely what you would like to do.


Support Forum / Re: Sum of spatial Burgers vector
« on: September 03, 2018, 10:08:37 AM »
Dear SC,

It is not clear to me what the physical meaning of the quantity is that you are asking for, but in principle ispossible to calculate it using OVITO's scripting capabilities. For example, you could insert the following user-defined modifier function into the data pipeline to analyze the results of the DXA modifier:

Code: [Select]
import numpy as np
def modify(frame, input, output):
    total_b = np.zeros(3)
    for segment in input.dislocations.segments:
         total_b += segment.spatial_burgers_vector

This function simply computes the vector sum of the Burgers vectors of all spatial dislocations. Note however that this approach ignores the line sense of the dislocations, which may vary from line to line (as will the sign of the Burgers vector). So the Burgers vector summation doesn't make much sense, unless you know that all lines are pointing in the same direction.


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