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 ... 15 16 [17] 18 19 20
Yes, node.output.attributes is a Python dictionary containing all computed attributes as key-value pairs. The key SelectExpression.num_selected can be used to look up the corresponding value computed by OVITO in the dictionary. For this you have to use the standard Python indexing notation, e.g.

   value = dictionary[key]

When you call the export_file() function to create a text file, the function expects the list of key names to be exported as a parameter (columns). Internally, the function looks up the values corresponding to these keys in the node.output.attributes dictionary.

The name of the global attribute is simply SelectExpression.num_selected. So when calling export_file(), use columns=['Timestep', 'SelectExpression.num_selected'].

Support Forum / Re: Vorotop modifier
« on: July 21, 2017, 09:34:10 AM »

Support Forum / Re: Vorotop modifier
« on: July 20, 2017, 01:40:49 PM »
This modifier is missing in the Linux build of OVITO (the Windows version has it). I wasn't aware of that, so thanks for notifying me.

I'll try to post new dev builds as soon as possible, probably tomorrow. If you can't wait and want to use the VoroTop modifier immediately, please build OVITO from source yourself.

Support Forum / Re: RDF
« on: July 13, 2017, 10:38:59 PM »
Yes, OVITO can read GSD files (written by the HOOMD code). Let me know if you experience any problems with this. I wrote the GSD file parser myself, but I couldn't test it very much, because I didn't have many GSD files at hand.

The RDF calculation as it is currently implemented in the Coordination Analysis modifier of OVITO is very simplistic: It includes every particle pair in the system, irrespective of the molecules the individual atoms/particles are part of. I guess you can call this "inter-molecular", but I am not familiar with the precise nomenclature.

Support Forum / Re: RDF
« on: July 13, 2017, 09:58:00 PM »

Most analysis functions in OVITO, including the Coordination Analysis, operate on a per-frame basis. The program cannot know that your system is in equilibrium and that you want to take a time average.

I suggest you write a small Python script for OVITO which performs the time averaging for you. Here is how you calculate the RDF for a single frame:

How to load a simulation sequence and step through the frames is described here:


Support Forum / Re: Run error on the example of WS Python Script
« on: July 11, 2017, 11:48:42 AM »
This error probably occurs for the same reason as in your other forum post: The input data files contains only a single atom species. In this case the occupancy array is only one-dimensional. The modify() function in your script, however, expects it to be two-dimensional.

Support Forum / Re: Some problems on OVITO WS Python Script
« on: July 11, 2017, 11:42:05 AM »

A possible explanation for this error is that your input simulation file contains only one atomic species. In this case setting per_type_occupancies=True has no effect. The generated occupancy array is still one-dimensional and you cannot refer to vector components like Occupancy.1 when exporting the results.

Please check if that is the case. You can check the number of atom types in the input and inspect the dimensionality of the Occupancy array by adding something like this to your script:

Code: [Select]
print("Number of particle types: %i" % len(node.source.particle_properties.particle_type.type_list))

I noticed another, unrelated problem in your script: You should not add the SelectExpressionModifier and DeleteSelectedParticlesModifier modifiers inside the for-loop, because then you will insert them many times to the modification pipeline, which becomes very long. Instead, insert the two modifiers only once before entering the for-loop, like you already did with the WignerSeitzAnalysisModifier.


Support Forum / Re: Ovito run problem
« on: July 07, 2017, 11:42:10 AM »
OVITO cannot be run through a remote X window connection. The reason is that it requires direct access to OpenGL graphics hardware.

The only remote execution solution which is supposed to work is TurboVNC/VirtualGL. Perhaps you can make use of that.

If not, you should run OVITO locally. Note that it provides a built-in SFTP client, which allows you to access data stored on remote machines.

Support Forum / Re: Export from OVITO to render in Paraview/Blender?
« on: July 03, 2017, 09:41:56 AM »

Could you please clarify what kind of data you have in mind that should be exported to Paraview or Blender? Are you thinking about

  • atoms/particles
  • bonds
  • surface meshes
  • dislocation lines
  • camera setup
  • animation/trajectories

or all of the above? I'm asking because not all file formats support all kinds of data, so the choice of exchange format depends on what you would like to transfer.

The only export format which supports all types of data and which can be directly written by OVITO is the POV-Ray scene description format. However, as far as I know, this format cannot be read by Blender (and certainly not Paraview). Surface meshes can be exported from OVITO to the VTK format, which can be opened with Paraview. This requires a call to the export_vtk() Python function.

I have been working on an Alembic file exporter for OVITO for some time. This file format can be read by Blender and even supports animated meshes. However, that development work is incomplete and currently paused.

Writing a Python script for OVITO to export data to disk in a file format of your choice is possible, at least when it comes to particle and bond data. For example, I have written a script that exports the current particle set to a IDTF model file for embedding the particle data in PDF documents. Surface mesh data is currently not accessible via the Python interface. Thus, for these things, a real file exporter plugin must be written in C++, similar to the already existing POV-Ray exporter.

Best regards,

Support Forum / Re: Running scripts without a user being logged in
« on: June 27, 2017, 06:17:42 PM »
Hi Alex,

