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 ... 11 12 [13] 14 15 ... 18
Support Forum / Re: Cluster Analysis with WS Analysis
« on: October 11, 2017, 08:49:30 AM »
I tested your first script. It seems to work correctly.

Since there is no loop over the frames in the cascade simulation, the first script so far only analyses the very first frame. Assuming there are no defects yet at the beginning of the simulation, you only get a single number as output. This number is the number of atoms with cluster ID 0. Any atoms that are not selected get assigned to this special cluster by the ClusterAnalysisModifier. They are all non-vacancy sites.

Let's now add a loop over the frames of the simulation:

Code: [Select]
from import *
from import *
from ovito.modifiers import *
import numpy

node = import_file("cascade.dump",multiple_frames = True)

# Perform Wigner-Seitz analysis:
ws = WignerSeitzAnalysisModifier(
    per_type_occupancies = False,
    eliminate_cell_deformation = True)

# Select vacancies (occupancy = 0)
select_vacancies_mod = SelectExpressionModifier(expression = 'Occupancy==0')

# Cluster vacancies
node.modifiers.append(ClusterAnalysisModifier(cutoff = 4.595, sort_by_size = True,only_selected=True))

for frame in range(ovito.dataset.anim.last_frame + 1):
output_filepath = "cluster_sizes.%i.txt" % frame
output = node.compute(frame)
cluster_sizes = numpy.bincount(output.particle_properties['Cluster'].array)
numpy.savetxt(output_filepath, cluster_sizes)

Here are a few points that I have corrected in your version of the script with the for-loop:

  • Do not call node.compute() until you are done populating the node's pipeline with modifiers. The compute() function evaluates all modifiers currently in the pipeline. You only need to call it once before you are going to access the final computation results.
  • Do not add modifiers to the pipeline inside the for-loop. Any call to node.modifiers.append() will add another modifier to the pipeline. If you do this n times, you will end up with a pipeline containing n copies of the SelectExpressionModifier and the ClusterAnalysisModifier and OVITO will perform the clustering computation n times when you finally call compute() (That is n-1 times more than necessary). The correct way is to insert these two modifiers before the for-loop just once.
  • You script called compute() on the currently selected node in the scene (ovito.dataset.selected_node). However, there is no selected node, because you never added a node to the scene in your script. The solution is to simply call node.compute(), i.e., on the ObjectNode referenced by the script variable node.

Version dev39 for Linux is now available for download. Please use this one for testing.

Please wait a moment. I was notified yesterday that the dev38 build for Linux is broken (some missing libraries etc). I am fixing it at this moment.

The Wigner-Seitz routine has been parallelized now and makes use of all processor cores. Please try the new test build dev38.

(And this one should also work for up to 2 billion atoms)

Yes, OVITO and ovitos can read binary LAMMPS dump files. But I recommend the NetCDF format as a much better alternative. See the dump netcdf command of LAMMPS. Ovito/ovitos can read this format, and soon will be able to write it as well.

I have created an issue to track these two topic:

Support for >2 billion atoms:

Improving WS analysis performance:

Support Forum / Re: Tolerance of structure detection
« on: October 04, 2017, 04:48:07 PM »
The identification method used by the "Identify diamond structure" modifier is directly based on the adaptive common neighbour analysis method (see user manual for details and the paper linked therein). This method is by design parameter-free (which can be seen as an advantage). There is no tolerance parameter that would allow you to accept more distorted structures.

The only identification method in OVITO which has a tolerance parameter is the Polyhedral Template Matching method. But this one, in its current form, cannot identify diamond structures.

I don't know what exactly you want to archive, but perhaps it is sufficient in your case to identify diamond structures just by means of coordination number. You could use OVITO's coordination analysis modifier and subsequently select all atoms with exactly 4 neighbours and mark them as "diamond" atoms.

Best regards,

If 6 configurations take about 7 hours, this makes about 1 hour per dataset. How many atoms does your dataset comprise?

The WS analysis consists of four steps:

1. Loading the displaced configuration from disk
2. Loading the reference configuration from disk
3. Building the hierarchical nearest-point-search data structure
4. The query phase, where physical atoms are assigned to their nearest reference site

