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 ... 21
Support Forum / Re: Averaging the strain tensor
« on: June 24, 2019, 02:47:14 PM »
Yes, the global attribute 'SelectExpression.num_selected' will reflect the changing number of atoms in your region, not the initial number at time 0. This is because the FreezePropertyModifier only freezes the selection state of the individual atoms but not the global value of the attribute dynamically set by the SelectExpressionModifier. What the FreezePropertyModifier, coming after the SelectExpressionModifier in the data pipeline, does is to overwrite the changing selection state of atoms with the saved original state. But it does not do that the same for the 'SelectExpression.num_selected' attribute.

Thus, if you need to know many atoms are selected, you can either use the value of 'SelectExpression.num_selected' at frame 0, or count the number of atoms yourself that are part of the selection set, i.e. by considering the values of the 'Selection' particle property. 

Furthermore, let me point out that you script keeps adding modifiers to the pipeline in a for-loop. This is a typical mistake and is not how it should be done. Instead, you should create and insert all modifiers only once in the beginning before entering the for-loop. Inside of the for-loop, you should only make calls to node.compute() or change the settings of existing modifiers in the pipeline. Otherwise you pipeline will become longer and longer with each iteration of the for-loop.

Support Forum / Re: Averaging the strain tensor
« on: June 23, 2019, 02:40:56 AM »
On the Python side, particle properties such as the 'Strain Tensor' property appear as two-dimensional Numpy arrays containing all the tensor components.  Thus, you should instead use the following code to access the six components of the symmetric strain tensor:

Code: [Select]
StrainTensor = input.particle_properties['Strain Tensor'].array
StrainTensor_XX = StrainTensor[:,0]
StrainTensor_YY = StrainTensor[:,1]
StrainTensor_ZZ = StrainTensor[:,2]
StrainTensor_XY = StrainTensor[:,3]
StrainTensor_XZ = StrainTensor[:,4]
StrainTensor_YZ = StrainTensor[:,5]

Support Forum / Re: Periodic Images in GSD file
« on: June 23, 2019, 02:31:03 AM »
I'm not sure, but to me it looks like the 'particles/image' array in the file 'Homopolymer.gsd' contains only information for frame 0 of the trajectory. Thus, the GSD file reader assumes it is a static particle property that doesn't change with time. This leads to wrong results when the Unwrap Trajectories modifier uses the information to c compute unwrapped coordinates. The periodic image property read from the GSD file should change every time a particle crosses a periodic boundary in the simulation.

Did I get this wrong? Isn't the periodic image property supposed to change with time?

The 'Calculation Results text file' export format is for outputting global quantities only, not per-atom information. Please pick an atomistic file format, e.g. XYZ, to export per-atom data.


You can use the '&&' operator (logical AND operator) to test whether a value is between a lower and an upper bound:

"variable1 < Position.X && Position.X < variable2"

This expression will evaluate to true if and only if both sub-expressions are true.

Regarding you second question I am not sure what is going wrong. The modify() function you posted looks okay. Maybe you are doing things in the wrong order? The Python modifier function must be inserted into the pipeline before the SelectExpressionModifier so that the two attributes are available when the Boolean expression refers to them. Please attach the entire script code if you can't get it working.


Support Forum / Re: Delete Custom Modifier Presets from List
« on: June 21, 2019, 02:58:50 AM »
Hi Gabriel,

I assume you are already using Ovito 3.0.0-dev. Yes, it should be possible to delete a modifier template by going to the "Modifier templates" page of the application settings dialog:

Here you see the list of defined modifier templates and a button to delete those you don't need anymore.

Note that in Ovito 2.9.0 the steps are somewhat different: Select a modifier in your current pipeline, click the "Save Modifier Preset" button in the toolbar,  select the custom modifier you want to delete in the "Preset name" drop-down list, and finally click the trash can icon to the right.


Support Forum / Re: Periodic Images in GSD file
« on: June 21, 2019, 02:48:10 AM »
Ok, I will take a look at the LAMMPS file you provided in a moment.

This is just to inform you that the new Ovito build is available (3.0.0-dev415), which parses the periodic image information from GSD files. The data is stored in the "Periodic Image" particle property. Subsequently, you can apply the Unwrap Trajectories modifier if desired to unwrap the particle positions using this information. The modifier will clear the "Periodic Image" property as a side effect.

Support Forum / Re: Periodic Images in GSD file
« on: June 20, 2019, 06:55:34 AM »
Hi Gabriel,

Yes indeed, OVITO's file reader for the GSD format seems to ignore the image information. I'm not sure whether that is because the official GSD format specification didn't mention the image data at the time I wrote the GSD file reader, or because I didn't have an example file at hand.

