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 ... 12 13 [14] 15 16 ... 20
Support Forum / Re: Property summation and periodic boundary conditions
« on: November 11, 2017, 08:13:53 PM »
Hi Jeremy,

The Compute Property modifier is probably not the right tool to compute an aggregate value from a set of atoms. If I understand you correctly, you used the Include Neighbour Terms option and a cutoff range that is large enough to include the entire atom cluster. Then all atoms in the cluster are visited during the computation and you can sum up their property values at one or all atoms of the cluster. However, if your system is periodic, additional images of the same cluster may reach into the cutoff range and you get additional, undesired contributions.

A better solution is to use a simple Python Script modifier to do the reduction computation. Let's say you want to compute the sum of the 'Potential Energy' property of all currently selected atoms. The following script function does that for you:

Code: [Select]
import numpy as np

def modify(frame, input, output):
energies = input.particle_properties['Potential Energy'].array
selection = input.particle_properties['Selection'].array
output.attributes['energy_sum'] = np.sum(energies[selection != 0])

The computed total value is output as a global attribute by the script. You can access the value in various ways, for example export it to a text file using OVITO's file export function or display it in the viewports using the Text Label Overlay.

You could extend the script further and let it compute the aggregate values for each cluster simultaneously (not just the currently selected one) and write the per-cluster values directly to an output file.


Dear yidongxia,

This looks like a bug in the Tachyon renderer. Perhaps some sort of stack overflow. Can you reproduce the crash, or was it a one-time thing?

It it is reproducible, it would be great if you could post the input dataset together with a step-by-step description of how to produce the program crash. I am not the author of the Tachyon renderer code, but perhaps I am able to fix it if there is a bug. Otherwise I will forward the report to the developer of Tachyon.



Support Forum / Re: PTM analysis - orientation of reference templates
« on: November 10, 2017, 03:34:36 PM »

That's a good question. I don't know the answer either. I will forward your question to Peter Larsen, the author of the PTM method and the routine in OVITO.

But my first guess is that the answer to your question can be found in this source code file:
I think the penrose_hcp array contains the 12 HCP neighbor vectors expressed in the Cartesian reference coordinate system used by the PTM routine.

I'll let you know if I receive a comment from Peter.


Support Forum / Re: Using ovitos to delete atoms
« on: November 08, 2017, 04:45:03 PM »
I'm sorry, I didn't see that you were referring to "ovitos". That means you would like to use the scripting interface of OVITO to automate the task.

My first draft for an ovitos script would look like this:

Code: [Select]
from import import_file, export_file
from ovito.modifiers import SliceModifier

pipeline = import_file("input.poscar")
pipeline.modifiers.append(SliceModifier(normal=(0,0,1), distance=123.45))
export_file(pipeline, "output.poscar", format="vasp")

Of course, this script can be refined further. For example, to batch process a sequence of files in a directory, one could change this to:

Code: [Select]
pipeline = import_file("input.*.poscar")
pipeline.modifiers.append(SliceModifier(normal=(0,0,1), distance=123.45))
export_file(pipeline, "output.*.poscar", format="vasp", multiple_frames=True)

Support Forum / Re: Error trying to initialize script
« on: November 08, 2017, 09:33:16 AM »
Ah, okay, that explains it.

I didn't realize you had installed the Ubuntu package "ovito", which comes from the Debian package repository. I cannot provide any support for this package. There is an independent maintainer responsible for it, who I am not affiliated with. (Bugs like the one you encountered should be reported to that Debian package maintainer.) As 'upstream' developer of OVITO I provide my own installation packages on, and only those come with a separate Python interpreter.

Now that you downloaded one of these binary packages, you are good to go. Let me know if you have any further questions.

Support Forum / Re: Using ovitos to delete atoms
« on: November 08, 2017, 07:47:36 AM »

There are various ways of doing this with OVITO. But the easiest is probably the one based on the Slice modifier.

After loading your POSCAR file in OVITO, add the Slice modifier to the processing pipeline. Set its normal vector to (0,0,1). (Shortcut: click the "Normal (Z)" label). Then adjust the modifier's distance parameter to the z-coordinate above which you want to delete all atoms.

An alternative approach would be to use the Expression Select modifier to select some atoms based on a user-defined criterion, e.g. "Position.Z>25". After that, you insert an instance of the Delete Selected Particles modifier to remove the selected atoms.   


