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 ... 16
Support Forum / Re: What's the default radius for atom
« on: January 14, 2018, 12:41:49 PM »
Dear Justin,

The default atom radii of OVITO are predefined in this source file. The radius values match those used by the VESTA software. Here, the radii/colors are defined in the file elements.ini that is part of the VESTA distribution. It's likely that OVITO's defaults were taken from there.

However, it's still unclear what the physical meaning of these radius values is. I'm not sure, I must admit.

If you have the feeling that these default values are not reasonable or should be replaced with something better, please let me know. I would be willing to replace them if it makes sense.


Thank you for the suggestion. I extended the user manual to describe how and where OVITO keeps its configuration data:

Support Forum / Re: cannot construct mech in dislocation analysis
« on: January 04, 2018, 05:14:09 PM »
Thanks Ann, I downloaded your test file. However, I was not able to reproduce the problem on my computer. Probably, I am using other DXA parameters than you. The easiest way to exactly reproduce your settings on my local machine would be if you save your setup as an .ovito file and give that file to me. For that, first make sure OVITO is giving you the error message. Then save the scene using the File/Save program state function in the menu. Finally, upload the .ovito state file here.

Furthermore, I noticed that your simulation is periodic only in the X-Y plane, but not along the Z direction. When loading the XYZ file, OVITO assumes by default that periodic boundary conditions are used in all three directions. This may lead to problems, because the z-coordinates of some of atoms are actually outside the simulation box in your case. Please try if turning off periodic boundary conditions along Z makes any difference. You can do that in the Simulation Cell panel.

Support Forum / Re: how to display dumbbells through W-S defect analysis
« on: January 04, 2018, 04:56:44 PM »
Yes, I agree, this is an interesting question  :) I do not see that the current version of OVITO provides a solution to this problem, which others have been facing before.

Basically, the W-S modifier needs to be extended (requiring code modifications). Here is what I have in mind: We could add an option that turns off the normal behavior of the W-S modifier: Instead of replacing the current configuration with the reference configuration, the current configuration is kept. The occupancy numbers that are assigned to the individual atoms then represent the total occupancy of the sites the atoms have been assigned to. The two atoms forming a dumbbell configuration, for example, would both have Occupancy==2. Of course, in this mode it would not be possible to select vacancies, because there are no atoms occupying vacancy sites. Also, the "Output per-type occupancies" option would not make any sense in this mode.

What do you think?

In principle, it is possible to implement this algorithm using a custom "Wigner-Seitz" modifier written in Python. So if you have an urgent need for this approach, that would be the way to go. Otherwise, let me create an issue for this feature request on our GitLab site and I will try to extend the built-in W-S modifier when I find some time.

Support Forum / Re: Segmentation fault -- (Linux) OVITO 3.0.0-dev60
« on: January 04, 2018, 10:29:28 AM »
I was able to reproduce and analyze the segfault. It seems to be due to a bug (or a limitation?) in the OSPRay code. I filed a bug report to the OSPRay developers:

I will try to develop a workaround in the OVITO code for the bug.

Support Forum / Re: cannot construct mech in dislocation analysis
« on: December 27, 2017, 07:13:01 PM »
One possible explanation for this error could also be that the (periodic) simulation cell you are analysing is too small. The DXA may not be able to handle such datasets with a very short periodic length. In this case a possible workaround would be to use the "Show periodic images" modifier to replicate the crystal and increase the simulation cell size by some factor prior to applying the DXA modifier.

Support Forum / Re: cannot construct mech in dislocation analysis
« on: December 27, 2017, 07:09:47 PM »
Dear Ann,

This is an unexpected failure of the DXA routine, which should never occur under normal circumstances. If it does occur, it probably means that the DXA routine needs to be improved in some way to correctly handle your dataset.

To this end, I am asking you to upload the input dataset (at least those simulation frame(s) for which the error occurs) or send the data file(s) directly to me. I will then try to reproduce the problem and find a fix. Please do not forget to also specify the DXA modifier settings that you used, as they may affect the occurrence of the error.

As a possible workaround, I suggest you slightly perturb the atomic positions of the input dataset. For example, you could use the Affine Transformation modifier to shift all positions by some amount before applying the DXA modifier. Maybe this helps to avoid the error, but I am not certain.


Support Forum / Re: What is the function of Ovito.conf at ~/.config/Ovito?
« on: December 25, 2017, 03:17:18 PM »
Yes, this is the configuration file written by OVITO to store the user settings. You will note that the application settings dialog of OVITO shows the path to this config file at the bottom.

The config file stores -among other things- the default parameters of built-in modifiers if they have been modified by the user, the list of custom modifier presets, the application settings, default particle types names and colors, and the file path history.


