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] 4 5 ... 28
Support Forum / Re: calculate average displacement vector in bins
« on: June 03, 2018, 10:37:49 AM »

For referring to a particle property, for example when setting the input of the Bin and Reduce modifier, the scripting interface provides two ways. The first is to make use of the predefined enum constants, e.g.
Code: [Select]
The second method is to refer to a property by name using a Python string:
Code: [Select]
A table with enum constants for all the standard properties and the corresponding property names is found here. However, as you noted, the enum constants do not allow you to select individual components of a vector property. That means you can use this notation only in places where a reference to a particle property as a whole is needed. The string-based notation, in contrast, lets you select individual vector components, e.g.
Code: [Select]
So in the present case this would be the way to go.


Support Forum / Re: Rendering Images with Python Script
« on: May 30, 2018, 03:28:46 PM »
Yes, the precise approach depends on whether you want to render a series of images or a single movie file (e.g. AVI or MP4).

In both cases you need to attach a TextLabelOverlay to the viewport you are rendering. Everything is easy if you are rendering individual images in a normal Python loop. Then you can simply assign a new text string to the label before rendering the next frame.
If you are rendering a movie sequence (i.e. no Python for-loop), then you have to work with a placeholder in the label's text string, which refers to a global attribute that is dynamically computed. Computing that attribute is your responsibility and can be done by means of a user-defined modifier function and a PythonScriptModifier that you insert into the data pipeline. This function should read in the text file with the time stamps and emit a global attribute with a value that depends on the frame being currently evaluated by the data pipeline system. 

Support Forum / Re: DXA Analysis in MgO
« on: May 25, 2018, 04:44:06 PM »

MgO has a rocksalt structure if I'm not mistaken. No, this type of lattice structure (like any other simple cubic structure) is currently no support by the DXA implementation in OVITO. In a compound like MgO, the preferred workaround, as you mentioned already, is to perform the analysis on a sub-lattice formed by one atomic species.

For that, you don't have to actually delete the atoms belonging to other sub-lattices. It's enough to first select the atoms from one sub-lattice, and then activate the "Use only selected particles" option of the DXA modifier, which has been introduced in the most recent version of OVITO.


Support Forum / Re: Creating histograms of bond lengths
« on: May 25, 2018, 04:37:02 PM »
Dear Aldo,

I think you forgot to add the Compute bond lengths modifier. At least you didn't mention it in your description.

This modifier needs to be inserted after the Create Bonds modifier, and before the Histogram modifier. The Create Bonds modifier only creates bonds but doesn't compute their lengths.


Support Forum / Re: Can the ovitos.exe use the parallel computing?
« on: May 25, 2018, 04:34:26 PM »
Dear Shaui,

OVITO and ovitos both automatically use all available processor cores for certain operations. However, this only applies to a subset of the analysis modifiers and to the rendering of images using the software-based engines. For the other modifiers and file I/O, parallelisation is not implemented, either because it would bring no benefit or because it would be too complicated to develop an efficient parallel algorithm.



Please excuse my late reply.

Filtering of atoms is typically done in OVITO by first selecting the atoms which are not of interest and then delete those atoms, leaving only the atoms of interest. This type of approach is preferred over setting the transparency of atoms to 100%. Note that thanks to OVITO's data pipeline system, the deletion of atoms is never permanent. A copy of the original input atoms is still kept around by the program, giving you the possibility to restore the deleted atoms at any point or dynamically update the set of atoms to be deleted.

So the typical sequence used for your case is:

1. Apply the Common Neighbour Analysis modifier to classify atoms
2. Apply the Select Particle Type modifier to select those type(s) of atoms you want to hide
3. Apply the Delete Selected Particles modifier to remove them

These three actions will be performed dynamically by the program as you stop through the sequence of simulation frames.


Extending the Bin and Reduce modifier to also support 3d grids is on my wish-list, yes. I am currently working the data model design that will lay the ground work for this.

No, OVITO currently doesn't have a built-in function for exporting the graphical representation of the 2d data grid computed and visualized by the Bin and Reduce modifier. But with some scripting and the matplotlib module of Python one can do it, of course. Python scripts can access the data produced by the Bin and Reduce modifier.

