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 ... 15
Support Forum / Re: Applying modifier in script
« on: December 14, 2017, 10:47:25 PM »
There are severals ways to solve this. The choice depends on what your ultimate goal is: Do you want to use the computation function from the graphical user interface, from batch processing scripts in the terminal, or both?

On the graphical side, note that OVITO allows you to save multiple modifiers as one preset or "super modifier" (see this page in the manual). Thus, you could let your user-defined modifier function still rely on the bonds created by a standard Create Bonds modifier. If you create a preset for this combination of modifiers, you can insert it from the modifier list with a single click. 

For a pure batch script that is callable from the terminal and executed with the ovitos interpreter, you can also still rely on the standard CreateBondsModifier. Just make sure your batch script inserts it into the pipeline before the PythonScriptModifier. It would roughly look like this:
Code: [Select]
node = import_file("....")

def calc_bisectors(frame, input, output):
    .... # access bonds from the input, store bisectors in the output.

node.modifiers.append(PythonScriptModifier(function = calc_bisectors))
data = node.compute()
... # Process the output data, export to a file, etc.

Finally, the third option is to get rid of the Create Bonds modifier and do the bond vector calculation dynamically in your user-defined function. For this purpose, OVITO provides the CutoffNeighborFinder facility.

Support Forum / Re: Applying modifier in script
« on: December 14, 2017, 05:24:14 PM »
Hi Maurice,

Modifier functions must never ever make changes to the data pipeline they are part of. Keep in mind that the modifier is potentially called many times by the system, every time the data pipeline needs to be evaluated. If the modifier function would change the pipeline in some way, e.g. by inserting an additional modifier, this change would automatically trigger a re-evaluation of the pipeline leading to an infinite update loop.

For this reason modifier functions must be pure functions without side effects. They may only access and modify the data that is being passed to them via the two input/output parameters. Note the distinction that is being made between the different objects: the data pipeline, the modifiers forming the pipeline, and the data that flows through the pipeline from modifier function to modifier function.

Please let me know what your intention is here and I will try to find the right solution. What is your modifier function supposed to do? Obviously you want to create bonds. But for that alone the standard CreateBondsModifier would be sufficient and you wouldn't have to write a user-defined modifier function.


Current versions of OVITO require you to "abuse" one of the standard properties for this, because user-defined particle properties are created without an attached display object. Standard properties that are created with an attached VectorDisplay object are the "Force", "Displacement" and "Dipole Orientation" properties.

That being said, have you already tried creating and assigning a new instance of the VectorDisplay class to the display attribute of the property data object? Perhaps this allows you to activate the visualisation of arrows even for your user-defined property.
For instance, In you modify() function, which creates the "Bisector" property:

Code: [Select]
bisectors.display = VectorDisplay()
bisectors.display.enabled = True

Hi Maurice,

This type of property access


doesn't work for user-defined particle properties, only for standard properties such as "position". In the new OVITO version 3.0 it has been marked as deprecated, even for standard properties (see this page). Instead, use standard Python indexing. That means, use a key string to look up the particle property in the dictionary, i.e.



Support Forum / Re: Creating modifiers
« on: December 12, 2017, 04:26:39 PM »
Note that this example snippet is not a self-contained script. It assumes that you have loaded some data from a file first, as explained earlier in the documentation. See

Calling the import_file() function creates a new ObjectNode object, which is assigned to the "node" Python variable. Later, in the snippet you posted, the new modifier is inserted into the data pipeline of that ObjectNode.

Support Forum / Re: Void in amorphous material
« on: December 10, 2017, 06:20:19 PM »
The Bin and Reduce function can map the per-atom volumes only to a two-dimensional grid of bins, not a three-dimensional one. So averaging will be performed within each bin and along the third axis. I don't know, this may not be the best choice for you problem at hand. It makes most sense for situations that are quasi-two-dimensional.

With the Compute Property modifier you can do a three-dimensional spatial averaging around each atom. Imagine a sphere with a user-defined radius around each atom. The value at every central site is computed as the sum over the values of all atoms contained within the sphere. In a second step, you can divide the summed values by the number of atoms in each sphere, giving you average values.

Support Forum / Re: How to make ovito write data file in a modify way
« on: December 09, 2017, 04:46:22 PM »
Dear Min Shi,

OVITO doesn't provide you control over the output number precision at the moment. I have created a feature request on our GitLab project page for this so that it can be added in the future:

Currently, your only option is to write a short Python script that dumps the coordinate data to a file in whatever format and precision you like. You can then execute that script from the menu in the graphical version of OVITO.