Anyway, I now work on extending OVITO's file reader. I expect that I can provide a new program build tomorrow and will get back to you.



Can you specify more precisely what you would like to obtain? Do you want to export the computed atomic strain values for all atoms and for all frames of a simulation trajectory to a series of output files? For this, you can use Ovito's file export function (File menu -> Export file), which lets you write the values of a particle property such as "Shear Strain" to an output file.



The ConstructSurfaceMeshModifier manages the SurfaceMeshDisplay object (so there is no need to create a new one) and you can access it through the modifier's mesh_display field. For example:

Code: [Select]
modifier = ConstructSurfaceModifier(radius = 2.9)
modifier.mesh_display.surface_color = (1,1,0.5)
modifier.mesh_display.show_cap = False


Support Forum / Re: Unable to save animation file
« on: June 17, 2019, 06:04:08 PM »
Hi Etienne,

you are using the Linux version of Ovito 2.9.0, right? We can look into this problem in more detail, but as a quick workaround you may already try switching to the current development build of Ovito 3.0.0.


Support Forum / Re: Calculating the area of Voronoi faces
« on: June 12, 2019, 05:21:06 PM »
Hi Leila,

Yes, Ovito calculates the areas of the Voronoi faces for evaluating the threshold criterion, but it doesn't store them. Thus, there currently is no way to access this information. The only solution would be to modify the C++ code of the Voronoi Analysis modifier, perhaps outputting the face area as an additional property of the bonds the Voronoi Analysis modifier can generate. I'm not sure if this is something you would like to do. It might be easier in this case to directly use the Voro++ package to perform this particular computation outside of Ovito.


I don't think I can tell you anything positive, unfortunately. The grain segmentation function that was part of a development version of Ovito at some point in time (years ago) was a highly experimental and non-official feature, which I have been playing with. I didn't find time to complete it and later removed the function from the code base completely.

Together with Peter Mahler Larsen, the developer of the Polyhedral Template Matching method, we started a new attempt to develop a grain segmentation algorithm last year. But again, due to the general lack of time and resources, we didn't follow through. We suspended the work after experimenting with a few approaches and testing out several ideas. In its current state, the grain segmentation algorithm is not usable and I don't like the idea of anybody else using it. Our ongoing work is organized in the 'grain_segmentation' branch of the Ovito gitlab repository, by the way.

Please remind me again who you are. Have we been in contact before? Did I share the experimental Ovito build that included the grain segmentation function with you? I am trying to understand whether you are interested in only  (re)building the legacy grain segmentation code (to reproduce old analysis results perhaps) or rather in finding a robust segmentation tool for a new project.

Since this topic is not related to the official Ovito version, I suggest we continue this discussion via email, not in this forum thread.


Support Forum / Re: Regarding Wiegner Seit modifier
« on: June 08, 2019, 11:29:22 AM »
Dear Bahman,

I am wondering: Did you already read the section "Affine mapping of the simulation cell" on the documentation page of the WS modifier? It can be found here:

This section explains the purpose (and naming in the UI) of the modifier option controlling the mapping of the deformed simulation cell back to the undeformed geometry.


Hi Cody,

The macOS build instructions found in the Ovito manual are not up to date, I must say. Sorry for probably wasting some of your time with that.

There is a text file in the GitLab repo where I keep track of the installation+build steps required to build the official Ovito binaries for macOS:

This is a more personal memo with fewer explanations, but at least it is always fully up to date. Note, however, that it includes some extra steps which might not be necessary if you just want to building a locally running version of Ovito and not a redistributable program package.

I'm not sure if I read this right: You don't want to build the latest snapshot of the Ovito code but rather an older version (2.7.1). Is that right? This could make things more difficult, because build steps have changed over time and older versions of third-party libraries may not be easily available anymore. Please take a look at the archived version of the file build_macosx_howto.txt linked above, which was tagged with release 2.7.1 or whatever version you intend to build.



Given the magnitude of the (partial and full) Burgers vectors and the atomic plane distance of the crystal it should be possible to predict what the atomic strain values will be. But making this prediction is rather difficult and I don't have any numbers readily available. It's probably easier to use the Atomic Strain modifier and inspect the typical values found for atoms adjacent to the slip plane (or their distribution). You can then derive appropriate thresholds to discriminate between the two types of slip.

I have attached an example analysis from a simple shear strain simulation of an FCC crystal. The left picture shows the calculated atomic shear strain values, and the right hand side shows the results of the Common Neighbor Analysis for the deformed configuration. You can find slip traces of a full dislocation (yellow arrow) and partial dislocations (blue arrow). The latter slip traces are associated with a remaining stacking fault, visible in the second picture (red hcp-like atoms). The shear strain values of the atoms in the partial slip trace are around 0.2 while the values of atoms in the fully slipped crystal reach around 0.4.



