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 ... 6 7 [8] 9 10 ... 18
Support Forum / Re: Identification of Burgers vector of defects
« on: March 14, 2018, 01:57:22 PM »
Hi Christophe,

Please excuse the late reply. I was away from work for some time and lost track of the incoming requests.

The DXA function of OVITO can identify dislocation loops (including their Burgers vector) if they are not too small. What "not too small" means is not so easy to define precisely, but it basically means that the defect must be ring-like and not sphere-like. There must be some "good" crystal material in the center of the defect and the defect atoms should form a loop structure around it. Then the DXA function will identify it as a dislocation loop with a certain Burgers vector and produce a corresponding line representation of the defect.

Hope that answers your question. Let me know if you need further help.


Support Forum / Re: atomic strain
« on: March 14, 2018, 01:51:41 PM »
Yes, you could compute the M matrix using OVITO's Compute property modifier (using the neighbor compute mode). Note, however, that you would need to define one modifier for each of the 9 components of the M matrix, because the modifier lets you only perform scalar computations.

A second option is to write a user-defined modifier function in Python. This would be the easier solution if you already have knowledge of Python.

Support Forum / Re: lattice orientation of a complex structure
« on: March 13, 2018, 09:41:58 AM »

I am afraid that isn't much that can be done. The only chance you have is if two of the six sub-lattices you mentioned would form a HCP lattice. Then you could select these atoms and use the PTM modifier on the subset of atoms only.

I would be interesting in knowing what kind of crystal structure you are dealing with. What's the name of the crystal structure (or the material)? Perhaps you have a picture of unit cell. I can discuss with Peter Larsen, the developer of PTM, whether it would be possible to add support for the structure to his identification algorithm.


Support Forum / Re: atomic strain
« on: March 13, 2018, 09:35:09 AM »
I understand your concern. But the reasoning behind this behaviour is the following: Strain is a quantity that is always calculated with respect to some reference configuration. For atoms within the perfect bulk, it is easy. The perfect lattice is used as ad-hoc reference configuration in the elastic strain calculation. For atoms within the grain boundary core, however, it's not clear what would be the right reference configuration. OVITO has no information about how a perfect, elastically unstrained twin boundary should look like. This kind of information can only be provided by the user, but then we are basically performing a regular atomic strain calculation again, which requires an explicit reference configuration.

Support Forum / Re: atomic strain
« on: March 13, 2018, 12:51:37 AM »
It is essential that you activate the 'Adjust simulation box size' option in the 'Show periodic images' modifier. Without it, the atoms are duplicated, but the periodic volume remains the same. Then you get overlapping atoms, which let's the structure identification algorithm fail.

Support Forum / Re: atomic strain
« on: March 13, 2018, 12:02:13 AM »
Please upload the structure. I will take a look myself and let you know if something is wrong with it.

Support Forum / Re: rendering quality
« on: March 12, 2018, 11:09:40 AM »
Dear Kyu,

Yes, you can specify the resolution of the image or movie to be rendered in pixels. It is done by settings the size attribute of the RenderSettings object as shown here:

You might have to adjust the zoom level as well to make the simulation box fill the entire picture. This is done through the Viewport.fov attribute.


Support Forum / Re: atomic strain
« on: March 12, 2018, 11:04:52 AM »
Dear Hui,

it is not exactly what Atomeye does, but I think it is close to what you have in mind. The 'Elastic Strain Calculation' function of OVITO calculates the per-atom elastic strain tensor. This tensor describes the elastic distortion of the lattice with respect to an ideal crystal state, which doesn't have to be explicitly specified in terms of atomic positions:

Note the following important limitation: The elastic deformation can only be calculated for atoms that form a elastically distorted, but otherwise perfect lattice. For atoms that are part of crystal defects, the elastic strain is not well defined and OVITO won't calculate a value for them.

Best regards,

Support Forum / Re: How to visualize bonds?
« on: March 11, 2018, 12:09:21 PM »
Dear Young,

I'm not sure what exactly you mean with "create bonds as the configuration itself". Are you looking for a function to manually create bonds between selected particles within the program?

OVITO can read bonding information from LAMMPS data files and PDB files. The PSF format, however, is not supported yet.


Support Forum / Re: Python script modifiers
« on: March 05, 2018, 03:03:53 PM »
Looks like the manual editing of the HTML page requires some more care. I think I've fixed the problem now. Please try again.

Support Forum / Re: Python script modifiers
« on: March 05, 2018, 01:58:30 PM »
I just realised that you stumbled over an old documentation bug. The last line of the orientation colouring script has been cut off in the user manual. This error has been fixed some time ago in the development version of OVITO, but it is still present in the documentation of OVITO 2.9.0. I now manually added the missing script line to the online version of the scripting manual:

I'm sorry for the confusion.

Support Forum / Re: Python script modifiers
« on: March 01, 2018, 05:49:58 PM »