Support Forum / Re: Rendering Images with Python Script
« on: May 18, 2018, 10:12:43 PM »
Yeah, my mistake, here in this line:
Code: [Select]
pipeline.modifiers.append(AssignColorModifier(color=(0.3, 0.3, 1.0))

The third closing ')' is missing at the end to match the three opening '('.

Support Forum / Re: Rendering Images with Python Script
« on: May 18, 2018, 05:22:07 PM »
Can you please post the entire file as an attachment. From the error message I cannot tell where this is coming from.

Support Forum / Re: Rendering Images with Python Script
« on: May 18, 2018, 12:15:06 PM »
Giving vacancy sites a certain color depending on the type of atom that originally occupied that site in the perfect crystal is straightforward. Simply use a ExpressionSelectionModifier followed by an AssignColorModifier:

Code: [Select]
pipeline.modifiers.append(ExpressionSelectionModifier(expression = 'Occupancy==1 && ParticleType==1'))
pipeline.modifiers.append(AssignColorModifier(color=(0.3, 0.3, 1.0))
pipeline.modifiers.append(ExpressionSelectionModifier(expression = 'Occupancy==1 && ParticleType==2'))
pipeline.modifiers.append(AssignColorModifier(color=(0.2, 0.6, 1.0))

(Note that this code is for OVITO 3.0-dev. The SelectExpressionModifier class from OVITO 2.9 has been renamed to ExpressionSelectionModifier.)

Coloring interstitial atoms depending on their chemical type is less straightforward, but can probably done and will probably require turning on the per_type_occupancies option. I guess you want interstitials to be coloured according to their own chemical type, not the chemical type of the site they are sitting on, right? If yes, then one has find a way to determine which of the two (or more) atoms occupying a site is the interstitial and which one is the original atom (if any).

Dear Afshin,

If you understand you correctly, you would like to transfer some atomic property from the unstructured atoms to a three-dimensional structured grid. Is that right? So this function would be similar to the existing Bin and Reduce function, but using a three-dimensional grid of bins instead of two-dimensional.

Dear SG,

The RDF is a statistical distribution and not something that can be calculated for individual atoms. So please clarify how you mean that. For a given BCC atom, would you like to compute the distances to all its neighbours within a certain cutoff range?


Support Forum / Re: Rendering Images with Python Script
« on: May 12, 2018, 02:07:30 PM »
I now ran your script myself with OVITO 2.9.0, and I can confirm that are indeed some issues. I was able to find a workaround for the zooming issue, but the viewport overlay function, which is needed to render the scale bar, seems to be broken in that program version. It might be that it cannot be used from a batch script at all, only within the GUI.

In this situation I suggest you switch to the current development build of OVITO 3.0.0 instead. The old 2.9 release is already one year old and issues like the one encountered here have been fixed since then. The Python programming interface has been further simplified, but that also means you will need to adjust the code accordingly. I have done that for you already. Below you find the updated script code, which should work correctly with OVITO 3.0.0-dev198 according to my tests:

Code: [Select]
from import *
from ovito.vis import *
from math import *
from PyQt5.QtCore import *
from PyQt5.QtGui import *

pipeline = import_file("../../")

# Turn off cell display:
pipeline.get_vis(SimulationCellVis).enabled = False

bar_length = 100 # Simulation units (e.g. Angstroms)
bar_color = QColor(0,0,0)
label_text = "{} nm".format(bar_length/10)
label_color = QColor(255,255,255)

# Define the overlay function, which renders the scale bar:
def render_overlay(args):
    # Compute length of bar in screen space
    screen_length = args.project_size((0,0,0), bar_length)

    # Define geometry of bar in screen space
    height = 0.07 * args.painter.window().height()
    margin = 0.02 * args.painter.window().height()
    rect = QRectF(margin, margin, screen_length, height)

    # Render bar
    args.painter.fillRect(rect, bar_color)

    # Render text label
    font = args.painter.font()
    args.painter.drawText(rect, Qt.AlignCenter, label_text)

# Create a viewport and install overlay function:
vp = Viewport()
# This selects a parallel projection with viewing direction along -Z axis:
vp.type = Viewport.Type.TOP
# Adjust camera pos and FOV automatically:
# Alternatively, set parameters explicitly:
#vp.camera_pos = (251.497,251.551,550.188)

# Set up renderer
renderer = TachyonRenderer()

# Now render the frames, one by one:
for frame in range(pipeline.source.num_frames):
    print("Rendering frame", frame)
    vp.render_image(frame=frame, size=(1920,1440), filename="t"+str(frame)+".png", renderer=renderer)


Thanks for clarifying what you meant, and I'm sorry that I didn't realise at first that you are using the "Color lines by Burgers vector" mode and not the "Color line by dislocation type" mode.

The answer remains more or less the same though. I didn't have time yet to implement a customization option for the user and the set of line colors is currently hardcoded in the source code of OVITO and cannot be changed by the user. Here are the corresponding lines in the source code:

There are seven colors in total: four 1/2<111> and three <100> Burgers vectors for the BCC crystal lattice.

For the time being you would have to modify the source code and recompile OVITO if you want to customise these predefined colors.

Support Forum / Re: Rendering Images with Python Script
« on: May 11, 2018, 09:25:02 PM »
Dear Ben,

1) I am not really sure how this issue arises. What I noticed in your script is that you never set the field of view of the camera explicitly (i.e. the Viewport.fov parameter). You only set the camera position and the direction. My suggestion is that you either set the FOV value, i.e. the size of the visible render region, explicitly, or call the Viewport.zoom_all() to let OVITO choose the FOV value automatically in order to fully show the entire dataset.

2) Another mistake I noticed is that you add the user-defined viewport overlay function inside the for-loop that renders the series of frames. That means you keep adding multiple overlays to the viewport's list of overlays, one more with each frame. This certainly isn't what you want. You should rather add an overlay just once before entering the for-loop, i.e. in the following order:
Code: [Select]
# Install the user-defined viewport overlay, which will render the scale bar:
def render_overlay(painter, **args):
overlay = PythonViewportOverlay(function=render_overlay)

# Now render the frames, one by one:
for frame in range(0,dataset.anim.last_frame+1):
I'm not sure though why the scale bar is not showing. If you didn't modify the original code of the overlay function, which was taken from the OVITO docs, it should work. Perhaps it is related to the first issue above then. Let's see.


Pages: 1 2 [3] 4 5 ... 28