We'll have to do some profiling to find out how long these individual steps take. The first step can be timed by adding a print statement after the import_file() call in the Python script. Step 2 takes the same amount of time as step 1. For profiling steps 3 and 4 I'll have to amend the code a bit.

None of these steps is currently parallelized. Step 4 could be made parallel, but this would probably increase the memory footprint. Whether it is worth the development effort depends on the profiling. Steps 1 and 2 can be speed up considerably by using a binary file format such as NetCDF instead of text-based dump files.

Hi Christophe,

There is no problem with your script. The current LAMMPS dump file reader still contains a check on the number of atoms which prevents loading files with more than 10^9 atoms. This sanity check was written 9 years ago, in times when multi-billion atom simulations were far less common (and visualising dataset of this size on a desktop computer virtually impossible anyway).

I just made changes to the code to push this limit to 2^31 atoms. This, however, is the current hard limit of OVITO's internal data model. It uses 32-bit values to store integer particle properties including the atom IDs. I will extend the data model in the coming weeks or months to further push the internal limit to 2^63 atoms or so, but this will require significant development work and testing. I acknowledge that analysing large multi-billion datasets will soon become a common practice, even before graphics hardware catches up to make the visualization possible.

Please stand by until I release a new dev build next week, or pull and build the updated sources from Gitlab yourself if you need to process your >1e9 dataset immediately.


Support Forum / Re: Undefined reference to BZ2_bzDecompress
« on: October 04, 2017, 11:36:06 AM »
I'm not entirely sure where this error is coming from. OVITO doesn't use the bzip2 library, but it might be an indirect dependency of the libav video encoding library.

Please try adding these two lines to the file src/core/CMakeLists.txt:

Code: [Select]

They should be inserted anywhere after line 129 starting with "ADD_LIBRARY(Core..."
Then run make again.

Best regards,

Support Forum / Re: Voronoi analysis modifier doesn't seem to work?
« on: October 02, 2017, 05:18:35 PM »
The "Calculation results text file" format is only for exporting global quantities (e.g. the total count of some sort of atoms), but not for per-atom data. For the latter you need to use an atomistic file format such as XYZ.

You can export only a subset of atoms to an XYZ file. For this you need to do two things: First select atoms which you don't want to export (e.g. using the Expression Select modifier), then remove them by applying the Delete Selected Particles modifier. Only the remaining atoms will be exported.

Note that there is also a Invert Selection modifier in case it is easier for you to select the atoms you want to export.

The Expression Select modifier has another function: It outputs the number of selected particles (e.g. those fulfilling your criterion) as a global attribute. This value can be exported to a text table file using the "Calculation Results Text" format (typically as a function of simulation time).

Support Forum / Re: Voronoi analysis modifier doesn't seem to work?
« on: September 29, 2017, 10:23:53 AM »

The computation results are there, but they are not immediately visible. You need to take some actions.

After the Voronoi modifier has done its work (which should be the case, unless there was an error message), the computation results are stored as new per-atom properties and will be available for further processing or visualization steps.

To see what properties an atom currently has, position the mouse cursor on the atom and OVITO will displays the information in the status bar. Or better: Use the Particle Inspection Utility.

Now you have several ways to use the computed information. For example, you could use the Color Coding modifier of OVITO to visualize the atomic volume with a color that is assigned to each atom. Or you could use the Expression Select modifier to select certain atoms with a specific type of Voronoi index and highlight or count them. Or you could simply use the Export File function of OVITO to write the computed Voronoi information to an output file.

Support Forum / Re: adding a new particle properties to visualize
« on: September 28, 2017, 11:13:07 PM »
I have to admit that I don't know at all how joblib works and if it is compatible with the ovitos interpreter.

I would simply write two Python scripts: The first script performs the order parameter calculation for a subrange of simulation frames. It is executed by the ovitos interpreter and, let's say, it takes the subrange as command line parameters. It's basically the script that you already have. But instead of looping over all frames, it only loops over a specified interval [a,b] of frames.

The second script is a standard Python script and divides the total simulation sequence into a given number of subranges. For every subrange it spawns a separate instance of the ovitos interpreter and runs the first script. This can be done using the os.system() function or Python's subprocess module.

