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 5 ... 21

The Delaunay tetrahedra are thrown away once the surface mesh has been built (and before the triangle mesh is being smoothed in the final algorithm step). Thus, there currently is no way to access this information in the output of the modifier pipeline. You would have to hack the C++ sources of the Construct Surface Mesh modifier in order to access the Delaunay structure.

Why are you interested in getting hold of the tetrahedra forming the solid region?


I didn't pay much attention to this detail, but I think you are getting this error due to the way you are running the script from the command line. You do

   ovitos <

but instead you should just do


Piping the script file into the interpreter using the "<" operator seems to work with your first script (a fact that is very surprising to me) but not with the second script containing the loop, probably because the indented loop code block gets not executed correctly.

Hi Nick,

You wrote that it "stops working". Could you please elaborate on what happens. Do you get an error message? Do you get wrong or no results?

Just from looking at the scripts I don't see an obvious reason why the second version shouldn't work. However, since all loop iterations operate on the same input data file, I suggest you rearrange the script a bit in order to avoid loading the same input file over and over again. The following version will re-use the existing pipeline, just reconfiguring one of the modifiers during each iteration:

Code: [Select]
node = import_file("dump.mycoords.5000")
modifier1 = SelectExpressionModifier()
mod = ConstructSurfaceModifier(radius = 3.5, smoothing_level = 10, only_selected = True)
for x in range(1, 107):
modifier1.expression = 'MoleculeIdentifier=={x}'.format(x=x)
filenameW = "New" + str(x) + ".txt"
export_file(node, filenameW, "txt", multiple_frames = False, columns = ["Frame", "ConstructSurfaceMesh.solid_volume", "ConstructSurfaceMesh.surface_area"])
print("particle %i completed" % (x))


Support Forum / Re: set echo off when using ovitos with sftp
« on: February 21, 2019, 09:51:00 AM »
No, normally this should not happen. Can you please post the script so I can see how you specify the SFTP address?

If you have switched to Ovito 3.0.0-dev already, you can activate verbose log messages by setting the OVITO_SSH_LOG environment variable. This will show you more information about the SSH connection and authentication process:

Code: [Select]
export OVITO_SSH_LOG=1

Note that you can test the SSH/SFTP remote file access also from within the graphical Ovito program. If it works there, it should also work the same way from a Python script.

Support Forum / Re: Surface indexing using ovito
« on: February 21, 2019, 07:34:33 AM »
Hi Angel,

I don't think that Ovito can directly solve your problem. But I am still trying to understand exactly what you would like to do, or what you would like Ovito to do for you.

As you said, the PTM already allows to calculate the local crystal orientations at each atom. If I understand you correctly, you would like to take an input vector in the simulation coordinate system, for example the normal vector of a slicing plane, and transform it to the local lattice coordinate system. Is this the information you are interested in?


Support Forum / Re: set echo off when using ovitos with sftp
« on: February 20, 2019, 09:18:08 AM »

That's a good question. I never thought about it before. The "set echo off beforehand!" message is meant as a warning to you, because Ovito has no way of concealing your keyboard input when you enter the password. Thus, the password will appear as clear text in the terminal and every bystander can potentially see it.

Unix/Linux terminals, however, provide a way to hide all keyboard input entered by the user. You can activate this mode using the "stty -echo" terminal command (to reactivate the display again use "stty echo"). You need to activate the "echo-off" mode before running ovitos.

Note that newer versions of Ovito provide support for public-key SSH authentication. Thus, if you use this type of authentication instead of password authentication, the above problem is no longer an issue and you have the advantage of your ovitos script running without any user intervention.


Support Forum / Re: How can we get a bond angle distribution in ovito?
« on: February 19, 2019, 07:21:42 PM »
The script builds up a histogram of bond angles over the [-1,+1] value range of cos(theta). This histogram is stored in a Numpy array in the variable "angle_cosine_histogram". You can use the numpy.savetxt() function to write the numeric data to a text file in the current directory. For example, add the following line to the end of the script:

Code: [Select]
np.savetxt("distribution.txt", angle_cosine_histogram, delimiter=',')