You don't need the Color Coding modifier. The Python script should directly assign colors to the atoms. Don't you see any colors? Make sure that the "Output - Lattice orientation" option is activated in the PTM modifier. If you still don't see any colors being assigned, please check if the Python script modifier displays any error messages.


Support Forum / Re: segmentation fault
« on: February 28, 2018, 09:27:21 PM »
Hi Emile,

I could not reproduce the segfault under macOS using Ovito 2.8.1. Which operating system do you use? And have you tried newer versions of Ovito already?


Support Forum / Re: how to import_file with specified dump files
« on: February 27, 2018, 09:27:54 AM »
Hi Kevin,

I don't think that this can be done with any of the current program versions. You need to live with the fact that OVITO will read in all the files in the series.

But I like the idea and agree that, in general, this would be a useful feature that would bring additional flexibility. I added a corresponding feature request to the GitLab project and hope to find some time to implement this extension in the future:


Support Forum / Re: Combine Particle Set Modifier issue.
« on: February 22, 2018, 10:01:03 AM »
Thanks for sending the data files. Now it became clear what the issue is.

It turned out that the 'Combine particle sets' modifier in the current Ovito version is still too dumb to combine datasets with different atom types. I worked on the modifier code yesterday to make it smarter. Please download the latest development version of Ovito (3.0.0-dev123), which is able to merge datasets correctly that do not have the same set of particle types:

Let me know if you still experience any problems.


Support Forum / Re: How to make ovito write data file in a modify way
« on: February 21, 2018, 10:11:46 PM »
Just to let you know: The latest development version of OVITO (3.0.0-dev123) lets you set the desired numeric precision for file export.

Support Forum / Re: Combine Particle Set Modifier issue.
« on: February 20, 2018, 03:03:31 PM »
Can you please post the data files with the two atom sets? I would like to reproduce the problem that you are facing. Right now, I still don't understand what you are doing and what is happening. On one hand you write that atom IDs are not correct, on the other hand you talk about chemical types not being as expected. Note that, in Ovito, all particles have two different properties: "Particle Type" and "Particle Identifier", which have nothing to do with each other. The first property describes the chemical type of an atom while the second property is a numeric identifier, which is unique throughout a system. The particle type determines the display color of particles, while the particle identifier is a non-visual property, which is used by Ovito behind the scenes to track particles over time.

My suspicion is that there might be problem with the particle types. Note that Ovito encodes the chemical types using numbers, e.g. Li=1, Ni=2, O=3. if this mapping differs in the two input files, a problem may arise when the datasets are merged into one.

Support Forum / Re: Combine Particle Set Modifier issue.
« on: February 19, 2018, 10:31:34 PM »
I don't understand what you mean with the "labels of the atoms". Do you mean the atom types, the atom IDs, or some other property? Please clarify.

If you mean the atom IDs, please note the following statement from the user manual:

The IDs of particles loaded from the second file are newly assigned by the modifier to ensure that they do not conflict with the existing particle IDs in the current dataset.

This is to ensure the uniqueness of the particle IDs.


Support Forum / Re: how to display dumbbells through W-S defect analysis
« on: February 19, 2018, 04:14:35 PM »
Ok, I took the time today to implement the new output mode and extend the W-S modifier as described above. You can find the extension in the latest development version (dev120).
Note that the user manual hasn't been updated yet, but the scripting documentation already reflects the addition:

Let me know if it works (or not).

Support Forum / Re: How can we get a bond angle distribution in ovito?
« on: February 16, 2018, 04:17:41 PM »
Hi there,

Here is a script I wrote some time ago for Ovito 2.9.0 to calculate the bond-angle distribution for a system (for demonstration purposes). It may serve you as a starting point to develop a solution for your specific problem. Disclaimer: I never used the script for real-word analyses and I never verified that it is working correctly. So use with caution.


