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 ... 19 20 [21]
Support Forum / Re: Graphic card and type of rendering pictures
« on: January 09, 2017, 01:25:08 PM »
1. Yes, I would think that the integrated Intel graphics should be sufficient to work with a one-million atoms dataset. The graphics hardware is only used for displaying the atoms. It's not used by Ovito to accelerate other computations.

2. I am not aware of any technique or freely available programming framework that would allow to render the three-dimensional scene including atoms and bonds to a 2d vector graphics format, at least not with the visual quality we get from pixel-based renderers. If you know one, please tell. However, I'm not sure how much benefit this would bring anyway. For the following reason: Ovito is designed for large datasets with millions of atoms. The key advantage of bitmap-based output is that the resulting file size is independent of the number of visual elements in the three-dimensional scene (i.e. atoms, bonds, etc.). Furthermore, unlike with lines and flat surfaces, vector graphics formats often have difficulties to properly describe shaded spheres.

Support Forum / Re: Adaptive CNA for 2D binary systems
« on: January 08, 2017, 11:29:29 AM »
The adaptive mode of the CNA is currently only implemented for certain three-dimensional crystal structures like FCC and BCC. In principle, it would be possible to extend this approach to two-dimensional structures, but that would require modifying the C++ code of the CNA modifier. The point is that the adaptive mode, which is responsible for picking the optimal neighbor cutoff for each atom, always requires some a priori knowledge on the specific structure to search for. It is not a general method that is independent of the structure you are trying to identify.

But maybe it is possible to stick to the conventional bond-based CNA mode and instead change the way bonds are created. This could improve the identification of the crystalline 2D structure your are looking for in a similar manner as the adaptive CNA mode.

For example, writing a custom PythonScriptModifier, which can be used in place of a CreateBondsModifier, might be an idea. Instead of creating bonds up to a certain cutoff radius, the custom modifier could create exactly N bonds on each atom using the NearestNeighborFinder class.

Support Forum / Re: Global parameters defination
« on: January 07, 2017, 07:35:28 PM »
Dear Leal,

Yes, it is possible to define global values that are accessible by modifiers in the data pipeline and which can be referenced in expressions of the SelectExpressionModifier. They can be defined by adding entries to the attributes dictionary of the node.source object.

However, this doesn't seem to be the right strategy for the problem at hand, because the global attributes are static across the entire pipeline. If I understand you correctly, you want to create several SelectExpressionModifiers, each with different values for L and M. In this case I suggest you simply replace the variables L and M in the selection expression with their numeric values, i.e.

Code: [Select]
for i in ...
    L  = i*5
    M  = (i+1)*5
    Select=SelectExpressionModifier(expression='Position.Y*Position.Y+Position.Z*Position.Z>{L}*{L} && Position.Y*Position.Y+Position.Z*Position.Z<{M}*{M}'.format(L=L, M=M))

Another alternative is to use a PythonScriptModifier instead of a SelectExpressionModifier. Unlike the latter, the user-defined Python modifier function has direct access to variables defined in the Python script.

Let me know if you have further questions. The best solution to this scripting problem probably depends on what exactly you want to do with these ring-shaped particle selections.

Hi Leal,

I'm not sure if I can tell you much more than what is already said in the documentation.

Your code is sufficient to set up the modifier. Next you need to call node.compute(). Subsequently, you can access the computed data through the modifier's bin_data property. In this specific case, it refers to a one-dimensional array with 100 entries, holding the mean coordination number of particles within the 100 slices along the x-axis of the simulation cell.

Code: [Select]

mean_coordination = modifier.bin_data
assert(len(mean_coordination) == modifier.bin_count_x)

Let me know if you need further help with this.

Support Forum / Re: Graphic card and type of rendering pictures
« on: January 03, 2017, 11:24:12 AM »
1. OVITO requires graphics hardware that supports version 2.1 or later of the OpenGL standard. Virtually all graphics cards and integrated graphics units that you can buy today do this. The rendering quality does not depend on the hardware's capabilities, only the interactive performance does. If you work a lot with datasets containing tens of millions of atoms, a dedicated graphics chip or card are recommended.

2. Note that OVITO can only produce bitmap images. But if your question is whether it is possible to include user-defined vector graphics in the images rendered by OVITO, then I suggest you take a look at the Python script viewport overlay. This feature allows you to paint graphics on top of rendered images, and it might even be possible to load an external SVG vector graphics file and overlay it on the output image.

Support Forum / Re: colour atoms by index
« on: December 28, 2016, 05:00:37 PM »

One way to do this is to first select a group of particles based on their indices and then use the Assign Color modifier to assign a color of your choice to the selected particles. To select the particles, first use the Expression Select modifier with an expression like this:

     ParticleIndex>100 && ParticleIndex<=200