You should be able to use the Atomic Strain function of OVITO for that (set the cutoff radius to be halfway between the first and second neighbor distance). Due to dislocation slip, atoms right above and below the glide plane will exhibit high atomic shear strain values. You can use the Color Coding modifier to visualize those values or use the Expression selection modifier to select and highlight atoms whose shear strain value is above a threshold.

Note that this method is not exact, because atomic shears will be affected by elastic displacements of atoms, thermal vibrations and other noise. But since the atomic shear values due to plastic slip are typically much larger than these other effects, it should still work.

Crystal slip resulting from partial dislocations and full dislocations should lead to markedly different shear strain levels. So it should be possible to discriminate between the two types as well.


Support Forum / Re: Can ovito scripting work in Jupyter notebooks?
« on: May 15, 2019, 09:51:49 AM »

Please take a look at this section of the user manual:

We don't have any first-hand experience here with using the Ovito Python modules within Jupyter. But in general there are two possible strategies you can try: Either you keep using the Python interpreter that ships with Ovito ("ovitos") and use pip to install whatever third-party modules you need (e.g. jupyter). Or you build Ovito from source. Then you should be able to use its Python modules from other interpreters. This path is a bit more tricky, because the critical step here is to make sure that Ovito gets built against the right Python interpreter and against the right version of the Qt libraries. It must be same version that is used by the PyQt5 module installed in the same Python interpreter.

Note also that a colleague from Max-Planck-Institute in Düsseldorf has created a Conda package for Ovito 2.9.0:

Support Forum / Re: Request for yum repository
« on: May 14, 2019, 05:10:09 PM »
We provide prebuilt binary packages of Ovito for Linux on our website. So normally there should be no need to build Ovito from source. Please let us know why you would like to specifically have a Yum package of Ovito.

Yes, Ovito 3.0.0 brings several changes in the Python interface.

The RenderSettings class has been deprecated, and its use is discouraged. Instead, simply use the Viewport.render_anim() function.

The RenderSettings class is still available in case you want to keep using it. The "everyNthFrame" field has been renamed to "every_nth_frame".

The documentation of the updated Python interface is still incomplete in some places. In particular the '_' notation is not yet introduced anywhere. Probably it isn't needed anyway in your particular case. Currently, Ovito prevents you from modifying the display radius and color of particle types in the pipeline output. This makes sense, because such a change could cause unwanted side effects. The solution is to instead modify the original data that enters the pipeline. This data is cached by the FileSource object delivering it from the input file. See the documentation of the FileSource. One of the example code snippets demonstrates how to configure the display properties of individual particle types. Hope this helps you solve the problem. If not, let me know.

By the way: I put a new development build of Ovito 3.0.0 online yesterday, which already contains an extension that allows you to control the orientation of the camera's vertical axis:

With that, you no longer have to adjust the global application settings to change the orientation of the box in the rendered picture.

Yes, I just realized that some more extra care is needed in this case. Sorry, for leaving you along with the problem too soon.

First, to find out what the default value of the FOV parameter is, you need to create a Viewport, set its projection type to 'perspective', and then query the current value of the FOV parameter:

Code: [Select]
>>> from ovito.vis import *                                                                                                                                                                             
>>> vp = Viewport()                                                                                                                                                                                     
>>> vp.type = Viewport.Type.PERSPECTIVE                                                                                                                                                                 
>>> print(vp.fov)                                                                                                                                                                                       