I can only guess, but the discrepancy between the results obtained within the GUI and with ovitos are likely due to different modifier settings. In general, when you use a modifier in a script executed with ovitos, its parameters are initialized to hard-coded default values, which are all documented in the Python scripting reference. In contrast to that, when you insert a modifier into the pipeline using the GUI, some its parameters are typically initialized the most-recently used values (Ovito memorizes them in a config file in the user's home directory). Remaining parameter are always initialized to the same hard-coded values as in ovitos.

So please make sure that the WignerSeitzAnalysisModifier.eliminate_cell_deformation setting has been set consistently in the GUI and in the script. Note that, in Ovito 3.0, this parameter has been deprecated and replaced by the ReferenceConfigurationModifier.affine_mapping parameter.

Okay, good to here that you solved the problem already.

I still don't understand why the loaded environment module affects the operation of Ovito on your HPC cluster, but I guess that is not important. What counts is that you got it working. In general, however, I can say that the binary Ovito installation packages come with their own copy of the Python interpreter. So there should be no need to load any Python interpreter on the system in order to use Ovito. But I can also say that the Python interpreter shipped with Ovito may not be perfectly isolated from the system environment. So things like environment variables set on the local system may interfere and still affect its operation (possibly letting it crash).

I forgot to tell: Within GDB, type "run" and press enter to start the execution. In case the segfault occurs and execution stops, type "bt" + enter to get the backtrace.
Even without debugging symbols included in the executable, you should get some first, approximate information abut the location where the crash happened.


What happens if you run

  ovitos -c "pass"

This command will execute just the Python "pass" statement and nothing else. If possible, run this in a debugger such as GDB:

  gdb --args ovitos -c "pass"

Perhaps this allows you to capture a stack trace, which could tell us more about the reason for the segfault.

The NearestNeighborFinder.find() yields a bunch of information about the neighbors of a particle. Aside from the distance and the neighbor vector, it also returns the global index of the current neighbor particle. This index can be used to access other properties of the neighbor particle. Example:

Code: [Select]
foo_values = data.particle_properties['foo'].array
for index in range(data.number_of_particles):
    for neigh in finder.find(index):
        neigh_foo = foo_values[neigh.index]  # Access the 'foo' value of the current neighbor


Yes, unwrapping the atomic coordinates can be achieved, but it's complicated:

  • First, go to frame 0 of the sequence and make a copy of the current atomic positions using the Freeze Property modifier. Name the copied property "pos0", for example.
  • Use the Displacement Vectors modifier to let Ovito compute the atomic displacements with respect to the initial positions. This is where the minimum image convention comes into play.
  • Finally, use the Compute Property modifier to overwrite the values of the Position property. For the X component, enter the expression "pos0.X+Displacement.X". For the other two components, do correspondingly.


After your activate the WignerSeitzAnalysisModifier.per_type_occupancies option, the occupancy numbers will be calculated element-wise. Instead of a total "Occupancy" number for a site, partial numbers "Occupancy.1", "Occupancy.2", etc. are calculated. The sum of all partial occupancy numbers for a site is always equal to the total number computed without the per_type_occupancies option.

Given that you have two atom types in your simulation, you need to make sure that both partial occupancy numbers are zero for a Si-site to detect vacancies:

  Occupancy.1 == 0 && Occupancy.2 == 0 && ParticleType == 1

This expression will make sure that Si-sites now occupied by a C-atom in the displaced configuration are excluded from the selection.
Regarding your second question: The expression

  Occupancy.1 == 2 && ParticleType == 1

will select Si-sites that are occupied by exactly two Si-atoms, regardless of how many C-atoms are on the same site. The question is: what exactly do you consider a "Si SIA"? Maybe a site that was originally occupied by a C-atom and is now occupied by two Si-atoms should also count as a "Si SIA". To catch those kinds of sites as well, you might have to extend the expression with additional criteria that are combined with a logical OR operator (||).


Support Forum / Re: How to calculate max and min of cluster's position
« on: February 13, 2018, 09:20:46 AM »
Hi Kevin,

Thank you for sharing the solution to your own problem. I hope you don't mind if I comment on your script. I agree with the way you determine the size of the stacking fault. But I am wondering if the sequence of 5 modifiers is really necessary to extract the SF atoms. In my eyes, the ClusterAnalysisModifier is not necessary. You could have directly deleted all non-HCP atoms as follows:

Code: [Select]
# Modifier 1: CNA                                                                                           
# Modifier 2: Select non-HCP atoms                                                                 
node.modifiers.append(SelectExpressionModifier(expression = 'StructureType!=2'))
# Modifier 3: Delete them                                                                                   

A ClusterAnalysisModifier would only be necessary if there are several independent HCP atom clusters in your system and you want to focus on a particular one of them, perhaps the largest one. Then, however, you should make use of the ClusterAnalysisModifier.sort_by_size option and delete all atoms with property Cluster!=1.

Best regards

Support Forum / Re: source, output attributes
« on: February 12, 2018, 09:51:34 PM »
I guess this behaviour is due to the two parallel caches the FileSource maintains. There is one cache (let's call it 'A') that contains the data for the most recently requested frame, and a second cache (let's call it 'B') for the data at the current animation time. When a new request for a frame is processed, the FileSource first checks if the data for the requested frame is already available in either of these two caches. Only if that is not the case, the data is retrieved from the external file(s).

So in your case, the following happens:

Code: [Select]
import_file(...) # This fills cache B with data of frame 0
node.compute(3)  # This fills cache A with data of frame 3
node.compute() # Cache A already contains the data for the requested frame. Returns immediately.

Cache B is not updated again in this case. But cache B is exactly the one that the FileSource object exposes to the Python script. This explains the output you see, I think.

Based on your input, I extended the Python interface of the FileSource class a bit. In the newest development build of OVITO, the class provides a new method compute(), allowing you to request arbitrary frames from the FileSource. Now it no longer matters which data is currently in the visible cache of the FileSource. Please see the updated documentation for details:

Support Forum / Re: Correlation Function for Python
« on: February 12, 2018, 09:33:32 PM »
I have published a new development build (dev155) of OVITO 3.0, which provides Python-based access to the Correlation Function modifier an its results: 

Pages: 1 ... 6 7 [8] 9 10 ... 18