These steps can be repeated to assign colors to more ranges of particles.

Loading a VTK file works the same way as loading a simulation data file (Select "Load File" from the menu). Pick "Add to scene" when being asked how to import the data from the VTK file into Ovito. This will create a second object in the three-dimensional scene in addition to the simulation dataset that is already loaded.

I see, you want to run the script from within Ovito. This requires a different approach, because Ovito has already called QApplication::exec() and the script is executed within the running event loop. However, Qt allows you to start a local event loop. The loop can be stopped again by some signal (in this case: the window being closed by the user). Here is a demo script:

Code: [Select]
from PyQt5.QtCore import *
from PyQt5.QtWidgets import *
import sys
if __name__ == '__main__':
    app = QApplication.instance()
    window1 = QWidget()
    window1.setWindowTitle("Hello World!")

    event_loop = QEventLoop()
    window1.setAttribute(Qt.WA_DeleteOnClose)      # Make sure window is destroyed when user closes it.
    window1.destroyed.connect(event_loop.quit)     # Quit local event loop when window is destroyed.
    QTimer.singleShot(100, lambda: window1.activateWindow())     # Wait for a short time, then bring window in front of all other windows.
    event_loop.exec()     # Start local event loop.

One problem I noticed with this approach: If you abort the script execution by pressing "Cancel" instead of closing the window, the local event loop is never orderly terminated. This seems to cause a program crash when Ovito is quit.

Hmm, the minimal code example that you posted works for me when I run it with the ovitos interpreter (Ovito version 2.8.1, Linux). It shows a window, and the script waits until I manually close the window. Please let me know if you are trying this on a platform other than Linux. Maybe it is a platform-specific issue.

Here is also a link to the corresponding page of the user manual, which describes the viewport overlay feature:

Regarding the second question:

In the current program version, the plane of the Slice modifier will only be visible in the interactive viewports, not in rendered images. The only way to add arbitrary geometry to the three-dimensional scene (e.g. a plane) is to import a VTK file into Ovito that contains a triangle mesh. I have attached an example VTK file containing a tetrahedron made of four triangular faces. The file format is documented here.

Unfortunately, this approach requires that you write the VTK file by hand or use some other tool like ParaView to prepare it. There is no way to generate the plane geometry within Ovito (but you can use the Move tool found in the toolbar to reposition the imported geometry).


Note that Ovito already creates its own QApplication object. The same is true for the ovitos script interpreter. The internal QApplication object exists while the script is being executed.

It is therefore not a good idea to create a second QApplication from the script (Qt only allows a single QApplication instance). The segmentation fault results from Ovito trying to delete its QApplication object after script execution. However, this object has already been auto-deleted by Qt, because the script created a second QApplication object.

The solution to this problem is to not create a second QApplication instance. Instead, simply access the existing one from the script:

Code: [Select]
if __name__ == '__main__':
    app = QApplication.instance()

(Older Ovito versions didn't try to delete the QApplication object upon program exit. Thus, creating a second QApplication object from the script, even though wrong, didn't result in a segfault.)

Support Forum / Re: LAMMPS sphere data format
« on: December 14, 2016, 04:20:05 PM »
I added the option to load and write LAMMPS data files with atom_style=sphere for you (Commit 5e4ba252).

The particle diameters read from the data file are automatically mapped to the "Radius" particle property in OVITO (after dividing by 2) and the density values are mapped to the "Mass" particle property (after multiplying with the particle volume).

Particles with radius=0 in the data file will be rendered using the default radius, which can be set in the particle display panel of OVITO.
Please download the latest development build from the website.

Support Forum / Re: Writing LAMMPS data file
« on: December 08, 2016, 08:24:09 PM »
No, I'm sorry, but OVITO's internal data model doesn't support "bond angles" (and other non-visual information used by the LAMMPS code). There is no way for OVITO to produce a LAMMPS data file like that.

Reading such files with OVITO should be possible though, and bonds and bond types are supported by the data model.

Let's suppose you would like to determine the global maximum of a particle property for every frame of a simulation and export this information to a text file. This can be done by inserting a Python Script modifier into the data pipeline. The following modifier script computes the maximum of the Potential Energy particle property and injects the value as a new global attribute into the data pipeline:

Code: [Select]
def modify(frame, input, output):
    max_energy = input.particle_properties['Potential Energy'].array.max()
    output.attributes['Maximum Energy'] = float(max_energy)

You can now use OVITO's standard file export function to generate a table of the Maximum Energy attribute and write it to a text file. Select Calculation Results Text File as output file format.