thanks for reporting this issue. I have created a corresponding issue in our tracking system:

During the development of ovitos I did pay attention to making it work even when there is no X server running under Linux (so-called "headless" operation). However, I didn't consider a similar situation under macOS, mainly because I didn't know until now that it is even possible to run macOS computers without a graphical session.

I'll try to look into this issue when I find some time. Perhaps it is possible to detect the headless environment and then implement a similar behavior as under Linux.

Are you sure that setting the cell dimension in this was has no effect whatsoever? My expectation was that the behaviour is similar to what happens in the graphical OVITO version: Manually and temporarily changing the box size is possible, but any changes will be overwritten as soon as another simulation frame is loaded, e.g. by stepping to the next animation frame.

So changing the dimensions of the node.source.cell should be possible as long as you do not trigger a reload of the input file.

Note that, as a workaround to the normal behaviour, you can use the AfffineTransformationModifier. It allows you to permanently overwrite the cell vectors loaded from the simulation file.

Support Forum / Re: Switch renderer in a python script
« on: June 22, 2017, 01:09:41 PM »
Hi Katey,

you can replace the renderer in a Python script by creating an instance of the TachyonRenderer class and assigning it to the renderer field of the RenderSettings object.

This can be done either for the global render settings object:

Code: [Select]
rs = ovito.dataset.render_settings
rs.renderer = TachyonRenderer()

or by creating an ad-hoc render settings object, which is then passed to the Viewport when rendering an image:

Code: [Select]
rs = RenderSettings(renderer = TachyonRenderer())

Support Forum / Re: Anaglyphs in OVITO
« on: June 20, 2017, 09:08:34 AM »
Hi Carlos,

Thanks for the feedback and the suggestion.

What I can say is that I already implemented anaglyph (blue/red) rendering in the interactive viewports of OVITO one or two years ago for testing purposes. But that feature is incomplete (due to my lack of time) and not enabled in normal builds of OVITO. You'll find it in debug versions of OVITO if you build from source. I still need to implement user controls for the eye-distance and other projection parameters. What I don't like about anaglyph rendering is that the effect works only well for colorless datasets. Color coding and other important visualizations tools don't play well with it.

The latest dev build of OVITO contains an extended POV-Ray rendering module, which allows producing omni­directional stereo projection videos. These are 360 degree stereoscopic videos that can be watched with VR headsets or uploaded to Youtube.

There is also a VR module for OVITO under development, which enables realtime walkthroughs of the scene using headets like Oculus Rift and HTV Vive. This is actually very cool. We use it for demo purposes mainly. Some more fine tuning of user controls is necessary for a public release.


Dear Christophe,

I don't think this is a bug; it's normal behavior.