Support Forum / Re: OVITO can't read my simulation output
« on: December 08, 2017, 04:04:26 PM »
I'm not a HOOMD user, so I cannot understand what your statement means. Does it mean that the problem is caused by HOOMD or your simulation control script? Or is there something we can change on the OVITO side to better deal which such data files? If the latter is the case, yes, please post an example file.

Support Forum / Re: OVITO can't read my simulation output
« on: December 08, 2017, 09:06:42 AM »

The GSD/HOOMD file reader in OVITO is still a little rough around the edges and might not be prepared for all corner cases yet. To me that sounds like a bug in the GSD parsing routine, which needs to be sorted out.

I can try to do that. But first I need to understand where exactly the problem is. For that it would be very helpful if you send me one of the files that lead to the error as a test case. 


Support Forum / Re: How can I scale the size of particle?
« on: December 07, 2017, 07:51:04 AM »
Sorry, I still don't understand the problem, I think.

Why can't you just go to the "Particle Types" panel and change the radii of particle types 2-4 to some larger values to make the corresponding particles appear bigger in the viewports?

Support Forum / Re: How can I scale the size of particle?
« on: December 07, 2017, 07:13:35 AM »

OVITO uses the following information to determine the display size for individual particles:
  • per-particle radius (the Radius particle property if present)
  • per-type radius (0 by default; but may be non-zero if the particle type is named after a chemical element; go to the "Particle Types" entry in the pipeline editor to change the per-type radii)
  • global default radius (1.0 by default; can be changed in the particle display settings panel)
I listed the settings in order of priority: If one is 0 or not defined, OVITO falls back to the next in the list when determining the effective display radius for a particle.


Support Forum / Re: solid volume calculated by the Construct Surface Mesh
« on: November 30, 2017, 05:41:04 PM »
Dear Andree,

Thanks for appreciating the work I did with developing OVITO.

The explanation for your observation is this: The solid volume is calculated before the surface smoothing step. Thus, the value is unaffected by the smoothing.

The reason for this choice is that calculating the volume enclosed by an arbitrary triangle mesh is difficult. In contrast, calculating the original volume is easy, because it is simply the union of all Delaunay tetrahedral elements that were classified as 'solid' by the algorithm. In fact, first the volume is determined, and then the surface around it is constructed later.

Why is it justified to use the original volume before smoothing? Because the smoothing procedure is supposed to be volume conserving! In practice it turns out that this is not quite right, but the assumption is that the error is not significant. At least so far it didn't justify the effort it would mean to implement a general volume calculation routine for the smoothed triangle mesh (which can deal with periodic boundary conditions and other difficulties).

Let me know if you have further questions.


Support Forum / Re: Filtering defects by time or frame sequence
« on: November 29, 2017, 02:32:30 PM »
I'm sorry for the delay.

Here is what I had in mind:

Let's say the 'Selection' particle property indicates whether an atom belongs to set 'I' or not, i.e. being an initial defect or not. You can then use the Compute Property modifier to determine for every atom in the system whether it is close to one of the atoms from that set 'I' or not. In order to do that, you need to activate the 'include neighbor terms' option in the Compute Property modifier. You simply enter 'Selection' in the neighbor expression field and choose an appropriate cutoff. You can name the output property 'IsCloseToInitialDefect' to similar. Enter '0' as expression for the center atom.

The new property 'IsCloseToInitialDefect' will be zero for atoms that do not have any selected neighbors and non-zero for atoms which have at least one selected neighbor.

In a final step you can now restrict your set 'N' to atoms having IsCloseToInitialDefect==0.

Support Forum / Re: Python loading error
« on: November 23, 2017, 03:04:51 PM »
I tried to reproduce the error, but so far I did not succeed. I downloaded and ran the Ovito exe installer from the website, opened the Windows command prompt, put the Ovito installation folder into the PATH environment variable and finally executed "ovitos". This worked without a problem for both Ovito 2.9.0 and Ovito 3.0.0-dev62.

Please let us know which version of Ovito you did install.

Perhaps there is some sort of interference from the Anaconda installation on your system. I will try to install Anaconda on my system too to see if that makes a difference.

Note that the Ovito python modules have been compiled for the CPython interpreter that ships with the Ovito installation packages. It's likely that they are not compatible with the Anaconda Python interpreter. That's why your second approach fails.

Support Forum / Re: Dislocation Analysis for Fluorite Structures
« on: November 23, 2017, 09:54:30 AM »
Hi Janel,

Here is what I recommend: Use the Select Particle Type modifier to select the Ca atoms, which form an FCC sublattice. Then apply the DXA modifier and turn on the option "Use only selected particles" and set the crystal structure to "Face-centered cubic".


Pages: [1] 2 3 ... 15