Support Forum / Re: Segmentation fault -- (Linux) OVITO 3.0.0-dev60
« on: December 21, 2017, 02:57:27 PM »
Thank you for reporting this problem. When I wrote the OSPRay rendering module for OVITO, I had tested it only with 90M atoms.
I created a record in our issue tracker and will do some testing myself as soon as possible:

Support Forum / Re: How can I scale the size of particle?
« on: December 18, 2017, 01:28:47 PM »
I see, so your LAMMPS dump file contains particle radius information. If this is the case, then OVITO probably maps the per-particle radius values to the internal "Radius" particle property. In this case changing the per-type radius or the default display radius has no effect, because the per-particle radii are given the highest priority (see my first post above).

That means you have two options:

  • Turn off the mapping of the radius column from the dump file to OVITO's "Radius" particle property. This can be done by selecting the "Edit column mapping" button in the file source panel.
  • Alternatively, you can overwrite the values in the "Radius" particle property. First select the particles for which you want to change the radius using the Select Particle Type modifier. Then apply the Compute Property modifier to assign a new value to the Radius property. Make sure you activate the Compute only for selected particles option here.

Support Forum / Re: Why my results is the same in every file
« on: December 18, 2017, 09:13:14 AM »

This command from your script loads just the first frame from the given LAMMPS dump file:
Code: [Select]
node = import_file("G:\ovito\plugins\python\ovito\io\")
So the script will process only a single simulation frame.

If your dump file contains a sequence of frames, then you need to use the multiple_frames option with the import_file() function:
Code: [Select]
node = import_file("G:\ovito\plugins\python\ovito\io\", multiple_frames = True)
print("Number of loaded frames: ", node.source.num_frames)

If you have multiple dump files instead, one for each frame, the you need to use a filename pattern instead:
Code: [Select]
node = import_file("G:\ovito\plugins\python\ovito\io\*")
print("Number of loaded frames: ", node.source.num_frames)


Support Forum / Re: Applying modifier in script
« on: December 14, 2017, 10:47:25 PM »
There are severals ways to solve this. The choice depends on what your ultimate goal is: Do you want to use the computation function from the graphical user interface, from batch processing scripts in the terminal, or both?

On the graphical side, note that OVITO allows you to save multiple modifiers as one preset or "super modifier" (see this page in the manual). Thus, you could let your user-defined modifier function still rely on the bonds created by a standard Create Bonds modifier. If you create a preset for this combination of modifiers, you can insert it from the modifier list with a single click. 

For a pure batch script that is callable from the terminal and executed with the ovitos interpreter, you can also still rely on the standard CreateBondsModifier. Just make sure your batch script inserts it into the pipeline before the PythonScriptModifier. It would roughly look like this:
Code: [Select]
node = import_file("....")

def calc_bisectors(frame, input, output):
    .... # access bonds from the input, store bisectors in the output.

node.modifiers.append(PythonScriptModifier(function = calc_bisectors))
data = node.compute()
... # Process the output data, export to a file, etc.

Finally, the third option is to get rid of the Create Bonds modifier and do the bond vector calculation dynamically in your user-defined function. For this purpose, OVITO provides the CutoffNeighborFinder facility.

Support Forum / Re: Applying modifier in script
« on: December 14, 2017, 05:24:14 PM »
Hi Maurice,

Modifier functions must never ever make changes to the data pipeline they are part of. Keep in mind that the modifier is potentially called many times by the system, every time the data pipeline needs to be evaluated. If the modifier function would change the pipeline in some way, e.g. by inserting an additional modifier, this change would automatically trigger a re-evaluation of the pipeline leading to an infinite update loop.

For this reason modifier functions must be pure functions without side effects. They may only access and modify the data that is being passed to them via the two input/output parameters. Note the distinction that is being made between the different objects: the data pipeline, the modifiers forming the pipeline, and the data that flows through the pipeline from modifier function to modifier function.

Please let me know what your intention is here and I will try to find the right solution. What is your modifier function supposed to do? Obviously you want to create bonds. But for that alone the standard CreateBondsModifier would be sufficient and you wouldn't have to write a user-defined modifier function.


Current versions of OVITO require you to "abuse" one of the standard properties for this, because user-defined particle properties are created without an attached display object. Standard properties that are created with an attached VectorDisplay object are the "Force", "Displacement" and "Dipole Orientation" properties.

That being said, have you already tried creating and assigning a new instance of the VectorDisplay class to the display attribute of the property data object? Perhaps this allows you to activate the visualisation of arrows even for your user-defined property.
For instance, In you modify() function, which creates the "Bisector" property:

Code: [Select]
bisectors.display = VectorDisplay()
bisectors.display.enabled = True

Hi Maurice,

This type of property access


doesn't work for user-defined particle properties, only for standard properties such as "position". In the new OVITO version 3.0 it has been marked as deprecated, even for standard properties (see this page). Instead, use standard Python indexing. That means, use a key string to look up the particle property in the dictionary, i.e.



Pages: [1] 2 3 ... 16