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 ... 22
Support Forum / Re: Problem of launching OVITO 2.9.0 on Centos 6.4
« on: August 26, 2019, 01:26:31 PM »
This is the updated link for downloading the shared libs needed by Ovito 2.9.0 on older Linux distros:


« on: August 16, 2019, 11:13:27 PM »
Dear Al,

What do you think yourself would be an appropriate strategy to apply here? Replace each molecule with a virtual atom positioned in its center of mass and then run the CNA or PTM analysis on these virtual atoms?

This would probably require some Python coding. A simpler strategy would be to pick one particular (physical) atom out of each molecule and run the structure analysis on these selected atoms. But this wouldn't be as precise as the center-of-mass approach, I guess.


Hi Mike,

If your particle's largest diameter is smaller than half of the simulation box size, then you can apply the minimum image convention and do the following:

In a first step, you determine the current center of mass of the particle. Instead of simply calculating the sum of all atom position vectors (and dividing by the number of atoms), you need to calculate the sum of all vectors from some reference atom in the particle (it doesn't matter which one) to every atom of the particle. Each of these vectors needs to be wrapped around if it is longer than half the box size. Thus, you need to extend your Python script accordingly.

In the second, once you have the center of mass, you are going to calculate the vectors from the center of mass to each of the atoms. Here, again, you need to wrap around the computed vectors in case the span more than half the box size (which indicates that the atom is on the opposite side of the box from the center of mass).

Does that make sense? If not, let me know.


Support Forum / Re: Batch processing of xsf files to render isosurfaces
« on: August 09, 2019, 02:03:27 PM »
Ah ok, then this was a misunderstanding.

You've attached two pictures to your previous post. Note that they are identical. I am wondering if your intention was to show the different outcomes from GUI and script?

Support Forum / Re: Batch processing of xsf files to render isosurfaces
« on: August 09, 2019, 01:46:25 PM »
I don't see a reason why the isosurfaces should come out differently in the GUI and the scripting interface. At last not if you use the exact same isolevel value. Two slightly different values, like +0.0001 and -0.0001, can make a big difference though if the distribution of field values is very narrow. In your case the histogram shows that the distribution is very narrow indeed. The vast majority of values is very close to zero. Thus, the generated isosurface will be very sensitive to small changes in the isolevel parameter.

You can access the field values loaded from the XSF file as follows:

Code: [Select]

This expression gives you a Numpy array containing the values of all grid cells. Use it to analyze the value distribution or compute the isolevel dynamically in your script.

Support Forum / Re: Batch processing of xsf files to render isosurfaces
« on: August 07, 2019, 06:01:43 PM »
Hi Chris,

Please excuse the late response. We have been busy these days with launching our new website.

I have compiled a Python script for you below, which is supposed to demonstrate how the various tasks you listed can be accomplished.
I think most of the steps are self-explanatory. But of course you can ask further questions if you have any.


Code: [Select]
# Import OVITO modules.
from import *
from ovito.modifiers import *
from ovito.vis import Viewport
import math

# Import NumPy module.
import numpy

pipeline = import_file("CO_homo.xsf")

# Get access to the loaded data:
source_data =

# Hide simulation box:
source_data.cell.vis.enabled = False

# Configure visual representation of oxygen atoms:
type_O = source_data.particles.particle_types.type_by_name('O')
type_O.radius = 0.8
type_O.color = (0.2, 0.2, 1.0)

# Add modifier that creates bonds between atoms.
modifier = CreateBondsModifier(cutoff = 2.0)
# Configure the BondsVis element:
modifier.vis.width = 0.3

# Add modifier that creates an isosurface.
modifier = CreateIsosurfaceModifier(isolevel = 0.016, property = 'G98CUBE')
# Configure the SurfaceMeshVis element:
modifier.vis.surface_transparency = 0.5

# Render an image:
vp = Viewport()
vp.type = Viewport.Type.Perspective
vp.camera_pos = (-100, -150, 150)
vp.camera_dir = (2, 3, -3)
vp.fov = math.radians(60.0)
vp.render_image(size=(800,600), filename="figure.png", background=(1,1,1), frame=0)

Support Forum / Re: Output the shear strain increment
« on: August 05, 2019, 11:19:59 AM »

Right, even with the start_frame option, the export fails with the same error. That's not how it is supposed to be.

I checked the source code of the export_file() function in Ovito 3.0: The function seems to still evaluate the data pipeline at frame 0. I will fix this bug as soon as possible. In the meantime you can work around the problem by patching this Python file of Ovito:

Comment out line 167 of the file /python/ovito/io/

Code: [Select]

Depending on your platform, you can find the Python file in different locations. See the table at the end of this section in the manual.

Support Forum / Re: Possible to embed OVITO in PyQt GUI?
« on: August 05, 2019, 09:19:53 AM »
Hi Anne,

I've now extended Python programming interface of OVITO by adding the new Viewport.create_widget() method (still undocumented). It allows creating a QWidget from an existing Viewport object, which can be embedded into a PyQt5 user interface. You can find a example script demonstrating this here:

Note however that this will only work when running your PyQt5 application through a standard Python interpreter. Please see this section of the user manual how to make the Ovito modules available in a standard Python interpreter. It typically requires building them from source.


Support Forum / Re: Output the shear strain increment
« on: August 04, 2019, 07:27:12 PM »
Hi Peter,

The export_file() function will try to export all frames of the trajectory by default when called with the multiple_frames option. This includes the very first frame of the sequence (frame 0), for which the incremental atomic strain cannot be computed, because there is no predecessor frame. The evaluation of the data pipeline leads to an error condition, which lets the export_file() function stop immediately.

The solution is to avoid exporting frame 0 of the trajectory. For this, the export_file() function provides the start_frame optional keyword parameter. See the documentation page. By specifying it with a value of 1, the first frame should be skipped during export.


Support Forum / Re: Possible to embed OVITO in PyQt GUI?
« on: August 02, 2019, 01:04:53 PM »
Hi Anne,

Currently, the Python programming interface doesn't cover the GUI-related functions and classes of OVITO. Even though it is possible to create a Viewport non-visual object from Python, it is not yet possible to create or access a corresponding widget for the viewport that could be embedded in a windowing user interface.

Let me check how much effort it would be to extend the Python bindings of OVITO in such a way that a PyQt widget could be created from a Viewport object. Your requirements seem to be quite simple.

Just a question: Are you running you PyQt GUI application through a standard Python interpreter? Is it possible for you to use the ovitos interpreter instead?


Support Forum / Re: question on V matrix and W matrix
« on: August 01, 2019, 05:28:29 PM »
The Atomic Strain modifier does not assign the identity tensor for good reasons, I think. It rather assigns an invalid deformation gradient tensor to atoms for which it couldn't compute any meaningful results to prevent possible mistakes or confusion on the side of the users, who could accidentally take the identity tensor as a valid output value.

If you really would like to have the identity matrix being assigned to invalid atoms instead of the null matrix, you can do so yourself using the Compute Property modifier. It allows you to overwrite the deformation gradient property of particles which have previously been selected by the Atomic Strain modifier with the 'Select invalid particles' option activated.

Support Forum / Re: question on V matrix and W matrix
« on: July 31, 2019, 03:02:10 PM »
You are talking about the calculation the Atomic Strain modifier performs. Yes, if the atomic neighbor vectors of an atom in the reference configuration are all co-planar, the V matrix will be singular and the calculation of the F tensor cannot be performed for that atom. OVITO will detect this situation and output a zero F tensor in this case. The Atomic Strain modifier provides the "Select invalid particles" option, which is active by default. What it does is select and highlight all atoms for which the V matrix is singular and for which no atomic deformation gradient could be calculated.

Support Forum / Re: Plot the strain distribution of wrinkle
« on: July 31, 2019, 02:55:38 PM »
We need to actually test this, but the PTM function found in the current development build of Ovito 3.0.0 can calculate atomic deformation gradient tensors for graphene structures. It doesn't even require the flat reference configuration for this.

After using the PTM modifier in OVITO to calculate the per-atom elastic deformation gradient tensors for the writers wrinkled structure, you can apply the standard Color Coding modifier to visualize the stain distribution in terms of the individual elements of the local deformation gradient tensor.

Support Forum / Re: alpha render setting while rendering animation
« on: July 30, 2019, 11:18:15 PM »
True, that's a limitation of the Viewport.render_anim() Python function. It should be possible in your case to work around it by calling Viewport.render_image() in a for-loop.

For instance:
Code: [Select]
for f in range(pipeline.source.num_frames):
    viewport.render_image(frame=f, alpha=True, filename='image{}.png'.format(f))

Support Forum / Re: how to calculate the deformation gradient
« on: July 29, 2019, 09:05:02 AM »

Please see the references given at the bottom of this page from the Ovito documentation:

Another description of the calculation procedure can be found here:


Support Forum / Re: VTK mesh transparency from python script
« on: July 25, 2019, 09:24:27 AM »
Hi Marco,

This requires a yet undocumented part of the Python API, but here you go:

Code: [Select]
# OVITO 2.9.0:
node2.source.objects[0].display.transparency = 0.5

# OVITO 3.0.0-dev:[0].vis.transparency = 0.5


Support Forum / Re: Steinhardt order parameters
« on: July 22, 2019, 11:22:10 AM »
Which Ubuntu package containing the Boost library did you install? I think you'll need the "libboost-program-options-dev" package to build the ASAP code under Ubuntu.

Support Forum / Re: Incuding Python dev in the ovito distribution
« on: July 20, 2019, 05:40:05 PM »
Hi Linyuan,

Yes, I will see if we can do that. On which operating system do you use Ovito?


Dear DJing,

Ovito doesn't have a function for this specific type of interface analysis, it only provides general visualizations functions for plotting per-atom vector quantities that have been calculated by other means. I'm not sure which other codes/tools are publicly available that support the calculation of interface disregistry vectors. I think it's best if you contact authors of papers that contain this type of analysis and ask them how they did it.


Support Forum / Re: molecular surface mesh
« on: July 16, 2019, 10:59:14 AM »
Hi Matteo and Popperoga,

Yes, the surface construction method currently implemented in Ovito differs from the usual approaches you find elsewhere. It treats the atoms always as point-like and their radius property is ignored. The only input aside from the atomic positions is the size of the rolling probe sphere. So this approach is not really suitable for measuring molecular surface areas, I agree.

We currently don't have other surface measurement tools in Ovito, but that is something we could work on in the future. Thanks for sending the reference to the 1983 paper. I will take a look and see how much effort it would be to integrate something like this in Ovito.

My understanding is that there are two general classes of surface analysis algorithms: The first type of algorithm just measures the accessible surface area of an atomic structure, e.g. using a stochastic Monte Carlo sampling technique, but doesn't actually construct a geometric representation of the surface. The second class of algorithm generates a visual model of the surface in the form of a triangulated surface mesh, which can be used to measure its area but also to visualize the surface. Which of these capabilities are relevant in your particular case?


Support Forum / Re: amorphous structure for iron in radiation damage
« on: July 11, 2019, 09:12:49 AM »

No, that statement would not be right in general. The common neighbor analysis will only mark those atoms as 'BCC' that have 8 nearest neighbors and 6 second nearest neighbor atoms positioned on lattice sites. All other atoms will be marked as 'Other'.

For example: If there is a vacancy in your crystal, which is quite common in irradiated materials, all the surrounding 12 atoms will be marked as 'Other', because they are all missing at least one neighbor atom. The material surrounding the vacancy is not amorphous, it's still a crystal but a defective one.


Support Forum / Re: Trajectories selection modification
« on: July 10, 2019, 02:05:20 PM »
Hi Rafael,

You mean to select atoms that enter a spatial region at least once throughout the simulation, i.e., whose trajectory lines intersect the region?


Support Forum / Re: How to visualize bonds?
« on: July 08, 2019, 01:34:41 PM »
No, Ovito currently cannot read "local" style dump files. Only the "atom" and "custom" styles can be read.

The problem is that Ovito cannot know what information the local dump file contains, being it bonds, angles or something else. Furthermore, the meaning of "c_1" is not transparent to Ovito. It cannot know that this is a "compute property/local" yielding the atom indices connected by the bonds.

I am wondering, what is you goal here? Is there a reason why the bond topology is stored in a dump file and not in a data file?

Support Forum / Re: Averaging the strain tensor
« on: July 04, 2019, 07:40:07 AM »
The easiest solution is to make sure the imported atom coordinates are already in unwrapped form. For example, when using LAMMPS to generate dump files, the "xu", "yu" and "zu" fields should be exported.

In case you have already run your simulation and it is too late to do this, you need to use OVITO's "Unwrap Trajectories" modifier, which is only available in the latest development build of OVITO 3.0.

This modifier can either make use of the image flag information (ix,iy,iz) to unfold the trajectories -if these fields are present in the dump file-, or it can try to detect crossings of the periodic boundaries by analyzing the trajectories for discontinuities.

See here for more information:

You need to insert the Unwrap Trajectories modifier into the data pipeline before your user-defined modifier function for computing the center of mass.

Support Forum / Re: Tio2 mechanical analysis
« on: July 02, 2019, 02:41:29 PM »
Dear Baham,

Yes, Ovito's dislocation analysis function is not working for TiO2 Anatase crystals, mainly because there is no structure identification algorithm (such as CNA or PTM) available that could handle this structure type. Extending the capabilities of Ovito in this direction is an ongoing effort.


Support Forum / Re: minimum distance between two atoms
« on: June 26, 2019, 07:18:06 AM »
Hi Dori,

This can probably be implemented using a small Python modifier function. Do you mean the minimum distance between any two atoms in you super cell or a particular pair of atoms?


Support Forum / Re: Averaging the strain tensor
« on: June 24, 2019, 02:47:14 PM »
Yes, the global attribute 'SelectExpression.num_selected' will reflect the changing number of atoms in your region, not the initial number at time 0. This is because the FreezePropertyModifier only freezes the selection state of the individual atoms but not the global value of the attribute dynamically set by the SelectExpressionModifier. What the FreezePropertyModifier, coming after the SelectExpressionModifier in the data pipeline, does is to overwrite the changing selection state of atoms with the saved original state. But it does not do that the same for the 'SelectExpression.num_selected' attribute.

Thus, if you need to know many atoms are selected, you can either use the value of 'SelectExpression.num_selected' at frame 0, or count the number of atoms yourself that are part of the selection set, i.e. by considering the values of the 'Selection' particle property. 

Furthermore, let me point out that you script keeps adding modifiers to the pipeline in a for-loop. This is a typical mistake and is not how it should be done. Instead, you should create and insert all modifiers only once in the beginning before entering the for-loop. Inside of the for-loop, you should only make calls to node.compute() or change the settings of existing modifiers in the pipeline. Otherwise you pipeline will become longer and longer with each iteration of the for-loop.

Support Forum / Re: Averaging the strain tensor
« on: June 23, 2019, 02:40:56 AM »
On the Python side, particle properties such as the 'Strain Tensor' property appear as two-dimensional Numpy arrays containing all the tensor components.  Thus, you should instead use the following code to access the six components of the symmetric strain tensor:

Code: [Select]
StrainTensor = input.particle_properties['Strain Tensor'].array
StrainTensor_XX = StrainTensor[:,0]
StrainTensor_YY = StrainTensor[:,1]
StrainTensor_ZZ = StrainTensor[:,2]
StrainTensor_XY = StrainTensor[:,3]
StrainTensor_XZ = StrainTensor[:,4]
StrainTensor_YZ = StrainTensor[:,5]

Support Forum / Re: Periodic Images in GSD file
« on: June 23, 2019, 02:31:03 AM »
I'm not sure, but to me it looks like the 'particles/image' array in the file 'Homopolymer.gsd' contains only information for frame 0 of the trajectory. Thus, the GSD file reader assumes it is a static particle property that doesn't change with time. This leads to wrong results when the Unwrap Trajectories modifier uses the information to c compute unwrapped coordinates. The periodic image property read from the GSD file should change every time a particle crosses a periodic boundary in the simulation.

Did I get this wrong? Isn't the periodic image property supposed to change with time?

The 'Calculation Results text file' export format is for outputting global quantities only, not per-atom information. Please pick an atomistic file format, e.g. XYZ, to export per-atom data.

Pages: [1] 2 3 ... 22