Perhaps there are Python packages out there that can do all of this for you, I don't know.

Support Forum / Re: How can I adjust the font of ovito?
« on: September 27, 2017, 07:55:35 PM »
OVITO itself doesn't provide any controls for the font size used in user interface elements. Normally, it should automatically follow the font settings of the operating system.

Could you please post a screenshot? I am wondering if the text appears smaller than normal on your system.


Support Forum / Re: WS Analysis on system that is moving
« on: September 27, 2017, 01:26:57 PM »
Just as an addition to my previous description of the WS defect method: The OVITO user manual contains an illustration of the method, which might help understanding it:

Support Forum / Re: How to export the CNA value for each atom?
« on: September 26, 2017, 09:41:12 PM »
  • Select "Export file" from the File menu.
  • Choose the output file format ("LAMMPS Dump File") and a filename.
  • Check the particle properties to export. You want to export at least the "Structure Type" property, probably "Position.X/Y/Z" as well.
See also:

Support Forum / Re: WS Analysis on system that is moving
« on: September 26, 2017, 05:53:38 PM »
Yes, the high number of defects you describe sounds like an artefact of the WS analysis.

It is easy to demonstrate, as an example, that the WS analysis reports a large number of Frenkel pair defects for a perfect crystal if you rigidly shift that crystal lattice by some amount. Once the atoms lie halfway between two reference lattice sites, then they will be randomly assigned to either of the sites. Then you get a lot of sites with zero occupancy and interstitial sites.

According to the WS analysis, a vacancy is a site with no physical atom being closer to that site than to any of the other sites. One can describe this method also in terms of the Voronoi tessellation. Each site has a Voronoi cell around it, with the Voronoi faces being located halfway between the site and its neighbors. The WS analysis counts how many physical atoms are located in each Voronoi cell. Those sites whose Voronoi cell contains no atoms at all, are called vacancies.
Note that there is no threshold parameter that would control how far an atom can move away from its site before it is counted as a defect. The WS analysis is a parameter-free method. An atom may be counted as a defect as soon as it gets closer to a neighbouring site than to its original site.

So, for the WS analysis to work correctly, it is important that perfect crystal atoms are still remain close to the center of the Voronoi cell (i.e. close to the original site locations). If all the atoms somehow get shifted toward the borders of their Voronoi cells, then they might spuriously be assigned to the cell of a neighbouring site, especially if they are also subject to thermal vibrations.

Thus, its important to make sure that the crystal lattice does not drift as a whole during the simulation. Furthermore, it's important to make sure the crystal does not expand or contract, because that would also push atoms away from their original locations. To partially mitigate this type of problem, the WS modifier provides an option to rescale the expanded simulation cell, including all contained atomic coordinates, to the size of the reference cell.

Regarding your script:

The offset that you apply to the atomic positions has no effect, because it happens after the WS analysis is performed. You apply to modifiers, the WignerSeitzAnalysisModifier and the PythonScriptModifier, in that order. When the PythonScriptModifier moves the atoms, the WS modifier will not see it. You need to move the atoms with a modifier that is inserted before the WS modifier. If you don't want to use another PythonScriptModifier for this, you can also use a AffineTransformationModifier to translate all atoms by a uniform offset.

Support Forum / Re: adding a new particle properties to visualize
« on: September 25, 2017, 07:36:01 AM »

Note that the script I posted is meant to be run from the terminal with the 'ovitos' script interpreter. See for more information. The script takes care of importing the input data and writing out the results to an output file without any user interaction.

If instead you want to interactively use the order parameter calculation from within the graphical version of OVITO, you need to change the script. You need to remove the calls to import_file() and export_file()  (because we assume that you load a dataset in OVITO interactively).

Furthermore, you need to remove the call to node.modifiers.append() and rename the Python function to the standard name "modify". You then manually insert a Python Script modifier into the pipeline into the data pipeline and copy/paste the script code into the editor window.

If your simulation is big and you have a large number of frame to process, it's probably better to stick with the non-interactive batch script approach though. Currently, OVITO doesn't allow you to parallelize over simulation frames, because Python scripts are always executed in the main thread. If you want to speed things up, you need to invoke multiple instances of 'ovitos' and split up the simulation sequence into subranges and process them in parallel.

