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 ... 20
Support Forum / Re: Can ovito scripting work in Jupyter notebooks?
« on: May 15, 2019, 09:51:49 AM »

Please take a look at this section of the user manual:

We don't have any first-hand experience here with using the Ovito Python modules within Jupyter. But in general there are two possible strategies you can try: Either you keep using the Python interpreter that ships with Ovito ("ovitos") and use pip to install whatever third-party modules you need (e.g. jupyter). Or you build Ovito from source. Then you should be able to use its Python modules from other interpreters. This path is a bit more tricky, because the critical step here is to make sure that Ovito gets built against the right Python interpreter and against the right version of the Qt libraries. It must be same version that is used by the PyQt5 module installed in the same Python interpreter.

Note also that a colleague from Max-Planck-Institute in Düsseldorf has created a Conda package for Ovito 2.9.0:

Support Forum / Re: Request for yum repository
« on: May 14, 2019, 05:10:09 PM »
We provide prebuilt binary packages of Ovito for Linux on our website. So normally there should be no need to build Ovito from source. Please let us know why you would like to specifically have a Yum package of Ovito.

Yes, Ovito 3.0.0 brings several changes in the Python interface.

The RenderSettings class has been deprecated, and its use is discouraged. Instead, simply use the Viewport.render_anim() function.

The RenderSettings class is still available in case you want to keep using it. The "everyNthFrame" field has been renamed to "every_nth_frame".

The documentation of the updated Python interface is still incomplete in some places. In particular the '_' notation is not yet introduced anywhere. Probably it isn't needed anyway in your particular case. Currently, Ovito prevents you from modifying the display radius and color of particle types in the pipeline output. This makes sense, because such a change could cause unwanted side effects. The solution is to instead modify the original data that enters the pipeline. This data is cached by the FileSource object delivering it from the input file. See the documentation of the FileSource. One of the example code snippets demonstrates how to configure the display properties of individual particle types. Hope this helps you solve the problem. If not, let me know.

By the way: I put a new development build of Ovito 3.0.0 online yesterday, which already contains an extension that allows you to control the orientation of the camera's vertical axis:

With that, you no longer have to adjust the global application settings to change the orientation of the box in the rendered picture.

Yes, I just realized that some more extra care is needed in this case. Sorry, for leaving you along with the problem too soon.

First, to find out what the default value of the FOV parameter is, you need to create a Viewport, set its projection type to 'perspective', and then query the current value of the FOV parameter:

Code: [Select]
>>> from ovito.vis import *                                                                                                                                                                             
>>> vp = Viewport()                                                                                                                                                                                     
>>> vp.type = Viewport.Type.PERSPECTIVE                                                                                                                                                                 
>>> print(vp.fov)                                                                                                                                                                                       

