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 ... 20
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.

So far I was not able to reproduce the problem under Windows with the current development version Ovito 3.0.0-dev52. I didn't have the chance yet to test v2.9.0.

If you have a dump file that raises the error and is not too large, please post it here.

Support Forum / Re: Problem with remote file loading
« on: November 20, 2017, 07:09:54 PM »
Dear Jérôme,

I tried to find out more about this error online, but this doesn't seem to be a common problem. There are two possible explanations: (1) the SSH server is not properly configured, or (2) there is a compatibility problem between the SSH/SFTP client library used by OVITO and the SSH server.

I know that OVITO's built-in SSH client has some limitations, in particular with regard to the key encryption methods it supports. However, this particular type of error message has not been reported before. So it is entirely possible that the problem lies on the server side. FileZilla might be smarter and can work around the problem, or it using another protocol.

Unfortunately there is not much I can do from here. I am by no means an expert for SSH client/server communications and the SFTP protocol. The third-party code library used by OVITO for remote file transfer hasn't been updated for some time now and is not really well supported. But it is the only solution currently available. If the remote access doesn't work for you, you might be forced to copy your files to the local computer first before you can open them in OVITO.


Support Forum / Re: creating and manipulating geometry
« on: November 20, 2017, 03:42:36 PM »
I do have plans to extend Ovito in this direction, but given the limited spare time I have available for the development, these plans have only low priority at the moment. Steps in this direction will be contingent upon our ability to secure funding for further development of the software.

Currently, Ovito can only analyze and manipulate existing particle configurations. Here is a rough roadmap I have in my mind for extending Ovito's capabilities toward the creation of new configurations:
  • Possibility to write user-defined modifiers in Python that can manipulate an existing system and add new particles to it (works already)
  • Support for user-defined Python functions that can generate entirely new particle datasets from scratch and which can act as sources for data modification pipelines in Ovito
  • Integrating LAMMPS as an engine into Ovito, visualizing a live view of the LAMMPS simulation. This will make it possible to use LAMMPS scripting within Ovito as a means to generate simulation setups. Here, Ovito mainly provides an environment for rapid prototyping and testing of LAMMPS scripts.
  • Adding functions to Ovito for the interactive creation and manipulation of particle configurations (e.g. a "crystal builder").

You are invited to post your own ideas. What would be most useful functions for manipulating and creating atomic configurations? And how should they be made available to the user?

That's surprising. Which program package version are you using? Is it the same version on Linux and Windows?

Support Forum / Re: charge atom indexation ends on 99999
« on: November 17, 2017, 02:24:39 PM »
By the way:

You can fix the problem of wrong particle identifiers by assigning new IDs within OVITO: Simply use the Compute Property modifier to set the 'Particle Identifier' property. Enter "ParticleIndex+1" as expression. After that you should be able to export the dataset to a valid LAMMPS data file.

Support Forum / Re: charge atom indexation ends on 99999
« on: November 17, 2017, 02:18:03 PM »
Thanks. I checked the PDB file in a text editor: Atom serial number in the second file column run from 1 to 99999. After that, the serial number is replaced by the string '******'. OVITO converted that string to the number 0. That's why particle identifier run only from 0 to 99,999 after file import in OVITO.

I now changed the file parer code and added a special handling of the ***** case. It's be available in the next development version of OVITO.

Can you please say something about the origin of that PDB file? Which code was used to produce it? Source that I find only all say that the legacy PDB format cannot store more than 99,999 atoms and any dataset with more atoms needs to be split into multiple files then.

Support Forum / Re: Void in amorphous material
« on: November 17, 2017, 11:41:52 AM »

there are two approaches that come to my mind:

(1) You can use OVITO's Voronoi Analysis function to compute the atomic volume. The volume per atom can be taken as a local measure of the density. Note that it might be necessary to flatten out local fluctuations. This can be done using the Compute Property modifier or the Bin and Reduce modifier.

(2) The Construct Surface Mesh modifier allows you to reconstruct the outer and inner surfaces of a solid. Hence, it can be used to identify pores in a material. Here, the probe sphere radius parameter of the modifier controls the minimum size of the pores to be identified.

Support Forum / Re: charge atom indexation ends on 99999
« on: November 16, 2017, 06:00:26 PM »

