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
1
Support Forum / Re: Steinhardt order parameters
« on: July 22, 2019, 11:22:10 AM »
Hi,
Which Ubuntu package containing the Boost library did you install? I think you'll need the "libboost-program-options-dev" package to build the ASAP code under Ubuntu.
-Alex

2
Support Forum / Re: Incuding Python dev in the ovito distribution
« on: July 20, 2019, 05:40:05 PM »
Hi Linyuan,

Yes, I will see if we can do that. On which operating system do you use Ovito?

-Alex

3
Dear DJing,

Ovito doesn't have a function for this specific type of interface analysis, it only provides general visualizations functions for plotting per-atom vector quantities that have been calculated by other means. I'm not sure which other codes/tools are publicly available that support the calculation of interface disregistry vectors. I think it's best if you contact authors of papers that contain this type of analysis and ask them how they did it.

-Alex

4
Support Forum / Re: molecular surface mesh
« on: July 16, 2019, 10:59:14 AM »
Hi Matteo and Popperoga,

Yes, the surface construction method currently implemented in Ovito differs from the usual approaches you find elsewhere. It treats the atoms always as point-like and their radius property is ignored. The only input aside from the atomic positions is the size of the rolling probe sphere. So this approach is not really suitable for measuring molecular surface areas, I agree.

We currently don't have other surface measurement tools in Ovito, but that is something we could work on in the future. Thanks for sending the reference to the 1983 paper. I will take a look and see how much effort it would be to integrate something like this in Ovito.

My understanding is that there are two general classes of surface analysis algorithms: The first type of algorithm just measures the accessible surface area of an atomic structure, e.g. using a stochastic Monte Carlo sampling technique, but doesn't actually construct a geometric representation of the surface. The second class of algorithm generates a visual model of the surface in the form of a triangulated surface mesh, which can be used to measure its area but also to visualize the surface. Which of these capabilities are relevant in your particular case?

-Alex

5
Support Forum / Re: amorphous structure for iron in radiation damage
« on: July 11, 2019, 09:12:49 AM »
Hi,

No, that statement would not be right in general. The common neighbor analysis will only mark those atoms as 'BCC' that have 8 nearest neighbors and 6 second nearest neighbor atoms positioned on lattice sites. All other atoms will be marked as 'Other'.

For example: If there is a vacancy in your crystal, which is quite common in irradiated materials, all the surrounding 12 atoms will be marked as 'Other', because they are all missing at least one neighbor atom. The material surrounding the vacancy is not amorphous, it's still a crystal but a defective one.

-Alex

6
Support Forum / Re: Trajectories selection modification
« on: July 10, 2019, 02:05:20 PM »
Hi Rafael,

You mean to select atoms that enter a spatial region at least once throughout the simulation, i.e., whose trajectory lines intersect the region?

-Alex

7
Support Forum / Re: How to visualize bonds?
« on: July 08, 2019, 01:34:41 PM »
No, Ovito currently cannot read "local" style dump files. Only the "atom" and "custom" styles can be read.

The problem is that Ovito cannot know what information the local dump file contains, being it bonds, angles or something else. Furthermore, the meaning of "c_1" is not transparent to Ovito. It cannot know that this is a "compute property/local" yielding the atom indices connected by the bonds.

I am wondering, what is you goal here? Is there a reason why the bond topology is stored in a dump file and not in a data file?

8
Support Forum / Re: Averaging the strain tensor
« on: July 04, 2019, 07:40:07 AM »
The easiest solution is to make sure the imported atom coordinates are already in unwrapped form. For example, when using LAMMPS to generate dump files, the "xu", "yu" and "zu" fields should be exported.

In case you have already run your simulation and it is too late to do this, you need to use OVITO's "Unwrap Trajectories" modifier, which is only available in the latest development build of OVITO 3.0.

This modifier can either make use of the image flag information (ix,iy,iz) to unfold the trajectories -if these fields are present in the dump file-, or it can try to detect crossings of the periodic boundaries by analyzing the trajectories for discontinuities.

See here for more information: https://ovito.org/manual_testing/particles.modifiers.unwrap_trajectories.html

You need to insert the Unwrap Trajectories modifier into the data pipeline before your user-defined modifier function for computing the center of mass.

9
Support Forum / Re: Tio2 mechanical analysis
« on: July 02, 2019, 02:41:29 PM »
Dear Baham,

Yes, Ovito's dislocation analysis function is not working for TiO2 Anatase crystals, mainly because there is no structure identification algorithm (such as CNA or PTM) available that could handle this structure type. Extending the capabilities of Ovito in this direction is an ongoing effort.

-Alex

10
Support Forum / Re: minimum distance between two atoms
« on: June 26, 2019, 07:18:06 AM »
Hi Dori,

This can probably be implemented using a small Python modifier function. Do you mean the minimum distance between any two atoms in you super cell or a particular pair of atoms?

-Alex

11
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.

12
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]

13
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?

14
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.

15
Hi,

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.

-Alex

16
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:

http://ovito.org/manual_testing/modifier_templates.html

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.

-Alex

17
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.

18
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.

-Alex

19
Hi,

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.

-Alex

20
Hi,

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

-Alex

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

-Alex

22
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.

-Alex

23
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.

-Alex

24
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:

http://ovito.org/manual_testing/particles.modifiers.wigner_seitz_analysis.html

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.

-Alex

25
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:

https://gitlab.com/stuko/ovito/blob/master/doc/develop/build_macosx_howto.txt

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.

-Alex

26
Hi,

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.

-Alex

27
Hi,

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.

-Alex

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

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

http://ovito.org/manual_testing/python/introduction/running.html#third-party-python-modules

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:

https://anaconda.org/conda-forge/ovito

29
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.

30
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.

Pages: [1] 2 3 ... 21