You can then use your favorite plotting tool (e.g. Microsoft Excel, Gnuplot, etc.) to import this text file and create a graph from the numeric data. There is currently no direct way of exporting the visual plots you can find within the graphical version of Ovito as images.

Support Forum / Re: wrong atom type
« on: February 19, 2019, 07:06:41 PM »

Yeah, the old Ovito version had problems reading XYZ files with varying sets of elements. This bug has been fixed, and the current development release 3.0.0-dev341 of Ovito handles these files much better. Please upgrade to the new program version.

See also the old bug report:


Support Forum / Re: How can we get a bond angle distribution in ovito?
« on: February 17, 2019, 06:46:02 PM »
Hi SC,

Constanze went on vacation, so let me answer your question.

Yes, "ovitos" is a command line application for executing Python scripts that do run outside of the graphical Ovito user interface. It is typically used when automating analysis and rendering tasks which do not require user intervention.

On Windows, you can find "ovitos.exe" in the installation directory of Ovito. You should run it from the Windows command line prompt as specified by Constanze in order to see the console output your Python script produces.



I would say switching to the Ovito 3.0-dev release is right choice, because sooner or later you will need to adapt your scripts in any case.

The data structures in Ovito 3 have changed and it wasn't possible to keep the Python interface fully backward-compatible. One of the classes that have been removed completely is ParticleProperty. That's why you get the error message. The Type.XXX constants are still available in the Particles class. Thus, you can now write Particles.Type.Selection. However, the new documentation suggests you better specify the property using its string name, i.e. "Selection". Instead of the old create_particle_property() method, the new interface provides the PropertyContainer.create_property() method:

Code: [Select]
sel = output.particles_.create_property("Selection")

Note the _ (underscore) that has been appended to the particles accessor. It is required to express your intention to modify the Particles property container that this accessor field returns. Without the underscore suffix, the returned object will be locked and any attempt to modify it will result in an error message.


Support Forum / Re: Data collection error
« on: February 14, 2019, 11:40:04 AM »
Yeah, I thought so.

The reason for this difference is that the table in the modifier panel lists the prescribed dislocation classes, which all have manually assigned names. In contrast to this, the names of the output attributes are auto-generated from the prototype Burgers vectors, and the algorithm puts all zero entries at the end of the Miller notation.

I should rename the predefined dislocation classes in the code to make them consistent with this scheme.

Support Forum / Re: Data collection error
« on: February 14, 2019, 11:17:24 AM »

The naming of the output attribute is different. It is "DislocationAnalysis.length.1/3<100>" (not <001>), as you can see in the attributes data inspector of Ovito (attached screenshot).


Support Forum / Re: dump bond length for each atom
« on: February 12, 2019, 08:06:31 PM »
Yes, the class is available in Ovito 2.9.0 as well:

It's just the example script in the old docs doesn't demonstrate how to access properties of the neighboring atom such as their chemical type. But it works the same way as shown in the newer documentation for Ovito 3.0.0: You simply need to use the neigh.index field to look up the neighbor's information in the 'Particle Type' property array.

Support Forum / Re: dump bond length for each atom
« on: February 12, 2019, 07:56:25 PM »
I see, you seem to want a method for visiting all neighbors of an atom within a certain cutoff range, independent of whether they are bonded to the central atom or not. For this purpose the Ovito scripting interface provides the CutoffNeighborFinder utility class:

The example script (for Ovito 3.0) shows how to print a list of neighbors for each atom, their distance from the central atom and how to access their type.

Is that what you were looking for?

Support Forum / Re: dump bond length for each atom
« on: February 12, 2019, 06:39:53 PM »
For Ovito 3.0.0-dev the code looks similar:

Code: [Select]
    atom_types = data.particles['Particle Type']
    bond_list = data.bonds['Topology']
    bond_lengths = data.bonds['Length']
    for atom_pair, bond_length in zip(bond_list, bond_lengths):
        print(atom_types[atom_pair], bond_length)

The main difference is that Ovito 3.0.0 works with full bonds, not half-bonds. Thus, it is no longer necessary to skip every other bond in the loop.