This sounds as if there is a problem in the PDB file parser in OVITO, which I wrote. I have no personal experience with the PDB format and I simply tried to follow the official format specification:

I was under the impression that atom IDs can only be 5 digits long, meaning that the PDB format can store only up to 99999 atoms. What you write suggests that my assumption was wrong.

Please post your PDB file here. I will try to fix the problem in OVITO.


Support Forum / Re: rendering problem
« on: November 16, 2017, 12:31:44 PM »
I meant the "override usage of point sprites" setting and the "override usage of geometry shaders" setting in the application settings dialog.

Here is another thing you can try: Set the rendering quality for particles to "low". This is done in the parameter panel for the "Display"/"Particles" entry in the pipeline editor:

The final workaround I can recommend, of course, is to use the Tachyon renderer instead of the OpenGL renderer to produce image frames.

Support Forum / Re: Applying conventional CNA
« on: November 15, 2017, 07:51:48 AM »
OVITO has originally been designed for simulation datasets with typical inter-particle distances on the order of 1 unit of length, because most molecular dynamics simulations use Angstroms as units. The neighbor list builder in OVITO refuses your dataset, because its internal threshold for the box volume is set too large. A box with volume ~1e-15 m^3 is currently considered degenerate. The cutoff radius parameter has no influence on this as the volume threshold is hardcoded.

I will see if I can make changes to the source code to better prepare OVITO for simulations that use SI units. Other analysis and visualization functions of OVITO might suffer from similar limitations at the moment. Perhaps you have a typical simulation data file for me as a test case.

For the time being you should be able to work around the problem by rescaling the dataset. You can do this within OVITO by applying the Affine Transformation modifier. Set the three diagonal elements of the matrix to 1e6 or so to scale up the entire box and its contents.

After that, the CNA analysis modifier should work. BTW: If you just want to color particles according to their coordination numbers, you can do so using the Coordination Analysis modifier followed by a Color Coding modifier. The CNA modifier is more appropriate though if you want to detect structural order in your system, like you said.

Support Forum / Re: rendering problem
« on: November 14, 2017, 09:11:02 AM »
This rendering bug is likely due to a nonconforming OpenGL graphics driver installed on your system. Please post the system report generated by OVITO when you chose "OpenGL information" from the Help menu.

You may be able to work around the graphics driver bug by changing some of the OpenGL-related settings in OVITO's application settings dialog (found under the 'General' tab).

Support Forum / Re: PTM analysis - orientation of reference templates
« on: November 13, 2017, 08:21:03 AM »

I have received a reply from Peter and need to correct myself:

The template neighbor vectors for the HCP structure are found in line 92 of the source file
Orientations computed by the PTM modifier are relative to this (fairly arbitrary) reference orientation.

Thanks for the instructions how to reproduce the crash. They were helpful.

I was able to reproduce the error and I think I was able to fix it. The maximum number of recursions in the Tachyon raytracer was set too high, leading to a stack overflow at runtime when there are a many semi-transparent objects in the scene. I have reduced this limit from 1000 recursions to 50, without notable differences in the generated image. Now it seems to work without problems. The change is included in ovito-3.0.0-dev54 (macOS version now available on the website).

Support Forum / Re: Extract Nye's tensor component from Ovito
« on: November 12, 2017, 06:29:21 PM »
My apologies, this time it wasn't your fault. The last (and essential) code line was missing from the old version of the Python documentation. Here is the current version of the manual, where the error has been fixed:

Support Forum / Re: Extract Nye's tensor component from Ovito
« on: November 11, 2017, 08:24:50 PM »
Hi Anuj,


Both the Elastic Strain Calculation and the PTM modifier can compute the atomic elastic deformation gradient tensor F. This is, if I remember correctly, the inverse-transpose of the lattice correspondence tensor G mentioned in the original publication of Hartley and Mishin [Acta Materialia 53 (2005) 1313]. The Nye tensor is the negative curl of this G tensor, which must be calculated using a finite differences scheme. OVITO doesn't do this last step for you, sorry.   


I think you didn't copy/paste the complete script from the example page. The implementation of the modify() function in your screenshot is obviously incomplete.


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