The default value is 0.61 (radians), which corresponds to 35 degrees. To zoom in, you should set the FOV parameter to a smaller value, but which is still on the same order of magnitude, e.g. 0.3. Make sure to set the FOV really after setting the projection type, because setting the projection type may reset the FOV value back to its default. Thus, instead of
Code: [Select]
vp = Viewport(type=Viewport.Type.PERSPECTIVE, fov=###)
better do
Code: [Select]
vp = Viewport(type=Viewport.Type.PERSPECTIVE)
vp.fov = 0.3

Note that I haven't tested your code directly. Please check if you can get better results now with the hints I gave. If not, I'll have to take a closer look at your script.

Regarding your second question: No, at the moment there is no way to select which coordinate axis points upward from Python. I will add a corresponding option in a future version of OVITO.


You probably should set the Viewport.fov parameter to a smaller value. This should give you a more parallel type of perspective projection.


Support Forum / Re: animated motion of particles using trajectory line
« on: April 18, 2019, 03:07:00 PM »
Yes, in Ovito 3.0.0-dev, the Generate Trajectory Lines modifier is all what is needed to produce this kind of animation.


Support Forum / Re: error during compilation
« on: April 17, 2019, 06:50:56 PM »
Thanks for letting us know.

Could you please also give us some info on the environment in which you have been building Ovito. Like the OS name and version, and the version of the Libav library on your system.


Support Forum / Re: The DXA misjudges the burgers vector
« on: April 17, 2019, 12:13:06 PM »
Right, I forgot that the Affine Transformation modifier won't act on the dislocations lines. That's a missing feature I might add in a future version of Ovito.

Another option is to use the object rotation tool from the main tool bar, see the attached screenshot. It allows you to rotate the entire model around the coordinate axes.

Support Forum / Re: The DXA misjudges the burgers vector
« on: April 17, 2019, 11:06:49 AM »
There might be another solution, which is even easier than what I have proposed before:

You can apply an Affine Transformation modifier to your model prior to the Dislocation Analysis (DXA) modifier in order to bring the crystal (including the simulation cell) into a different orientation, which shows less spurious symmetry flips. The aim is to (roughly) align the [100] direction of your crystal with the x-axis of the global coordinate system, the [010] direction with the y-axis, and the [001] direction with the z-axis. For this specific crystal orientation, DXA includes extra measures to avoid symmetry flips and should yield a stable crystal lattice orientation.

I don't know the orientation of your crystal, but it shouldn't be too difficult to figure out the rotation matrix that is needed to transform the crystal into the [001] standard orientation. If you like, you can then apply a second Affine Transformation modifier, with a reverse rotation matrix, to bring the crystal and the extracted dislocation lines back into the original orientation after DXA has been performed.

Support Forum / Re: The DXA misjudges the burgers vector
« on: April 17, 2019, 09:59:49 AM »
The two screenshots you posted show only a single dislocation line, so there wouldn't be much to identify. But do you mean you actually have multiple dislocations in your simulation, all with different 1/2<111> Burgers vectors, that you would like to identify?

One way would be to look at the "spatial Burgers vectors" of these dislocations. As mentioned before, these vectors are all expressed in the same static and global coordinate system and are not subject to spurious lattice symmetry flips. However, they are subject to elastic lattice strains, meaning they will never be mathematically exact 1/2<111> vectors. Thus, you will have to apply some rounding procedure to determine the true Burgers vector of each dislocation.

Another possibility is to consider the lattice orientation that has been assigned to the crystal by the DXA. It can be used to detect symmetry flips and transform the crystal orientation (and with it the Burgers vectors of all embedded dislocations) to a specific orientation that you specify. Then you could directly work with the true Burgers vectors of the dislocations. However, this approach is probably more complicated and requires functions from Ovito's Python interface that are not documented. I would have to give you more information about this.


Support Forum / Re: The DXA misjudges the burgers vector
« on: April 17, 2019, 07:39:45 AM »
Dear Peter,

This surprising behavior is not a bug in the DXA and can be explained as follows:

You are dealing with a BCC crystal. Every cubic crystal lattice has 24 equivalent orientations. Thus, given a crystal model that has some orientation in space, you have 24 different ways of defining the axis orientations of the crystal, i.e., the spatial directions of the [100], [010] and [001] Miller indices.

When the DXA sees your input crystal, it will pick one of these 24 physically equivalent rotations at random. It's important to note that the algorithm newly picks the orientation in each simulation frame in an uncorrelated manner, because it doesn't remember which orientation it has used for the previous frame.

So what you are observing is a flipping of the crystal lattice orientation to a different symmetrically equivalent orientation. Even though the dislocation doesn't change in any, the Burgers vector displayed by the DXA apparently does, because it gets expressed in a newly oriented lattice coordinate system.

The column "Spatial Burgers vector" shows that the physical Burgers vector, which is obtained by transforming the calculated true Burgers vector from the lattice coordinate system to the simulation coordinate system, indeed does not change. [2.4739,0.00,0.00] and [2.4739,0.00,-0.00] are essentially the same spatial vector --small numerical errors aside that typically occur due to elastic distortions of the crystal.

The dislocation line changes color, because you selected to color the lines "by Burgers vector" and not "by dislocation type". In the latter mode, the line would probably stay green, because 1/2[111] and 1/2[11-1] belong to the same class of dislocations.

Note that the spurious flipping of the crystal orientation only occurs for certain alignments of the crystal lattice, like in your particular case where the <111> direction is aligned along the y-axis of the simulation coordinate system. For the DXA, this orientation is right on the edge of a standard orientation triangle. So even an infinitesimal reorientation of the crystal into an adjacent standard triangle, which is associated with a symmetry flip of the lattice. Other orientations, which are located more in the interior of the standard triangle, won't show this unstable behavior and DXA will typically maintain the same orientation over time.


Hi Liam,

It is okay to lower the probe sphere parameter somewhat below the recommended value. However, be aware that the surface construction is not made to detect very small voids. With 'small' I mean a size on the order of one or two vacancies (note that vacancies can easily form during dislocation plasticity). If you lower the probe sphere radius, at some point the algorithm may start to detect holes in the material that are actually single vacancies or a pair of them. However, whether it detects them or not will depend on the details of the local atomic configuration, thermal displacements, elastic strains, etc. Sometimes you will be lucky, sometimes not. In other words, it's not really a good analysis tool in this size regime.

I would crosscheck whether the defects marked by the Construct Surface Mesh algorithm are indeed voids. Use, for example, the Polyhedral Template Matching function in combination with Select Type and Delete Selected modifiers to filter out all perfect FCC atoms. Then inspect the local defect configurations around the "void" identified by the Construct Surface Mesh modifier to see how big they actually are in terms of missing atoms.


Support Forum / Re: VGL Error
« on: March 28, 2019, 11:34:03 AM »

Ovito has been based on Qt5 from the very beginning. Ovito 2.9.0 was using version 5.7 of the Qt libraries, the new Ovito 3.0.0 builds for Linux use Qt 5.9.

I'm not an expert for this, but yes, the error message seems to suggest that the system libraries on the host machine are outdated and would need to be replaced with a newer version in order to run Ovito through the VNC connection. If that is also the conclusion of the sys admins, then there probably isn't an easy way out, sorry.


I have made a new development build of Ovito 3.0.0 available which shoudn't show the blank main window on macOS 10.14.4:

Please note that the (unrelated) error message "This file has been written by ovito 2.9.0 and ovito 3.x cannot read it anymore." means exactly that: Because the internal data structures of Ovito 3.0.0 have changed dramatically, it is not possible to open old .ovito files with the new program version. You will either have to recreate the visualization with Ovito 3.0.0 from scratch, or stick to the old release.

Let us know if you experience any problems with the new build.


Support Forum / Re: the unit of dislocation length in DXA analysis
« on: March 25, 2019, 02:03:57 PM »
Hi June,

Ovito, including the DXA function, does not use any particular units of length. It operates with those units in which the data are given that you loaded into the program. So, if atomic coordinates are given in Angstroms, then the DXA will yield dislocation line lengths in Angstroms as well.


Support Forum / Re: OVITO Crashes when Loading File
« on: March 25, 2019, 01:59:18 PM »
Hi Egor,

No, we haven't tested the GSD file reader of Ovito with files of that size. I just run a few test with much smaller datasets when I developed the code.

How many frames and how many particles does your GSD file contain?


Support Forum / Re: Failed to initialize Python interpreter.
« on: March 18, 2019, 03:38:38 PM »
Hi Corolina,

Did you install one of the Ovito packages we provide on our website? If so, which version? This question is just to make sure you did not install an old version of Ovito from the Debian package repository, for example.

In which location on your computer did you extract the Ovito archive during installation? The error message suggest you have installed it under /usr/bin/. Is this correct? Ovito is commonly installed under a user's home directory.

How did you run "ovito" (the graphical program)? If you run it from the terminal in the same way you run "ovitos", the two should behave exactly the same. Depending on how you run the two, they may see different environment variables (e.g. PYTHONPATH), which in turn may affect the loading of Python modules.


Support Forum / Re: Lattice rotation
« on: March 18, 2019, 11:32:33 AM »
Dear Rajdeep,

Note that your transformation matrix is not a proper rotation matrix: ([111], [1-10], [11-2]), because its column vectors are not normalized. A rotation matrix must have unit column vectors, all orthogonal, and its determinant must be 1. Since your matrix doesn't fulfill these criteria, you are getting something that is not a pure rotation.

It should suffice to normalize each column vector to obtain a rotation matrix, i.e.

([111]/sqrt(3), [1-10]/sqrt(2), [11-2]/sqrt(6))


Support Forum / Re: Modifying particle type name in latest Beta
« on: March 15, 2019, 03:28:13 PM »

Catching the exception won't help. The ParticleType object, whose name you are trying to change, is locked by default. This is to prevent accidental and permanent modification of data that actually belongs to the upstream pipeline. Modifiers are only allowed to modify copies of data, which are generated along the way down the pipeline. They can never alter the original input data objects.

That being said, here is how you can request a copy of the ParticleType object, which can then be safely modified within the modifier function:

Code: [Select]
    ptype_property = data.particles_['Particle Type_']
    for defect_type in ptype_property.types:
        mutable_defect_type = ptype_property.make_mutable(defect_type) = defect_names[]

The code uses the yet undocumented DataObject.make_mutable() method, which allows you to turn a sub-object into a modifiable version. In this case the ParticleType object is a sub-object of the Property object. That's why we call make_mutable() on the ptype_property. The method basically has the same effect as the '_' notation, just doing it explicitly.

Note that this code does not rename the original particle types. It renames copies of these types that are made along the data pipeline. Thus, the changes will only be visible to modifiers following your Python modifier function in the pipeline.

If you would instead like to modify the original particle types, you would have to do it from outside of a modifier function.

Let me know if you have any further questions.


Support Forum / Re: Fatal Python error: deallocating None
« on: March 15, 2019, 02:32:09 PM »
Hi Michelle,

It turned out that this error is due to a bug buried deep down in the Python interface layer of Ovito. It took me a while to figure out what is going on, because the bug only leads to a visible problem after creating a new global attribute in the DataCollection.attributes dictionary more than approx. 10,000 times.

I've fixed the bug in the source code:

You can download the new build 3.0.0-dev352 for Linux, which should solve the problem.


Support Forum / Re: remove surface mesh
« on: March 14, 2019, 08:40:18 AM »

The DislocationAnalysisModifier is currently not providing direct access to the visual element of the defect mesh. This is a mistake, which I am going to fix in the next development build of Ovito 3.0.

In the meantime, you can use the following workaround:
Code: [Select]
defect_mesh = pipeline.compute().surfaces['dxa-defect-mesh']
defect_mesh.vis.enabled = False


Support Forum / Re: surface mesh creation in for loop version 3.0.0
« on: March 12, 2019, 09:17:40 PM »
Hi Chris,

Please don't keep appending additional instances of the ConstructSurfaceModifier to the same pipeline in your loop. This may easily lead to a situation where Ovito needlessly constructs the surface mesh multiple times during every call to Pipeline.compute().

That being said, the first real problem in your script I see is in this line:
Code: [Select]

This isn't a proper function call, because the parentheses are missing. Unfortunately, Python silently accepts this syntax and won't tell you about the fact that the pipeline doesn't get computed. Please correct it to
Code: [Select]

Here is how I would translate the script to the new Ovito 3.0 style:

Code: [Select]
pipeline = import_file(file)

pipeline.modifiers.append(SelectParticleType(types = {'W'}) #constructing a surface over water molecules
mod = ConstructSurfaceModifier(only_selected = True)

loops = numpy.linspace(5,16,50)

for radius in loops:
    mod.radius = radius
    data = pipeline.compute()
    area = data.attributes['ConstructSurfaceMesh.surface_area']
    fraction = data.attributes['ConstructSurfaceMesh.solid_volume'] / data.cell.volume

Support Forum / Re: set echo off when using ovitos with sftp
« on: March 11, 2019, 11:48:21 AM »
Thanks for letting us know.

I'm not sure why Ovito 2.9.0 ignores the username you provide as part of the SFTP URL, but since it seems to work with the current development build, I won't take further actions for now. Let me know if you need anything else.

Support Forum / Re: twinning
« on: March 08, 2019, 08:42:39 AM »
Hi Wang,

DXA only identifies the dislocation lines themselves, but it cannot tell you where twinning took place in the crystal (which isn't strictly associated with the presence of dislocations). I would say the most natural way to identify twinning is to do a strain field analysis. In OVITO you can use the Atomic Strain modifier for this. In regions of the crystal that have undergone twinning, you should see a characteristic shear strain level. As an additional criterion, you could use the Common Neighbor Analysis to restrict the selection set to perfect FCC atoms (in order to exclude HCP-like stacking fault atoms, which may exhibit the same atomic shear strain values).


Support Forum / Re: Building OVITO from source
« on: March 08, 2019, 08:35:26 AM »
There seems to be a problem with the library "/projects/opt/centos7/anaconda3/lib/" from the Anaconda distribution. Is this the right installation of the Qt 5.x libraries that you intended to use? I can't tell for sure from the error message, but at least I can imagine that this crash results from a conflict between several Qt5 installations present on your system. Perhaps Ovito was compiled against a different Qt version than the one being loaded at runtime. Please attach the CMakeCache.txt file from your build directory. Then I will take a look at your build configuration.

Support Forum / Re: Building OVITO from source
« on: March 07, 2019, 06:05:56 PM »
Please run just "make", not "make -j8". When doing a parallel build, error messages can easily get lost in the verbose console output. If you run just "make" to perform a serial build, any error messages should follow at the very end and should be easily visible.

I would find it very surprising if the build succeeds but there is no /bin/ovito executable being produced (unless you've set OVITO_BUILD_GUI to OFF for some reason).

Support Forum / Re: Building OVITO from source
« on: March 07, 2019, 03:16:25 PM »
The dependency of the CrystalAnalysis plugin on the NetCDF library has been introduced just recently, and only for an experimental feature that you don't need. If required, you can temporarily remove this dependency by removing the following lines from the CMake script:

And the three lines in the other CMake file linked in my post above.


Support Forum / Re: Building OVITO from source
« on: March 07, 2019, 02:37:37 PM »

First of all, let me mention that you should be able to run Ovito from inside the build directory. Thus, it may not really be necessary to first install it via "make install". Please try.

Now regarding your question: Even though its name may suggest otherwise, the "NetCDFPlugin" is not the only module that depends on the NetCDF/HDF5 libraries. The "CrystalAnalysis" plugin also requires the NetCDF/HDF5 libraries. Thus, unless you also set the "OVITO_BUILD_PLUGIN_CRYSTALANALYSIS" CMake variable to OFF, the build script will still try to build and install the "NetCDFIntegration" target, which in turn requires the NetCDF & HDF5 system libraries to be available on your system.

See this part of the CMake code:

So one way to resolve your build problem is to disable the CrystalAnalysis plugin as well. You will then loose the Construct Surface Mesh and Dislocation Analysis modifiers though. I'm not sure if you need them.

I tried to build and install Ovito on my Ubuntu machine with OVITO_BUILD_PLUGIN_NETCDFPLUGIN set to OFF and OVITO_BUILD_PLUGIN_CRYSTALANALYSIS set to ON. This worked without problems. This suggests that the error you encountered is specific to the Centos environment. Is this why you had to disable the NetCDF plugin in the first place?


Pages: [1] 2 3 ... 20