Support Forum / Re: Python Modifier Script
« on: November 26, 2016, 05:07:38 PM »
I leave it to you to work out an actual algorithm to select the molecules. But here is the boilerplate code you need to access the positions, types and molecule IDs of atoms, and to create the output selection property. Set the corresponding entries in the selection array to 1 for atoms that you would like to select.

Code: [Select]
from import *

def modify(frame, input, output):
    position = input.particle_properties.position.array
    type = input.particle_properties.particle_type.array
    molecule_id = input.particle_properties.molecule_identifier.array
    selection = output.create_particle_property(ParticleProperty.Type.Selection).marray

Could you please attach the two simulation files (the reference and the displaced configuration) if they are not too large?

The steps that you describe sound correct. I am wondering whether the simulation cell size did change after you equilibrate the displaced system? In other words, did you use a barostat in LAMMPS to relax the box size? If yes, you probably have to activate the "Eliminate homogeneous cell deformation" option in the WS analysis modifier to account for the expansion/contraction of the lattice.

Another thing makes me suspicious: When you let LAMMPS write a dump file, OVITO should pick up the periodic boundary conditions automatically. No need to activate them explicitly in OVITO. Did you perhaps use some non-standard file format like XYZ, which doesn't store PBC flags and box size information? This would likely lead to artefacts at the box boundaries when performing the WS analysis.

Support Forum / Re: Python Modifier Script
« on: November 23, 2016, 07:57:13 AM »
Unfortunately, the version of Ovito that you are using (I assume it's 2.7.1) contains a bug in the implementation of the "is" comparison operator, which always evaluates to false. That is why the assertion from the example fails even though the original assumption still holds: input and output cell both point to the same internal object.

Please remove the assert() statements and proceed with writing your own modifier, or install the current development release of Ovito, which comes with a completely new implementation of the Python bindings.

Let me know if you need further help with writing the modifier script. The next steps depend on what you would like your modifier to do.

Support Forum / Re: Two bugs with ovito?
« on: November 03, 2016, 04:50:17 PM »
No, I'm sorry. The Voronoi polyhedra are not permanently stored by OVITO after computing their volume and counting their faces. And there is no function for visualizing the polyhedra.

Support Forum / Re: Two bugs with ovito?
« on: November 03, 2016, 09:06:54 AM »
I'm happy seeing the first question being posted on this board.

1) Some MD codes store the atomic positions in reduced coordinates in XYZ files. OVITO tries to detect this case by analyzing the range of the XYZ coordinates. If XYZ coordinates of all atoms fall into the range [-0.01, 1.01], then OVITO assumes they are given in reduced units and will rescale them to absolute coordinates while reading the file. Unfortunately, in your dataset, the absolutes coordinates are all within this range, so OVITO is doing the wrong thing. I will think about how to improve this defection heuristic for reduced XYZ coordinates. But it may be that the only solution is to introduce an explicit user option that suppresses the automatic rescaling of coordinates.

For the time being you can work around the issue by making sure some of the coordinates in your XYZ file are outside the [-0.01,1.01] range. For example, you can shift all Z coordinates by one box length, which is 1.0. Then apply the Wrap at Periodic Boundaries modifier within OVITO to map the atoms back into the box. I have attached a modified version of your file to demonstrate this.

2) First: There is no apparent difference between the two numbers in the error message because not enough decimal places are shown. The difference is <1e-4 but still large enough for OVITO to complain about it. I will make sure that more decimal places are printed in the error message in the future.

Regarding the cause of the message: As a sanity check, OVITO computes the sum of all Voronoi cells and compares it to the volume of the simulation cell. The two numbers should always match unless some atoms are located outside of a (non-periodic) simulation cell. In this case the Voronoi cells computed for atoms not inside the cell are invalid and OVITO warns you about this. However, even if the calculation is correct, due to numeric errors the sum of Voronoi cells might not exactly match the cell volume. So OVITO works with a threshold to tolerate a small deviation. This threshold was chosen too small in OVITO 2.7.1 and previous versions, which could led to false alarms like in your case. In the current development version the threshold has been raised and the error message goes away. So please download the current development version of OVITO from the website.

Only certain particle properties such as Force, Displacement and Dipole Orientation are rendered as arrows by OVITO. To visualize a custom vector property, map it to one of these standard properties.
  • This can either happen directly during import of the data file. Some file readers like the LAMMPS dump and XYZ reader allow you to define a custom mapping of file columns to particle properties. Use the Edit Column Mapping button to assign your vector data to the Force property, for example.
  • Alternatively, use a Compute Property modifier to set the values of the Force property to the values of your vector property.

Pages: 1 ... 19 20 [21]