Support Forum / Re: Error trying to initialize script
« on: November 07, 2017, 08:38:33 PM »
Have you tried the current development version already (Ovito 3.0.0)? Maybe it works better than the older 2.9 release.

I'm still thinking about reasons why there could be a conflict between Conda and OVITO. OVITO comes with a complete, self-contained CPython interpreter, which is extracted together with the program files from the .tar.gz archive that you downloaded from the website. This interpreter includes its own library of standard Python modules and extensions such as Numpy. I would say the only way another Python interpreter on the system (e.g. conda) could interfere with OVITO's interpreter is via environment variables. Maybe you can check if there are any other variables set (besides PYTHONPATH), which are relevant for a CPython interpreter.

Support Forum / Re: Creating and Visualizing Double Bonds
« on: November 07, 2017, 10:36:09 AM »

I'm sorry, but OVITO currently doesn't support the display of double bonds. But let me take a note that you are interested in having this feature. Perhaps we can add this capability to OVITO in the future. How would you like the double bonds to look like? Can you perhaps post a picture (from another visualization software) here that shows your preferred style?

Semi-transparent bond rendering is also still missing. Hope I soon get more development personnel (or time for myself) to implement all these things in OVITO.

Best regards,

Support Forum / Re: Error trying to initialize script
« on: November 07, 2017, 10:29:06 AM »
Let me know if you manage to get the mixed display of spherocylindrical and spherical particles working or not. I will consider your feedback in the future design of OVITO. Maybe it is possible to make this process somewhat easier.

Regarding your Python problem:

I assume you are running the binary Ovito 2.9.0 package from the website, right? (If you would run your own local build of Ovito 2.9.0, it would make a difference, because only the official version ships with a packaged Python interpreter + Numpy module).

I am still trying to find an explanation why the Numpy module isn't found on your system. Maybe you can check your PYTHONPATH encironment variable to see if there are any conflicting entries. Here is how it looks on my Ubuntu machine:

Code: [Select]
stuko@mogli9:~/progs/ovito-2.9.0-x86_64$ echo ${PYTHONPATH}

By running ovitos, I can check which paths are searched for modules (This might not work for you if initialization fails early):

Code: [Select]
stuko@mogli9:~/progs/ovito-2.9.0-x86_64$ bin/ovitos
This is OVITO's interactive IPython interpreter. Use quit() or Ctrl-D to exit.
In [1]: import sys
In [2]: sys.path

Support Forum / Re: Error trying to initialize script
« on: November 06, 2017, 08:22:03 AM »
Please let me know which version of OVITO and operating system you are using.

Yes, the binary program packages from the OVITO website (should) come with Numpy included.

I haven't tested how well it works, but OVITO should display spherocylindrical particles with zero length as simple spheres. So I am wondering: Can't you just set the 'Aspherical Shape.Z' property of these particles to zero? (Using the Compute Property modifier, for example)

If that doesn't work, it might be necessary to import the entire dataset into OVITO a second time. Select "Add to scene" when importing a second time. You can choose different particle display styles for the two datasets. It might be necessary to delete mutually exclusive subsets of particles from each dataset as you don't want to display the same particles twice.

Support Forum / Re: Elastic Plastic decomposition
« on: November 02, 2017, 08:32:18 AM »
Dear Debasis,

let me first note that this research was published under the same title in the MSMSE journal:

OVITO can calculate the atomic elastic deformation gradient tensor, which is related to the approach presented in the paper. Here is the corresponding page in the user manual:

However, this analysis modifier only calculates the elastic strain at each lattice site. If you are looking for an implementation of the more sophisticated elastic and plastic strain field method discussed in the paper, you should take a look at my other code, the Crystal Analysis Tool:

Let me know if you have further questions.

Best regards,

Support Forum / Re: Compute Property Question
« on: November 01, 2017, 05:28:05 PM »
A quick update:

I have revised the routine for calculating the atomic deformation tensors and it should now handle large cutoffs better when the simulation cell is periodic. The updated code is included in build 3.0.0-dev52 and later. 

Okay, cool.

Thank you!


Yes, OVITO's Voronoi Analysis modifier function supports non-orthogonal periodic and partially-periodic cells. It implements a workaround for Voro++'s limitation in this regard.



I'm sorry, but I now noticed that there was a mistake. As it turned out, the dev46 version double precision computations were not enabled in the dev46 build. I didn't immediately notice it, because my Linux virtual machine only allows me to build the Ovito executable but not run it.