The Compute Bond Lengths modifier has been removed in Ovito 3.0.0. The simple type of computation it performs can now be accomplished with the standard Compute Property modifier. You should set it to operate on bonds instead of particles, set the output property name to "Length", and enter "BondLength" as expression.

Support Forum / Re: dump bond length for each atom
« on: February 12, 2019, 06:32:39 PM »
Here is a Python code snippet for Ovito 2.9.0, which prints the list of all bonds in a data collection, listing the types of the two atoms connected by a bond and the bond's length:

Code: [Select]
# Get the atom type property:
atom_types = data.particle_properties['Particle Type'].array

# Get the array containing the bond topology, i.e. pairs of atom indices;
bonds_list = data.bonds.array

# The the 'Length' bond property array previously computed by the Compute Bond Lengths modifier:
bond_lengths = data.bond_properties['Length'].array

# Simultaneously iterate over the bond topology array and the bond lengths array:
for atom_pair, bond_length in zip(bonds_list, bond_lengths):

# Skip every other half-bond, because Ovito 2.9 stores A->B and B->A bonds.
if atom_pair[0] < atom_pair[1]: continue

# Use the atom index pair to look up the types of the two atoms connected by the current bond:
print(atom_types[atom_pair], bond_length)
The code assumes that you have applied the Compute Bond Lengths modifier, which creates the 'Length' bond property being accessed in the script.

The code produces output that looks like this:

Code: [Select]
[1 2] 1.22793
[2 1] 1.13556
[1 2] 1.17782
[2 1] 1.21634
[1 2] 1.24922

Support Forum / Re: dump bond length for each atom
« on: February 12, 2019, 08:42:48 AM »
Dear Zhao,
would you like an answer for Ovito 2.9.0 or for the new 3.0.0 development release?

Support Forum / Re: "Locking in" particles
« on: February 11, 2019, 10:51:30 AM »

Ovito currently doesn't provide a built-in solution to this problem. You can imagine that this isn't a trivial problem as clusters can typically grow and shrink over time or split and merge. There is no clear-cut criterion for deciding what is the "identity" of a cluster, which is necessary for tracking the cluster through time.

It's up to you to choose (and then implement, probably using a Python script) an appropriate method for deciding whether two clusters from two consecutive frames are the same or not. Ovito gives you only the list of atoms/particles that belong to each cluster in each frame.


Support Forum / Re: Name on the particle
« on: February 07, 2019, 11:29:40 AM »
Not yet, sorry.
My current current focus is on getting the 3.0.0 release over the finish line. Particle labels are a feature planned for a follow-up release.

Support Forum / Re: Problem in loading file in OVITO 3.0.0-dev334 on macOS
« on: February 01, 2019, 09:38:54 AM »
Let's try it one more time (if you don't mind). This the current Ovito version built against the old Qt library version (5.9.7):

Let's see if it works any better than the previous build on your machine.

Thanks for letting me know.
One more thing I would like you to do: In the non-working Ovito version, please go to the Help menu, select "OpenGL Information" and send me the displayed system information. Thanks.


The main difference between builds dev234 and dev334 is the version of the included Qt library, which is used by Ovito for its user interface and also the 3d viewports. The latter Ovito build comes with Qt 5.12.0, which could be the reason for the reported problem, but I am not sure. Sometimes, things that used to work become broken in new Qt versions.
The Qt people have just published the Qt 5.12.1 maintenance release. My hope is that it includes a fix for the problem. I uploaded Ovito build dev340 to the website today. Please give it a try.


Dear Mahsa,

Please post a screenshot of the Ovito window here. I haven't seen this happening before and would like to get an idea of how it looks on your computer.

Please then try an older development build, for example this one:

Does it show the same problem?


Hi again,

please ignore my previous statements regarding the WS modifier's inability to use frames from the reference trajectory other than the first frame. In the current development version of Ovito 3.0.0 the WS modifier already provides the "Reference frame number" field, which lets you select the desired frame from the trajectory. It's just that you cannot use the mentioned drop-down box to select it.

