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 ... 18
Support Forum / Re: How to add colorbar in Python script?
« on: August 29, 2017, 08:04:52 PM »
Dear Akula,

I'm afraid I have bad news: Python bindings for the color legend overlay are still missing in the current version of OVITO. You won't be able to use it from a script.

I can add the missing bindings in the next program version. However, it's going to be a few days, perhaps weeks, until I can do that and also provide new development builds. Let me know if you cannot find a workaround and need them as quick as possible.


P.S.: I have created a corresponding issue in our issue tracking system:

Support Forum / Re: Count number of displaced atoms
« on: August 22, 2017, 08:37:24 AM »
Sure, if you can define a reasonable displacement threshold, you can do that too. In this case the SelectExpressionModifier is your friend. It allows you to select (and count) atoms whose displacement property fulfills some user-defined criterion.

Support Forum / Re: Count number of displaced atoms
« on: August 21, 2017, 07:40:13 PM »
Yes, I am pretty sure this can be done using Ovito's scripting capabilities. You would have to write a custom PythonScriptModifier for this. This modifier would operate very similar to the Wigner-Seitz analysis modifier of Ovito.

First, you have to load the reference particle positions (the perfect crystal) from a file. See here how to do that.

In your user-defined modifier function, you make use of the NearestNeighborFinder class. It allows you to determine for every atom (of the displaced configuration) which reference site it is located on using a spatial nearest point search. You can then test whether the atom is still on its original site or now on a new site. Some care must be taken if the storage order of atoms changes during the simulation. Then it is important to compare atom identifiers instead of indices to detect whether an atom has left its original site.

Let us know how far you get with this. I can provide further help in the development if needed.

Support Forum / Re: Help needed: can OVITO analyze the ring size?
« on: August 21, 2017, 07:25:55 PM »
Dear YongCheng,

I can tell you that Ovito does not support a bond ring analysis at the moment. It's a messing feature that is on the long-term to-do list.

A standard analysis tool I have heard of is

Best regards,

OVITO allows you to save the rendered image to a PNG or JPEG file.

First, you need to render an image by clicking the "Render Active Viewport" button, see

This opens a new window showing the rendered image. In the toolbar of this window you'll find the "Save to file" button.

Support Forum / Re: PRoblem with render active viewport
« on: August 11, 2017, 04:47:30 PM »
Are you working with the newest OVITO version 2.9.0?

To find out where the problem is coming from, it would be helpful if you could also try the same operation with an older (or newer) release of OVITO. Please let me know if you get the same error message.

Support Forum / Re: Light and shadows arrangement
« on: August 10, 2017, 06:51:15 PM »
No, I don' t have anything like that. You have to "invent the wheel" here :)

When you generate a .pov file using OVITO, it contains the following section at the top, which defines the light source:

Code: [Select]
light_source {
  <0, 0, 0>
  color <1.5, 1.5, 1.5>
  point_at <-0.49923, -0.5547, 0.66564>

This is what you should change to your needs. I would first edit this section by hand and render the scene with POV-Ray to check the results. Once you have found the right light source settings, you can start developing a Python script or a batch script to do the replacement for you.

Support Forum / Re: Light and shadows arrangement
« on: August 10, 2017, 03:22:30 PM »
No, I'm sorry, the current version of OVITO doesn't allow you to control the exact lighting.

One way to deal with this limitation in your specific case would be to export the scene from OVITO to an external POV-Ray file (Select File->Export File in the main menu). You can then manipulate the lights defined in the POV-Ray scene file as needed and render the final image directly using POV-Ray.

This requires that you get familiar with the POV-Ray scene description language and develop some sort of automated script that modifies the light source definition in the .pov file to your needs.

The SelectExpressionModifier doesn't allow you to refer to Python variables from within the selection expression.

There are two possible ways to overcome this limitation:
  • Inject the Python value into OVITO's data pipeline as a new global attribute using a PythonScriptModifier so that it becomes accessible from a SelectExpressionModifier expression.
  • Write a PythonScriptModifier which performs the particle selection instead of using a SelectExpressionModifier.

Strategy 1 is explained here. But I prefer strategy 2, because it is more flexible.

First, take a look at this page to learn how to use the PythonScriptModifier in general. Our aim is to write a Python function which creates a particle selection on the basis of existing particle properties computed by other modifiers in the data pipeline. Typically, one uses a NumPy expression to produce an array of integers with one entry per particle and assign that array to the Selection particle property. Here is an example:

Code: [Select]
def create_my_selection(frame, input, output):
    occupancies = input.particle_properties['Occupancy'].array
    selection_property = output.create_particle_property(ParticleProperty.Type.Selection)
    selection_property[:] = (occupancies > 1)

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

Here, the variable occupancies refers to the array of occupancy numbers previously computed by WignerSeitzAnalysisModifier in your pipeline. The expression occupancies > 1 produces a new array of the same length which contains the value 1 for sites with an occupancy greater than one (i.e. interstitial sites), and 0 otherwise. The resulting array is used to initialise the contents of the Selection particle property, effectively creating a new particle selection which can then be used in subsequent modifiers down the data pipeline.

Make sure the custom modifier function is inserted behind the WignerSeitzAnalysisModifier in the pipeline. Also make sure it is inserted only once. Never insert modifiers in a for-loop!

I can confirm that OVITO can read standard as well es extended CFG files. So far I haven't heard of any problems with the CFG files produced by LAMMPS, so there is not much to look out for when writing these files.

I'm sorry, but OVITO cannot read files in the DCD format at all.

You have to convert the file to something that OVITO can read. See the list of supported formats at the end of this page:

I cannot recommend a file conversion utility, I never used one. But perhaps somebody else here can.

Dea zjhbz,

Yes, creating movie files is possible using OVITO's Python scripting interface. Please start by taking a look at this section of the scripting manual which introduces rendering:

Let us know if you need further help. For creating a movie file you need to configure the RenderSettings object by setting its range and filename attributes.


Support Forum / Re: Running error in vnc
« on: July 31, 2017, 09:48:38 AM »
I haven't seen this particular error before, but here is what I can suggest:

1. Delete the files* from the ovito-2.8.2-x86_64/lib/ovito/ directory. Sometime the version of libstd++ shipping with OVITO conflicts with certain graphics drivers. Alternatively, you can switch to the newer OVITO version 2.9.0, which no longer includes the libstdc++ lib.

2. In my experience the Nouveau driver doesn't play very well with OVITO. There are compatibility issues and performance is poor. I recommend installing the proprietary NVIDIA driver instead.

3. The error message suggests thats is being active. To me that sounds as if the system is falling back to the software rasterizer instead of using the real OpenGL driver with hardware acceleration. Perhaps that is due to the use of VNC. Are you using the TurboVNC/VirtualGL combination or plain VNC?


Support Forum / Re: Bug: Isosurfaces and Show Periodic Images
« on: July 28, 2017, 02:31:31 PM »
Hi Shashank,

Unlike other visualization programs, OVITO works with surface meshes that live in a truly periodic domain as defined by the simulation cell. As a consequence, a surface mesh cannot exist outside of the periodic box. Furthermore, if you change the box size and, with that, the periodicity length after the isosurface has been constructed, then things do not match anymore and you get strange results.

The advantage of a truly periodic surface description as employed by OVITO is that it is possible to translate the surface freely (e.g. using the Affine Transformation modifier) and the program will display the correct cuts at the simulation cell boundaries. Think of the simulation box as a "window" into the periodic domain which can be moved around.
The downside of this is that is not possible to change the box size. It must stay consistent with the periodicity length for which the surface has been computed.

The correct solution in your case would be to first apply the Show Periodic Images modifier and then construct the isosurface for the extended domain. However, the bad news is that the Show Periodic Images modifier is still incomplete. It doesn't replicate the grid data, only the atoms. I will have to take care of this and an issue in our bug tracker system has been created:

Anyway, I understand what the problem is that you are facing and I will think about better ways to deal with this limitation. There are several options that come to my mind. I suggest we continue this discussion in the issue thread linked above.

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:

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