First, allow me to correct you: I assume that you used the Wigner Seitz analysis modifier (not the Coordination Analysis modifier) to compute the occupancy numbers. This is important, because the WS modifier performs a replacement of the dataset: It replaces all atoms from the current configuration with the set of sites loaded from the reference configuration, including all their particle properties. This replacement is done, because the occupancy numbers calculated by the WS modifier are per-site properties, not per-atom properties (It's the atoms that occupy the sites). So you loose per-atom energies and other properties during this step and you are left with only the sites loaded from the reference configuration + information on how many atoms (of the displaced configuration) occupy these sites.

If you really need to select sites based on their occupancy numbers AND the energies of the atoms that occupy the sites, then we have to think about possible solutions. There are different avenues that come to my mind.


Support Forum / Re: python interpreter update in ovito
« on: June 13, 2017, 09:16:08 AM »
The Scipy package is not included in the Python interpreter that ships with Ovito. For installing modules in that interpreter or other options, see

The latest dev version of Ovito also provides the possibility to use the Ovito modules from the standard system interpreter:

Support Forum / Re: What does a particle radius of 1.0 represents?
« on: June 11, 2017, 08:45:47 PM »
Particle radii in Ovito are specified in natural length units of your simulation, topically angstroms.

The value of 1.0 [angstroms] for the default particle radius is only used as a fallback if no per atom type radius has been set or if it is zero. Otherwise the per-type radii take precedence. If the data file contains named atom types (e.g. "Cu"), Ovito should automatically assign a reasonable radius to the types (e.g. 1.28 angstroms for "Cu"). The default radii for the chemical elements can be modified in the application settings dialog. You can also change the current per-type values after loading a data file by selecting the "Particle types" entry in the list box on the right of the main window.

Support Forum / Re: Ovito
« on: June 07, 2017, 08:15:57 PM »
Sorry, I no longer provide current program packages for 32-bit Windows. It would mean a lot of extra work and the demand is quite small. The last program version available for 32-bit Windows was Ovito 2.7.1. You can still download it here:

Ovito internally uses the Voro++ library to compute the Voronoi tessellation. This library only supports 3d tessellation, not 2d.
Note that it should still work if the input cell is 3d, has a finite height, and all points are positioned on the same plane. Of course, you will have to divide the computed atomic volumes by the cell height to get the 2d Voronoi cell areas.

Apparently, Ovito doesn't produce a helpful message. I have created an issue in our issue tracking system here with the aim to improve the situation in the future:

Hi Alex,

I couldn't spot any problem in your code. I suggest you use the -g command line option when running this script with ovitos. This will start up the graphical program version while executing your script and your can check if everything was performed as intended and inspect the computation results. Note that you have to add a line 'node.add_to_scene()' to your script to make this work. Ovito's particle inspection utility will allow you to check the assigned 'Atomic Volume' values of individual particles.


Support Forum / Re: GSD file error
« on: June 06, 2017, 09:56:57 PM »
It would be great if you could post an example GSD file that leads to the error message that you describe. I will then check what is going on. Thanks.


(If the file is too big for this forum, please send it directly to my email address, or post a link to a share hosting service.)

The Viewport.render() method return an image object, which may be manipulated before saving it to a file with the save() method. But this shortcut is not meant for movies, only single frames.

For movies, you have to add a Python viewport overlay to the viewport being rendered. This is basically a custom Python function that gets called by OVITO every time a movie frame from the sequence is rendered. It allows you to draw on top of the rendered images before they are appended to the encoded movie file.

As you have already figured out yourself, you can use '*' in the filename passed to import_file() to load a sequence of data files. However, concatenating multiple sequences (with different base names or in different directories) is currently not supported. You will have to rename the files and put them all into a single directory to produce a single movie from them. Alternatively, you could render three sequences of image files with OVITO and then encode them all to a single video file using some external tool.

Hi Alex,
here is a simple example:

Code: [Select]
import ovito
from import *
from ovito.vis import *

node = import_file("animation.dump.gz", multiple_frames = True)

vp = ovito.dataset.viewports.active_vp

settings = RenderSettings(
    filename = "movie.avi",
    size = (640, 480),
    range = RenderSettings.Range.ANIMATION       

Support Forum / Re: Time (ps) of each frame in a movie
« on: June 02, 2017, 09:08:35 PM »
I don't think so. The LAMMPS dump file format only stores the timestep number. So that's the only information available to OVITO.

If, however, you have a lookup table available, perhaps a text or log file with the tilmestep numbers and corresponding simulation times, you could load it as part of the Python viewport overlay script and do the conversion yourself.

Support Forum / Re: Problem with ovito stopping suddenly
« on: June 01, 2017, 10:26:23 PM »
Thanks, I have downloaded the LAMMPS file. I am currently on a vacation trip, but when I return, I will check if I notice anything unusual when applying the Coordination Analysis modifier to this dataset under Windows.

Can you please confirm that the problem occurred as soon as you inserted the Coordination Analysis modifier after loading the dataset without any other operation being performed before? You did not even have the chance to change the cutoff distance parameter of the cluster analysis?

Furthermore, I noticed that the dump file contains multiple simulation frames. Did you look at frame 0?

Support Forum / Re: Time (ps) of each frame in a movie
« on: June 01, 2017, 05:21:51 PM »
Hi Christophe,

Printing the timestep number in the rendered frames can be done using the Text Label viewport overlay.

However, if you need to convert the timestep to a simulation time in picoseconds first, like in your case, then the Python Script viewport overlay is your friend.

Alternatively, you can insert a Python Script modifier into the data pipeline that performs the numeric conversion of the global "Timestep" attribute (requires just a single line of Python code). Then you can use the  Text Label viewport overlay to print the value of the new attribute. Let me know if you need help with that.



Yes, the binary LAMMPS dump format is generally hard to parse, because one needs to know the exact compile settings, code version and hardware platform LAMMPS was built on. All this information is not stored in the dump file and not available to OVITO. It has to guess it -something which is not guaranteed to work.

When I'm back from vacation (2-3 weeks from now), I will see if I can improve OVITO's heuristic for parsing binary dump files. For that I will need a sample file from you for analysis and testing. Hope you can provide one.

I am moving this discussion to the OVITO issue tracking system, which makes it easier to manage future changes to the source code in response to your request. Please post the sample file there, or send it to my email address directly, thanks.

Excuse me, I am on a holiday trip right now and couldn't test the code I posted. After taking a second look, I spotted at least one mistake:['Shear Strain'].array)

This should be "input.particle_properties", not particle_attributes.

Hi Mike,

Yes, Ovito allows you to do this. You simply have to use the File/Export File function. Pick "Calculation Results Text File" as output format. The Dislocation Analysis modifier outputs an attribute with the name "DislocationAnalysis.length.1/6<112>", which you can export to a text file as a function of simulation time.



You can insert a PythonScriptModifier into the data pipeline in between the shear strain calculation and your SelectExpressionModifier. The Python function determines maximum value of the atomic shear strain property and stores it as a global attribute that is injected into the pipeline. This attribute can then be referenced by the SelectExpressionModifier down the pipeline.

Code: [Select]
import numpy as np


def determine_max_strain(time, input, output):
    output.attributes['MaxShearStrain'] = np.max(input.particle_attributes['Shear Strain'].array)

node.modifiers.append(PythonScriptModifier(function = determine_max_strain))


Pages: 1 ... 15 16 [17] 18 19 20