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 ... 25 26 [27] 28 29 ... 32
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))


Note that the Compute Property modifier, unlike the Coordination Analysis modifier, does not compute the radial distribution function (RDF). The RDF is displayed in the Coordination Analysis panel.

However, because you specifically asked for coordination numbers, I assumed you are not interested in the RDF.

The coordination number computed by the Coordination Analysis modifier for each particle is stored in the "Coordination" output particle property. You can inspect all properties a particle has using the Particle Inspection utility of OVITO. Or you can use the Color Coding modifier, for example, to assign a color to each particle based on one of their property values (in your case the Coordination property).

The Compute Property modifier also outputs the computed values as new particle properties that are attached to each particle. This output data is stored but not immediately visible. You have to make it visible, e.g. using the Color Coding modifier.

In the math expression "ParticleType==2 ? 1 : 0" the ?: denotes a so-called ternary operator. The first table on the documentation page of the Compute Property modifier explains what it does:

A ? B : C   
If A differs from 0 (i.e. is true), the resulting value of this expression is B, else C.

In other words, the expression evaluate to the value 1 if the ParticleType property has the value 2. Otherwise it evaluates to 0. Thus, neighbours of types other than "2" do not contribute to the computed sum.

Support Forum / Re: Problem with ovito stopping suddenly
« on: May 25, 2017, 09:22:56 AM »
Dear Rangsiman,

This sounds like a bug in Ovito's cluster analysis routine, but let's see, I will need some more information to find out what is going wrong. It would be best if you could send me the dump file that is causing the program crash. I will then try to reproduce the problem and hopefully find a quick way to fix it.

It's best if you report this kind of bug report directly to me (mail [at] or, even better, create an issue in our bug tracking system on GitLab in the future (

Anyway, can you send me the dump file via email? Or, if it is too big, put it on a share hosting service and send me a link?



The Coordination Analysis modifier doesn't allows you to take into account the types of the neighbours when counting them. But there is another modifier in OVITO which can do it: the Compute Property modifier

This modifier can mimic the coordination number calculation. For example, to calculate the coordination number using the Compute Property modifier, you simply enter "0" as central expression and "1" as neighbour expression. In other words, the central atom itself contributes nothing to the coordination number while each neighbour within the cutoff radius contributes 1 to the final sum.

Now it is possible to perform a filtering of the neighbours based on their type. For example, if you want only neighbours of type 2 to contribute the coordination number, you would use this if-then-else neighbour expression:

    ParticleType==2 ? 1 : 0

Does that solve your problem already? Note that you could apply the Compute Property modifier multiple times to compute several type-specific coordination numbers.

Support Forum / Re: Problem with render of viewport
« on: May 24, 2017, 09:30:49 AM »
Sure, the image background color can be set in the Render Settings panel:

Support Forum / Re: Problem with render of viewport
« on: May 23, 2017, 10:15:04 PM »
Hi Christophe,

I'm not sure what exactly you have been doing and how the viewports look like, but my guess is that you have selected some atoms. In the interactive viewports, selected atoms are always displayed with a red color (i.e. temporarily overriding their actual colors). However, during image rendering, the selected particles are no longer marked with a red color; they are rendering using their actual colors (being white by default).

If you want to give the selected particles a particular color that also shows up in the rendered image, apply the Assign Color modifier.

Let me know if that doesn't solve your problem.


Hi Christophe,

I am wondering what you use as reference configuration for the WS analysis? Do you use the ideal lattice before relaxation or after?
The surface relaxation likely leads to a shift of atomic planes. Connected to this is the question whether the artefacts on the surface occur already before radiation or only after?

As you have already noted, the defects produced during the cascade can lead to an expansion of the crystal (elastic, thermal or both), which shifts all atomic positions. This lattice strain can lead to artefacts in the output of the WS analysis. The problem -and a possible solution- are discussed on page 2 of the following article:

However, this is not something that can be readily done with Ovito. For the above publication we developed a special post-processing tool which removed the elastic displacements from the atomic positions. After this 'cleaning' step, the configuration could be processed with the WS analysis to find point defects.

Hi Peter,

Your pseudo-code looks good. That's the way it should be done.

There is no special "viewport coordinate system" in Ovito. A viewport's camera defines what can be seen through that viewport. Its coordinates and orientation (the direction vector) are specified in the global scene coordinate system. Units of length match the ones used by your simulation dataset (Ovito itself doesn't specify any particular units of length). You have to position the camera relative to your model (the simulation box). The origin of the scene coordinate system may be located in one of the corners of the simulation box or in its center. That depends on where the simulation data came from and how your simulation has been set up. Check the properties panel of the "Simulation Cell" object in Ovito to find out where the corner of the cell is positioned relative to the scene origin.

The "fov" parameter specifies an angle in radians (for a perspective projection, like in your case). I think Ovito uses 35 degrees, that is 35*math.pi/180 in radians, by default.

Let me know if you have further questions. I don't have an example script at hand. But if you get stuck again, I can write one.

Support Forum / Re: Dislocation Line
« on: May 05, 2017, 03:35:43 PM »

It depends on how you mean it. Ovito can display atoms and dislocation lines simultaneously. The DXA modifier, which generates the dislocation lines, assigns a structure type to every atom. This information allows you to select the perfect crystal atoms and remove them from the view. What remains are the atoms that belong to crystal defects (any kinds of defect, not just dislocations).

However, the DXA algorithm doesn't tie defect atoms to specific dislocation lines. If this is what you are asking for, then the answer would be "no".

Best regards,

Pages: 1 ... 25 26 [27] 28 29 ... 32