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 4 ... 16
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".


Support Forum / Re: Filtering defects by time or frame sequence
« on: November 23, 2017, 09:48:10 AM »
I don't have a clear picture of situation and can give you only general advice..

Typically, one would use a coordination-based criterion to filter out such spurious atoms. For example, you can employ the Compute Property modifier to count how many neighbors within given cutoff range of each new defect atom belonged to the initial defects. This information can then be used to select certain atoms, e.g. those which are close one of the initial defects, with the Expression Select modifier and remove them.

Support Forum / Re: Reading data file without x y z in ITEM line.
« on: November 22, 2017, 02:08:36 PM »
Hi Zhu,

Yes, OVITO will first complain about the missing x y z columns in the dump file, but after that you can specify a custom mapping of file columns to the xyz position property. Press the "Edit column mapping" button as shown in the attached screenshot. Then make sure that the f_ave[1/2/3] file columns are mapped to the Posiition.X/Y/Z particle property.


Support Forum / Re: Filtering defects by time or frame sequence
« on: November 21, 2017, 11:22:44 PM »

If we focus on the point defects for the moment, I suggest to use Freeze Property modifier for that. Here is what I have in mind:

First, you identify the atoms that form point defects in the very first simulation frame and select them. You then apply the Freeze Property modifier to "freeze in" the Selection particle property so that it doesn't change anymore even if new defects are created at later frames. You can now highlight this static selection of atoms using the Assign Color modifier. It might make sense to insert a Compute Property to dynamically modify the atom selection and restrict it to just those atoms which were selected in the first frame and which are still defects in the current frame.

Dislocation line defects identified via DXA are a different story. I'm not sure how to do it here. It is possible, at least in principle, to save the dislocations found in the first frame and overlay them with the defects dynamically identified in later frames. However, those dislocation will then appear twice. The problem is that dislocations do not have a unique identity and unlike atoms they cannot be tracked over time.


I was now able to reproduce the file parsing error. It looks like the system function for floating-point number parsing behaves differently on Windows (or the Microsoft C++ compiler). The system's locale might play a role as well if it is set to a non-english language, but I'm not sure.

In any case, it doesn't seem to be an issue anymore in the new 3.0 version of OVITO, which uses double precision numbers internally. The error only occurred in the 2.9.0 version, which uses single precision floating-point numbers internally, which cannot represent very small numbers like 1e-205.

Please switch to the current development version if you want to get rid of the error.

Pages: 1 [2] 3 4 ... 16