Not surprising then, of course, that your measurements didn't show any significant deviations from the dev39 build. I'm sorry for having wasted some of your time here. If you still have the chance, it would be nice if you could run the benchmark again with the dev52 build. It has double precision calculations enabled (see OpenGL information dialog, accessible from the help menu).


Hi Jer,

Ovito doesn't have a built-in function for calculating the Warren-Cowley SRO, but it should not be too difficult to implement the calculation as a user-defined Python script modifier.

I would first use the Create Bonds modifier of OVITO to build a list of nearest neighbour bonds. Then all the user-defined analysis script would have to do is iterate over the bond list and do the counting of bond types.

I don't have such a script immediately ready for you. But I could support you as needed in writing it.


Support Forum / Re: group/group force calculate
« on: October 28, 2017, 01:11:39 PM »
Dear Mostofa,

It's not clear to me what you are after. For instance, how are the groups of 8 atoms supposed to look like?

But more importantly, note that OVITO cannot perform any force calculations. That is because OVITO doesn't know anything about the interactions between atoms. For that kind of calculation you need an MD simulation code such as LAMMPS. OVITO is only able to perform structural or kinematic types of analyses.

Support Forum / Re: Compute Property Question
« on: October 27, 2017, 12:03:08 PM »
Thanks. I was able to reproduce the problem. But I now think that is not related to your particular dataset or the fact that your simulation cell is sheared.

The problem is the large cutoff radius. As soon as it is larger than half the periodic box size (in your case the cell size along the z-axis), the relative displacements vectors calculated by the atomic strain algorithm turn out wrong. The reason is some sort of ambiguity and/or the minimum PBC image convention.

I am still trying to figure out whether that ambiguity can be resolved or not. For the time being, I suggest you use a smaller cutoff radius. In any case, there is not really a point in using a cutoff distance which is on the order of the simulation cell size. Only smaller cutoffs, typically on the order of a few interatomic distances, will give you spatially resolved strain information.

Support Forum / Re: Data from Polyhedral Template Matching
« on: October 25, 2017, 01:51:17 PM »
Note that Voronoi cells of particles can be classified by the PTM as 'Other' for two reasons:

  • The point-to-point correspondence cannot be established for any of the reference structures
  • It can be established for at least one reference crystal structure, but the resulting RMSD value (i.e. the structural deviation) is too large and exceeds the RMSD threshold value set by the user

The latter only applies if a non-zero RMSD threshold has been set. I assume your question pertains to the second case, where a point-to-point correspondence exists.

Currently, this intermediate information is not exposed by the algorithm and is not accessible by the user. You would have to touch the C++ code of OVITO to access the point-to-point mapping. If you are willing to do some code development, an alternative is to contact Peter Larsen, the author of the PTM method. He has made a C++ PTM code library available (same one used by OVITO), which you could work with.

Support Forum / Re: OVITO opens with black window only
« on: October 25, 2017, 01:40:30 PM »
I don't think this issue is in any way related to the path OVITO is installed in. Typically, a black window like this is a sign for graphics system problem.

Please check if your graphics driver is installed correctly. Sometimes reinstalling it can solve such a problem. Sometimes simply restarting the computer may help as well (because the Linux system packages are being automatically updated in the background, which can temporarily put the OpenGL graphics system into a non-working state).

Please also check whether other OpenGL-based programs work correctly or not. It may be a system-wide issue. For example, you can start the "glxgears" test program, which comes with most Linux distributions, from the terminal.

That being said, let me also answer your question:

OVITO stores its application settings in the config file $HOME/.config/Ovito/Ovito.conf under Linux. You can delete this file to reset OVITO into its default state.

Support Forum / Re: Compute Property Question
« on: October 25, 2017, 12:27:47 PM »
Your table shows that the results are correct for smaller cutoff radii but appear to be incorrect for large cutoff radii (cutoff on the order of the simulation cell size).

I can think of two possible sources for this error:

  • The atom neighbor lists generated by OVITO for the non-orthogonal (sheared) simulation cell are wrong and lead to incorrect strain calculation results
  • Or the minimum image convention used in the strain calculation routine leads to wrong results

I would like to investigate this issue further (and hopefully solve it). For that, it would be helpful if you could send/upload your simulation file. Just the first frame should be enough.

