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 ... 24
The CNA pictures suggests that the vacancy platelet hasn't turned into a vacancy dislocation loop yet. Maybe because they are too small for the two surfaces to collapse spontaneously, or because something else is wrong with the construction.

For the bcc simulations published in our Nature paper, we also cut vacancy loops into the crystal. Those loops had a hexagonal shape, with the habit plane parallel to {111}. The hexagonal region within which we deleted atoms from the perfect crystal had a thickness corresponding to exactly one 1/2<111> lattice vector. Then, during a short MD run, the two surfaces collapsed back to a perfect crystal lattice again due to their attraction, leaving behind a hexagonal 1/2<111> dislocation loop.

But our loops where certainly larger than yours, so the spontaneous collapse may not happen in your case and you need to assist it somehow.

Support Forum / Re: viewport
« on: April 19, 2018, 09:05:28 AM »
I'm not sure how you mean that. Normally, Ovito doesn't "compute" these values. The user controls them when moving the viewport camera using the mouse. The only function that computes a new camera position is the "zoom all" function, which is automatically invoked after importing a new dataset in order fully show it.

You can invoke this function from Python too, see the Viewport.zoom_all() method.

Note that this function only translates the virtual camera until all objects in the scene become fully visible. The viewing direction and the FOV angle are not changed by the function.

Support Forum / Re: segmentation fault
« on: April 18, 2018, 07:09:07 PM »

I need some more information:
  • Did you use the dump file posted by Emile?
  • What was the selection expression you used?
  • Which operating system do you use?
  • Did you try just Ovito version 2.9.0 or also others?



In this case you should take a step back and first analyse these defects by hand, not using DXA. Use the CNA to identify perfect bcc atoms and check the morphology of the defective atoms.

Keep in mind that the DXA will only determine that it is a dislocation if the vacancy cluster has collapsed into a loop-like shape (i.e. a defect core with torus topology). It will not find a dislocation if the vacancies form a simple cluster (i.e. a defect core with ball topology). There need to be perfect bcc atoms in the centre of the loop, which is probably easer in case of interstitials.

You wrote you removed the 89 atoms to create a vacancy loop. What was the shape of this group of sites you removed? Spherical or more like a platelet?

Support Forum / Re: viewport
« on: April 17, 2018, 07:34:35 AM »
Dear Kyu,

I'm not really sure how to define these parameters better than how it is already done in the Python docs:

These parameters control the position of the virtual camera relative to the dataset, the direction it is taking the picture, and the focal length of the camera.

In any case it is definitely a good idea to check out the Adjust View dialog in the graphical version of OVITO, see:

If you open this dialog for a viewport, it will show you the current values for these three parameters ("View position" corresponds to 'camera_pos', "View direction" corresponds to 'camera_dir', and "View angle" to the FOV (field of view) value). Note that the dialog displays the FOV angle in degrees, while in a Python script you would have to use radians.


Support Forum / Re: Ellipsoidal orientations problem
« on: April 16, 2018, 04:21:41 PM »
Hi Robin,

I can only speculate, but here is what I think is the problem:

OVITO doesn't know that the four columns named "qw", "qi", etc. in your file contain the orientation information. The reason is that LAMMPS doesn't seem to have a standard naming convention for these auxiliary properties. Thus, you need to tell the OVITO explicitly how to interpret these file columns. For OVITO to use the orientation information rotate the ellipsoids, the quaternion values from the file need to be mapped to OVITO's "Orientation" particle property. This is explained in the last paragraph on this page of the manual:

If you don't know where to find the "Edit column mapping" button, see the screenshot here:


Yes, that sounds reasonable and simple and is something you should try first.

An alternative approach that came to my mind is this:

Keep a counter for every defect cluster in the system. Initialize all counters to zero. Then visit all vertices of a given dislocation loop. For every vertex, find the closest cluster atom (use OVITO's NearestNeighborFinder for this). Increment the counter for the cluster this atom belongs to by one. The cluster with the highest count wins and is associated with the dislocation loop.

Hi Christophe,

can you post a typical picture of your defect structures, showing the point defect clusters and the corresponding dislocation loops (superimposed)? This would help us evaluate which kind of correlation strategies could work in your case.


Support Forum / Re: Colouring of atoms
« on: April 10, 2018, 05:55:35 PM »
Yes, you can let OVITO read in per-atom color values. You will need three extra columns in your input file with the RGB components in the range [0,1].

Make sure these columns get mapped to the Color.R, Color.G and Color.B particle properties during file import. Depending on the file format you are using, it may be possible to add some metadata to the header of the input file so that this mapping happens automatically.

Support Forum / Re: How to visualize bonds?
« on: April 10, 2018, 02:08:40 PM »
You cannot hide certain bonds in OVITO 2.9, but in OVITO 3.0 you can. In the current development version of the program, the Select Type and the Delete Selected modifier operate on bonds too.

Support Forum / Re: Rendering Additional Particle Shapes
« on: April 06, 2018, 05:56:16 PM »

I'm sorry, but the current program version is not able to render more "exotic" particle shapes other then the standard shapes (sphere, ellipsoid, cube, cylinder, etc.).

In principle, you could implement a user-defined viewport overlay in Python script to render your polygonal particles using 2D drawing calls. But in my eyes that approach would not make much sense since you could achieve the same results without Ovito using pure Python and plotting frameworks such as matplotlib.

In general, I would be open to ideas and suggestions of how to extend Ovito in this direction and enable the visualisation of more complex particle shapes. But I myself am not really familiar with the corresponding simulation tools and common practices. It still seems to be a niche application with a small audience (compared to atomistic simulations, where particles are typically point-like). There are several open questions that need to be discussed in order to design a useful extension to Ovito, for instance:
  • What degree of freedom with respect to the particle shapes is desired (only regular convex polygons, arbitrary polygons, arbitrary polyhedra)?
  • How would the user specify the shape information?
  • Are there suitable file formats for transporting this information from the simulation codes to Ovito?
  • Is there a common ground between different simulation codes such as LAMMPS and HOOMD?

If you want, we can discuss these questions as you get yourself more familiar with the typical procedures (and visualisation needs) in this area of particle simulations.


You script accounts for the zoom factor of the viewport ("fov" value) and correctly computes the radius of the circle in screen space, but it currently does not take into account the position of the viewport camera. Since the viewport camera is in general not located at the origin, always drawing the circle at the center of the screen is wrong and leads to the apparent offset.

I suggest you make use of the project_point() and project_radius() helper functions that are given in the last script example on the doc page. The project_radius() function does what your own script is doing: it determines the correct radius in screen space given a radius in 3d space. The project_point() function allows you to determine the center of the circle in 2d screen space given a center point in 3d space.

Here is how the new code should look like:

Code: [Select]
    # Define geometry of circular boundary in screen space
    origin = (0,0,0)
    RingRadScaled = project_radius(origin, RingRad, painter, args)
    origin_screen = project_point(origin, painter, args)
    diameter = RingRadScaled*2
    #Draw circle on top
    rect = QRectF(origin_screen[0]-RingRadScaled, origin_screen[1]-RingRadScaled, diameter, diameter)

Support Forum / Re: Installation to get python script to work in gui
« on: April 05, 2018, 03:43:24 PM »
Here is a way to do it: Open the file ovito-3.0.0-dev155-x86_64/lib/python3.5/ in a text editor and change line 80 from




After this change, Ovito's Python interpreter should ignore your user package directory.

Support Forum / Re: Installation to get python script to work in gui
« on: April 05, 2018, 03:31:49 PM »
Ok, thanks. This shows that the problem is not related to the virtualenv. Rather the $HOME/.local/lib/python3.5/site-packages is among the default locations where Python interpreters search for modules and, unfortunately, it has a higher priority than Ovito's internal site package directory. Thus, Python modules like the PyQt5 module that are also present in your user directory shadow Ovito's internal modules.

For testing purposes, you can temporarily rename the /home/ppzmis/.local/lib/python3.5/site-packages/PyQt5/ directory to see if that solves the problem.

I am still trying to figure out a way to convince Ovito not to look in the user package directory at all.

Support Forum / Re: Installation to get python script to work in gui
« on: April 05, 2018, 03:12:22 PM »
Note that I asked you to run "bin/ovitos", not "bin/ovito" in the terminal. "ovito" is the graphical program version, "ovitos" is the interactive script interpreter, similar to "python". Please try to deactivate your virtual environment.  The following line from the error message indicates that the PyQt5 Python module was somehow imported from a directory outside of the Ovito installation:

ImportError: /home/ppzmis/Documents/SimData/ovito-3.0.0-dev155-x86_64/bin/../lib/ovito/ version `Qt_5.9' not found (required by /home/ppzmis/.local/lib/python3.5/site-packages/PyQt5/

Instead, this module should have been imported from the internal package directory:


I am not really familiar with how virtual environments work, but something in the environment must be convincing Ovito's interpreter to load modules from /home/ppzmis/.local/lib/python3.5/ instead of the internal package directory.

Pages: [1] 2 3 ... 24