Support Forum / Re: Bug: Isosurfaces and Show Periodic Images
« on: September 23, 2017, 08:04:10 PM »
Here is a quick update on this topic:

The new development version of OVITO provides improved handling of periodic images. The Show Periodic Images modifier has been renamed to Replicate modifier and can now replicate (iso)surfaces as well as voxel data grids (e.g. charge density grids) in addition to particles/bonds. Furthermore, surfaces now carry their own periodic domain information, which is independent of the master simulation cell. So changing the cell dimensions no longer screws up the surface.

Support Forum / Re: Unable to create animation
« on: September 23, 2017, 02:04:54 PM »

QuickTime player of macOS cannot play AVI files, at least not those produced by OVITO. Perhaps it can play others when they use a different codec, I'm not sure. You have two options: Let OVITO write movies in the MOV or MP4 format instead. Those can be played back with QuickTime Player. Or use a different player app such as VLC, which can play the AVI files generated by OVITO.


Support Forum / Re: How to add colorbar in Python script?
« on: September 21, 2017, 11:35:41 AM »
Just to let you know: Python bindings for the color legend are now included in the newest preview release of OVITO. See


Support Forum / Re: Construct surface mesh
« on: September 21, 2017, 11:33:32 AM »
I have made a new development preview release of OVITO available:

It provides a greatly extended version of the Python class that allows you test whether a spatial point is inside the region enclosed by the surface or not. See

In principle, this allows you to perform the type of counting you have in mind using OVITO's scripting interface. It would be possible to write a custom modifier in Python that performs the point-in-surface test for all H-atoms and outputs the count as a new global attribute, which can be exported to a text file.

Support Forum / Re: adding a new particle properties to visualize
« on: September 19, 2017, 05:34:45 PM »

Here is a sketch of a working analysis script for OVITO based on your first draft. Please ask if you need further explanations.

Code: [Select]
from import import_file, export_file
from ovito.modifiers import PythonScriptModifier
from import *
import numpy as np

# Load input simulation file.
node = import_file("/Users/stuko/prj/ovito/examples/data/NanocrystallinePd.dump.gz" , multiple_frames = True)

# Control parameters:
N = 14; N1=8; d1=2.8*np.sqrt(3)/4; d2=2.8

# Define the analysis modifier function:
def calc_order_param(frame, input, output):

    print("Calculating order parameters for {} atoms at frame {}".format(input.number_of_particles, frame))

    # Initialize neighbor finder object.
    # Visit the 14 nearest neighbors of each particle.
    finder = NearestNeighborFinder(N, input)
    # Create output particle property (using DataCollection.create_user_particle_property() method):
    order_param_property = output.create_user_particle_property("order_param", "float")
    # Get a writable Numpy array, which will allow us to set the stored property values:
    order_param = order_param_property.marray

    # Loop over all input particles:
    for index in range(input.number_of_particles):
        d = 0.0
        # Iterate over the neighbors of the current particle, starting with the closest:
        # We use Python's enumerate() here to count up 'i' as we iterate over the neighbors.
        for i, neigh in enumerate(finder.find(index)):
            if i < N1:
                d += (neigh.distance-d1)**2
                d += (neigh.distance-d2)**2
        order_param[index] = d / N

# Plug analysis function into OVITO's data pipeline:
node.modifiers.append(PythonScriptModifier(function = calc_order_param))

# Export results to an output file (processes all input simulation frames):
export_file(node, "output.dump",
format = "lammps_dump",
columns = ["Position.X", "Position.Y", "Position.Z", "order_param"],
multiple_frames = True)

Support Forum / Re: Construct surface mesh
« on: September 14, 2017, 03:57:23 PM »
No, that is not supported. But it is likely that the next major OVITO release 3.0 will allow you to do this using the Python interface.

I am wondering why you need to determine this number. Under normal circumstances the Construct Surface Mesh function generates a surface that encompasses all input atoms. If some atoms are still outside of the generated surface, this typically is a sign for the probe sphere radius being too small.

Support Forum / Re: segmentation fault
« on: September 05, 2017, 10:10:02 AM »