The default value is 0.61 (radians), which corresponds to 35 degrees. To zoom in, you should set the FOV parameter to a smaller value, but which is still on the same order of magnitude, e.g. 0.3. Make sure to set the FOV really after setting the projection type, because setting the projection type may reset the FOV value back to its default. Thus, instead of
Code: [Select]
vp = Viewport(type=Viewport.Type.PERSPECTIVE, fov=###)
better do
Code: [Select]
vp = Viewport(type=Viewport.Type.PERSPECTIVE)
vp.fov = 0.3

Note that I haven't tested your code directly. Please check if you can get better results now with the hints I gave. If not, I'll have to take a closer look at your script.

Regarding your second question: No, at the moment there is no way to select which coordinate axis points upward from Python. I will add a corresponding option in a future version of OVITO.


You probably should set the Viewport.fov parameter to a smaller value. This should give you a more parallel type of perspective projection.


Support Forum / Re: animated motion of particles using trajectory line
« on: April 18, 2019, 03:07:00 PM »
Yes, in Ovito 3.0.0-dev, the Generate Trajectory Lines modifier is all what is needed to produce this kind of animation.


Support Forum / Re: error during compilation
« on: April 17, 2019, 06:50:56 PM »
Thanks for letting us know.

Could you please also give us some info on the environment in which you have been building Ovito. Like the OS name and version, and the version of the Libav library on your system.


Support Forum / Re: The DXA misjudges the burgers vector
« on: April 17, 2019, 12:13:06 PM »
Right, I forgot that the Affine Transformation modifier won't act on the dislocations lines. That's a missing feature I might add in a future version of Ovito.

Another option is to use the object rotation tool from the main tool bar, see the attached screenshot. It allows you to rotate the entire model around the coordinate axes.

Support Forum / Re: The DXA misjudges the burgers vector
« on: April 17, 2019, 11:06:49 AM »
There might be another solution, which is even easier than what I have proposed before:

You can apply an Affine Transformation modifier to your model prior to the Dislocation Analysis (DXA) modifier in order to bring the crystal (including the simulation cell) into a different orientation, which shows less spurious symmetry flips. The aim is to (roughly) align the [100] direction of your crystal with the x-axis of the global coordinate system, the [010] direction with the y-axis, and the [001] direction with the z-axis. For this specific crystal orientation, DXA includes extra measures to avoid symmetry flips and should yield a stable crystal lattice orientation.

I don't know the orientation of your crystal, but it shouldn't be too difficult to figure out the rotation matrix that is needed to transform the crystal into the [001] standard orientation. If you like, you can then apply a second Affine Transformation modifier, with a reverse rotation matrix, to bring the crystal and the extracted dislocation lines back into the original orientation after DXA has been performed.

Support Forum / Re: The DXA misjudges the burgers vector
« on: April 17, 2019, 09:59:49 AM »
The two screenshots you posted show only a single dislocation line, so there wouldn't be much to identify. But do you mean you actually have multiple dislocations in your simulation, all with different 1/2<111> Burgers vectors, that you would like to identify?

One way would be to look at the "spatial Burgers vectors" of these dislocations. As mentioned before, these vectors are all expressed in the same static and global coordinate system and are not subject to spurious lattice symmetry flips. However, they are subject to elastic lattice strains, meaning they will never be mathematically exact 1/2<111> vectors. Thus, you will have to apply some rounding procedure to determine the true Burgers vector of each dislocation.

Another possibility is to consider the lattice orientation that has been assigned to the crystal by the DXA. It can be used to detect symmetry flips and transform the crystal orientation (and with it the Burgers vectors of all embedded dislocations) to a specific orientation that you specify. Then you could directly work with the true Burgers vectors of the dislocations. However, this approach is probably more complicated and requires functions from Ovito's Python interface that are not documented. I would have to give you more information about this.


Support Forum / Re: The DXA misjudges the burgers vector
« on: April 17, 2019, 07:39:45 AM »
Dear Peter,

This surprising behavior is not a bug in the DXA and can be explained as follows:

You are dealing with a BCC crystal. Every cubic crystal lattice has 24 equivalent orientations. Thus, given a crystal model that has some orientation in space, you have 24 different ways of defining the axis orientations of the crystal, i.e., the spatial directions of the [100], [010] and [001] Miller indices.

When the DXA sees your input crystal, it will pick one of these 24 physically equivalent rotations at random. It's important to note that the algorithm newly picks the orientation in each simulation frame in an uncorrelated manner, because it doesn't remember which orientation it has used for the previous frame.

So what you are observing is a flipping of the crystal lattice orientation to a different symmetrically equivalent orientation. Even though the dislocation doesn't change in any, the Burgers vector displayed by the DXA apparently does, because it gets expressed in a newly oriented lattice coordinate system.

The column "Spatial Burgers vector" shows that the physical Burgers vector, which is obtained by transforming the calculated true Burgers vector from the lattice coordinate system to the simulation coordinate system, indeed does not change. [2.4739,0.00,0.00] and [2.4739,0.00,-0.00] are essentially the same spatial vector --small numerical errors aside that typically occur due to elastic distortions of the crystal.

The dislocation line changes color, because you selected to color the lines "by Burgers vector" and not "by dislocation type". In the latter mode, the line would probably stay green, because 1/2[111] and 1/2[11-1] belong to the same class of dislocations.

Note that the spurious flipping of the crystal orientation only occurs for certain alignments of the crystal lattice, like in your particular case where the <111> direction is aligned along the y-axis of the simulation coordinate system. For the DXA, this orientation is right on the edge of a standard orientation triangle. So even an infinitesimal reorientation of the crystal into an adjacent standard triangle, which is associated with a symmetry flip of the lattice. Other orientations, which are located more in the interior of the standard triangle, won't show this unstable behavior and DXA will typically maintain the same orientation over time.


Pages: [1] 2 3 ... 21