That being said, I have worked on the Ovito code in the meantime and added the missing capability of using a dynamically changing reference configuration. The newly available build Ovito 3.0.0-dev334 provides the "relative to current frame" option, which lets you use a reference configuration that is in sync with your defective configuration (see screenshot).

Just perform the following steps in the WS modifier panel:

  • Set "Reference configuration source" to "External file" and pick your dump file containing the reference trajectory,
  • select the "Relative to current frame" option, and
  • set "Frame offset" to 0.

You will also notice that the non-functioning drop-down frames list, which contributed to your confusion, is hidden now.
With the new extension you shouldn't need a Python script anymore to do what you wanted to.


Hi liammo29,

Here is some additional info regarding the original problem from my side, the Ovito developer:

The Wigner-Seitz function is currently limited to static reference configurations. This is unlike the Displacement Vectors and Atomic Strain functions, which already support dynamically changing reference configurations. This option is needed to perform the frame-by-frame analysis of the defective trajectory with respect to the corresponding frames of the reference trajectory.

Unfortunately, there currently is a drop-down box in the WS-modifier user interface listing all frames of the selected reference trajectory. It may lead you to think that it allows you to select a reference frame from the trajectory. However, that is not the case. This drop-down list is only there, because Ovito re-uses the same UI panel as for the main trajectory, where it allows you to quickly jump in time to a specific frame. In case of the reference trajectory, it doesn't work like that though. The only way to select a different reference frame other than the first one from the trajectory dump file is to split the reference trajectory into a series of individual dump files. (Use Ovito's export function for that). Then you can load in a specific frame as reference configuration.

However, even with this approach the reference frame will still be static. So it doesn't solve the original problem, which is to update the reference in sync with the main trajectory. I agree with Constanze that the only solution to this problem currently is the usage of a Python script.

Note that her script is for the current 3.0.0 development release. Your screenshot suggests that you were still using the old 2.9.0 program release.

Support Forum / Re: Quantum espresso files
« on: January 23, 2019, 02:52:37 PM »
You are probably referring to the import_file() Python function. Yes, this function can load all file formats that are supported by the graphical program version, including the QE format.

Support Forum / Re: Unwrapping dislocation segments in the CA file
« on: January 22, 2019, 09:50:44 AM »

The CA storage format reflects how the dislocation lines are represented in memory by Ovito: A single dislocation is always represented as one continuous line, which doesn't wrap back into the simulation box. The first vertex of the line is typically located inside the simulation box, but the other vertices of the line may be located outside of the box if it crosses a periodic box boundary.

When Ovito renders the dislocation lines in the viewports, it folds them back into the simulation box on the fly and splits segments when necessary. If you are interested in this "wrapped" representation of the dislocation lines, you should export the dislocation data to the "VTK Dislocation Lines" file format instead of the CA format.


Support Forum / Re: run ovitos on HPC
« on: January 17, 2019, 08:44:30 AM »
Dear Zhao,

You can prevent "ovitos" from connecting to the X server by clearing the DISPLAY environment variable before executing "ovitos":

   export DISPLAY=

Or even simpler:

  DISPLAY= ./ovitos


Support Forum / Re: Orbit center
« on: January 16, 2019, 04:04:57 PM »
Hi Chris,

OVITO uses the geometric center of the axis-aligned bounding box enclosing all objects that are currently visible as camera orbit center by default. Thus, if you hide some objects such as the simulation cell or the particles, the dynamically computed bounding box changes accordingly. In particular this will be the case if some of the particles are positioned outside the simulation cell (which otherwise determines the "bounding box" just by itself).

You can manually override the dynamically computed orbit center by double-clicking on an object in the viewports. However, there currently is no way to specify the coordinates of the orbit center numerically.


Hi Vivek,

From your error messages it seems that you are using a recent development version of Ovito 3.0.0. The script you mentioned is not compatible with that version anymore, because the programming interface has slightly changed.

The good news is that Ovito 3.0.0 provides a built-in capability to compute partial RDFs, see here:

You can access this new capability of the CoordinationAnalysisModifier from a Python script. Please see the first example script in the referenced Python docs. All you need to do additionally, is to set the partial option of the modifier to True.


Pages: 1 2 [3] 4 5 ... 21