Support Forum / Re: Compute Property Question
« on: October 24, 2017, 09:57:55 PM »
Yes, if the reference configuration is the same as the current configuration, then the (shear) strain values should be virtually zero for all atoms.

You are saying that this was indeed the case for the first simulation you analysed, but for some reason it is not the case for the second simulation (with the sheared simulation cell).

From what you wrote and the screenshots I cannot tell what went wrong. It might be necessary that you also upload the original data files so that we can reproduce the problem.

There is a typical source of error that can lead to unusually large strain values. Please check if it applies to your case:

For the atomic strain calculation the displacement of each atom needs to be computed. This requires that each atom has a unique identity so that its motion can be tracked over time. LAMMPS (assuming that is the MD code you use) tends to reorder atoms from time to time during a simulation. If you didn't write out the atomic IDs to the dump file, then OVITO might create a wrong mapping between the atoms in the current and the reference configuration. The computed atomic displacements and strains will then come out wrong.

However, this problem can only arise if the current and the reference configuration are not loaded from one and the same file. If it is the same file, then we'll have to look for other explanations. Did you check if the value of the Cutoff Radius parameter or the Eliminate Homogeneous Cell Deformation option have any influence on the computed strain values?


Support Forum / Re: Compute Property Question
« on: October 23, 2017, 05:22:41 PM »
Yes, the scalar "Shear strain" property, which is output by the Atomic Strain modifier of OVITO, is computed according to equation 7 in the book chapter.

Support Forum / Re: Compute Property Question
« on: October 21, 2017, 05:39:34 PM »
The atomic strain calculation is a little more elaborate than comparing average bond lengths. First, an atomic deformation gradient tensor is calculated, from which the atomic strain tensor and finally the volumetric and shear strain values are derived.

You can find technical details in the OVITO user manual and in section 3.2 of the attached document.

Great. Thanks for the quick effort.
Looks like the extra costs of double-precision computations are negligible. That's good news.

In the latest dev build of OVITO I have switched from single-precision to double-precision numbers as default floating-point data type. All calculations will now be performed with double precision in OVITO and the memory footprint becomes larger.

I would be interested in determining how that affects performance. If you have the time, it would be great if you could redo the benchmark run with the newest OVITO build to see if there is any measurable effect.

Support Forum / Re: segmentation fault
« on: October 20, 2017, 09:09:58 AM »
The log certainly shows that my instructions for turning off the network access during program startup did not work for some reason. If you have access to another macOS computer with a working Ovito installation, you can test whether the changes to the .plist settings file take effect. The updates.check_for_updates key in the settings file controls the user option "Auto-refresh news page from web server" in the Ovito application settings dialog. So setting it to false should uncheck the corresponding check box and vice versa.

I uploaded a new dev build of Ovito (3.0.0-dev46) yesterday. The macOS binary is build against the latest version of the Qt library (5.9.2). If you have the time, please try if that makes any difference.

Support Forum / Re: segmentation fault
« on: October 19, 2017, 07:11:59 PM »
This is surprising. Did you check if the program crash really is due to the same error as jjmolina reported above?

After the Ovito app crashes, a system dialog should appear. Click the "Report" button to see the error log. It should be similar to jjmolina's: 

Code: [Select]
Thread 0 Crashed:: Dispatch queue:
0   org.qt-project.QtNetwork      0x000000010b5c4425 0x10b525000 + 652325
1            0x00007fffad35f5c4 PAC::PACClient::invokeClientCallback() + 102

If it's different, please post the error log here.

Support Forum / Re: Compute Property Question
« on: October 19, 2017, 01:14:08 PM »
Dear Debasis,

Yes, you are right: The Compute Property modifier stores the computed values as a new particle property which is non-visual at first. There are various ways to make that data visible.

For a vector property such as "Displacement", Ovito can render an arrow for each particle in the viewports. For this, you need to check the box next to the "Displacement" entry under the "Display" section of the pipeline editor. See the attached screenshot.

Another option to make property data visible is to use the Color Coding modifier to translate a scalar property (e.g. "Shear Strain" computed by the Atomic Strain modifier) into a particle color. So if you add this modifier to the pipeline, particles will be assigned a color based on the value of the selected particle property.


Support Forum / Re: segmentation fault
« on: October 18, 2017, 06:41:41 PM »
I am pretty sure it is a text file, despite its unusual filename extension. On macOS, .plist files are XML-based config files.

Pages: 1 ... 12 13 [14] 15 16 ... 20