i haven't seen this kind of program crash before. The segmentation faults occurs on application startup, inside a function of the Qt library, when OVITO tries to contact the update notification server at This part of the program has not been changed for a long time, so it's not surprising that the crash is independent of the OVITO version in use. On the other hand, it remains unclear why you observe this crash now, and never before.

The stack trace indicates that the crash happens in a function named PAC::PACClient::invokeClientCallback(). PAC stands for proxy auto-config. So perhaps you have recently set up the use of a proxy server in the network settings. The error might be related to this bug in the Qt library: But that is only a guess.

You should try this newer build of OVITO 2.9.0, which was compiled against a more recent version of the Qt library:

Perhaps it already fixes the issue. Let's keep our fingers crossed.


Support Forum / Re: WS Analysis on system that is moving
« on: September 01, 2017, 06:30:30 PM »
Here is a sketch for a Python modifier function:

Code: [Select]
from import ParticleProperty

def modify(frame, input, output):
    old_pos_property = input.particle_properties['Position']
    old_pos = old_pos_property.array

    # Somehow compute 'shift_vector' from the current positions...

    # Compute new positions by subtracting the same shift vector from all current positions:
    new_pos = old_pos - shift_vector

    # Output the coordinates as 'Position' particle property, effectively replacing old property:
    output.create_particle_property(ParticleProperty.Type.Position, data=new_pos)       

Support Forum / Re: WS Analysis on system that is moving
« on: September 01, 2017, 06:24:00 PM »
Yeah, that is the tricky part. Some atomic coordinates might wrap around when they cross the periodic boundaries of the box. This makes the calculation of the COM difficult. You are using PBCs, right?

A strategy to deal with this could be to use only a subset of atoms and exclude atoms from the COM calculation that might cross a boundary.

Support Forum / Re: WS Analysis on system that is moving
« on: September 01, 2017, 12:05:30 PM »
OVITO doesn't have a built-in feature for eliminating such a drift of the center of mass. But I assume it is not too difficult to write a Python script modifier which does that.

The user-defined modifier function would first have to compute the current center of mass and determine its displacement from the reference position. In a second step, the modifier function would subtract that displacement vector from all atomic positions.

This Python script modifier has to precede the WS analysis modifier in the data pipeline so that the WS modifier sees the corrected atom coordinates.

Support Forum / Re: How could I visualize the decomposed displacement in 3D?
« on: September 01, 2017, 11:55:05 AM »
This is a little bit of work, but it can be done. You have to work around a current limitation of OVITO: It can only visualize one arrow per standard vector property. And in your case there is only one property: the Displacement property.
  • That means, if you want to visualize three vectors per atom, you have to import the entire dataset into OVITO three times (and probably compute the displacement vectors three times as well).
  • You now have three separate objects in your scene. For two of them you can safely disable the display of particles and the simulation cell, but keep the display of displacement vectors enabled for all three.
  • Finally, you have to take care of the decomposition of the displacement vectors (ux,uy,uz) into vectors (ux,0,0), (0,uy,0), and (0,0,uz) parallel to the coordinate axes. I think the easiest way to do this is to use the Compute property modifier in each of the three data pipeline. With it you can overwrite the values stored in the "Displacement" particle property and set individual vector components to zero.
An alternative approach would probably be to write a Python script modifier. The user-defined modifier function could create three new particle properties for the three axis aligned vectors and fill them with the data from the origin displacement vector property. Finally, each new particle property must be associated with a VectorDisplay object to render the vectors as arrows. Note that this approach shows that, in principle, OVITO is capable of rendering multiple vectors per particle, but it requires some 'convincing' .

Support Forum / Re: the display of particle types
« on: September 01, 2017, 11:36:11 AM »
Dear Ouyang,

Yes, Ovito can certainly do what you are looking for.

First, you should insert a Select Particle Type modifier into the data pipeline, followed by a Delete Selected Particles modifier. These two steps allow you to remove atom types of your choice. Note that the two operations are performed dynamically. You can temporarily disable the Delete Selected Particles modifier in the pipeline to bring the hidden atoms back.


Pages: 1 ... 11 12 [13] 14 15 ... 18