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 ... 31
I loaded your file in OVITO 2.9.0 and OVITO 3.0.0-dev, without any problems. Which version of the program are you using?


Support Forum / Re: can ovito movie rendering be paralleled?
« on: September 23, 2018, 07:41:30 PM »
Dear Kyu,

Several computational analysis algorithms are parallelized in OVITO, for example CNA, Compute Property, Wigner-Seitz analysis, and more. They will already make use of all processor cores. Also the Tachyon renderer is multithreaded and will use all cores during image rendering. So there is no point in parallelizing the rendering of a movie across frames.

However, what you can do, if you really want to squeeze out the last bit of performance, is to restrict Ovito (or ovitos) to a single processor core using the --nthreads command line option and run multiple Ovito instances in parallel, letting each instance render a different subset of the animation frames. Finally, you have to manually create a video from the saved animation frames using an external video encoding tool of your choice.

Support Forum / Re: dislocation analysis
« on: September 20, 2018, 11:52:10 AM »
I see. So you actually would like to identify dislocations in a hexagonal lattice.

The DXA function in OVITO does not support any 2D crystals, i.e. sheet-like materials like graphene and your hexagonal lattice. The algorithm was only implemented for three-dimensional crystals such as fcc and bcc, where dislocations are 1-dimensional (line-like) defects.

Identifying dislocation in 2d crystals requires a different method, but happens to be much easier, because here dislocations are 0-dimenesional defects. Here is a paper describing a simple algorithm for finding dislocations in 2d lattices:

I cannot give you a ready-to-use code for this, but it should be relatively easy to implement this algorithm in a Python script. Maybe this is something you can do yourself.

Support Forum / Re: dislocation analysis
« on: September 20, 2018, 10:43:35 AM »
Dear Bahman,

I'm not sure if I understand: What exactly is a "2D fcc model"? Face-centered cubic crystal lattices are by definition three-dimensional.


Support Forum / Re: Save the distance between two particles
« on: September 19, 2018, 09:42:38 PM »

Note that in your Python script you are subtracting two particle identifiers instead of two particle positions:

Code: [Select]
distance = np.linalg.norm( input.particles["Particle Identifier"][655] - input.particles["Particle Identifier"][679] )

The expression "input.particles["Particle Identifier"][655]" gives you the numeric ID of the 655th particle in the particles list. Obviously, it doesn't make sense to subtract two IDs. What you want, is the difference between two particle positions. XYZ coordinates are stored in the "Position" particle property:

Code: [Select]
distance = np.linalg.norm( input.particles["Position"][655] - input.particles["Position"][679] )

But note that this will subtract the position of the 679th particle from the 655th particle. But these are probably not the ones you are interested in. There is a difference between particle identifiers and particle indices. The ID is an explicit property of each particle, which sticks to a particle even if the storage order of particles changes or when you delete some particles. The particle index, on the other hand, is an implicit property since the index only specifies the position of the particle within the current list of particles. If you delete some particles using the Slice modifier or the Delete Selected modifier in OVITO, the indices of the remaining particles typically change, because the indices always form a consecutive sequence from 0 to N-1, where N is the current number of particles.

You can find the particle IDs in the "Particle Identifier" column of the particle data inspector (see your screenshot). Particle indices are shown in the left most column of the table.

(As a side note: The simulation code LAMMPS assigns unique IDs to atoms ranging from 1 to N. But during a simulation run, it tends to reorder particles and when they are written to a dump snapshot, the current ordering is typically random (you can change that behavior using the dump_modify sort command). That's why there is generally no well-defined relationship between the ID of a particle and its index, i.e. its position in the list of particles loaded from the dump file).

You want to compute the distance between the two particles with IDs 655 and 679. However, in Python you can access particles only by index! That means you first have to determine the indices of the two particles before you can access their position vectors. You do it as follows:

Code: [Select]
index1 = np.nonzero(input.particles["Particle Identifier"] == 655)[0][0]
index2 = np.nonzero(input.particles["Particle Identifier"] == 679)[0][0]
distance = np.linalg.norm( input.particles["Position"][index1] - input.particles["Position"][index2] )

Note that the np.nozero() function is the typical Numpy way of finding the first occurrence of a particular value (in this case the ID) in an array. In other words, it searched for the value 655 in the ID array and gives back the 0-based index. This index can then be used to access the corresponding value in the coordinates array.

Support Forum / Re: which gcc is used to compile ovito?
« on: September 17, 2018, 10:59:59 AM »
I think the file you uploaded in the previous comment is included in "lib/ovito/lib" directory.
Yes, thanks for noticing, I almost forgot. The file is indeed included in a subdirectory. For some reason, however, it is not found during the startup process.

There are two more things you could do:

1. Run "LD_DEBUG=libs bin/ovitos". The LD_DEBUG environment setting will produce a lot of output, telling what libraries are being searched and in which locations. It would be helpful if you could pipe the produced terminal output to a file and upload it here.

2. Maybe it helps, at least as a workaround, to preload the sheared library using the LD_PRELOAD option when running ovitos:

LD_PRELOAD=/opt/ovito/ovito-2.9.0-x86_64/lib/ovito/lib/ bin/ovitos

Support Forum / Re: which gcc is used to compile ovito?
« on: September 17, 2018, 09:46:51 AM »
The log output says

Code: [Select]
... (required by /software/centos7/lib64/

This suggests that the library gets loaded during the startup process for some reason. This library module is not included in the standard OVITO installation packages, because I thought it isn't needed by OVITO. But for some reason it is in your case.

Since the module is not included with OVITO, the system version gets loaded, which is not compatible with the other modules from OVITO. That's at least my assumption.

I have attached the matching version of the Qt module from my development machine. Please put it to the others in the OVITO lib directory and see if it gets loaded correctly.

Support Forum / Re: which gcc is used to compile ovito?
« on: September 17, 2018, 08:43:25 AM »
Note that when you run "ldd" from the terminal, the "ldd" command will only look in the system directories for the needed libraries. For example, in your case it finds the libQt*.so libraries installed in "/software/centos7/lib64/" instead of the ones that ship with OVITO, which are located in the "ovito-3.0.0-dev234-x86_64/lib/ovito/" directory. You need to make ldd look in the latter directory by settings the LD_LIBRARY_PATH variable. For example, on my Ubuntu Linux system:

Code: [Select]
stuko@mogli9:~/progs/ovito-3.0.0-dev234-x86_64/lib/ovito/plugins_qt/platforms$ LD_LIBRARY_PATH=../.. ldd =>  (0x00007ffd2216f000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbecd43d000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbecd1fa000) => /nfshome/stuko/progs/ovito-3.0.0-dev234-x86_64/lib/ovito/plugins_qt/platforms/../../ (0x00007fbeccbfa000) => /nfshome/stuko/progs/ovito-3.0.0-dev234-x86_64/lib/ovito/plugins_qt/platforms/../../ (0x00007fbecc626000)

Note that I have added "LD_LIBRARY_PATH=$PWD/../..[/I]" above to let ldd search in the parent directory for .so files. Without that, ldd finds the wrong Qt library versions in the system directory and I get error messages:

Code: [Select]
stuko@mogli9:~/progs/ovito-3.0.0-dev234-x86_64/lib/ovito/plugins_qt/platforms$ ldd
./ /usr/lib/x86_64-linux-gnu/ version `Qt_5.10' not found (required by ./
./ /usr/lib/x86_64-linux-gnu/ version `Qt_5' not found (required by ./
./ /usr/lib/x86_64-linux-gnu/ version `Qt_5_PRIVATE_API' not found (required by ./
./ /usr/lib/x86_64-linux-gnu/ version `Qt_5_PRIVATE_API' not found (required by ./
./ /usr/lib/x86_64-linux-gnu/ version `Qt_5' not found (required by ./ =>  (0x00007fffb198d000) => /usr/lib/x86_64-linux-gnu/ (0x00007fe980c29000) => /usr/lib/x86_64-linux-gnu/ (0x00007fe9809e6000) => /usr/lib/x86_64-linux-gnu/ (0x00007fe98049e000) => /usr/lib/x86_64-linux-gnu/ (0x00007fe97ffc8000)

In your case, the same applies to the library that you copied to the OVITO lib directory. ldd simply doesn't see it and falls back to the system version of libstdc++. That's why you get the error message "./ /software/centos7/lib64/ version `CXXABI_1.3.9' not found (required by ./".

The above only matters when running the ldd command. When running ovitos, the program should automatically make sure that libraries are first searched in the OVITO lib directory. libstdc++ and the libQt5*.so libraries should get loaded on startup. Later, when the platform plugins such as get loaded, the library search path should not matter anymore, because libstdc++ and the libQt5*.so libraries already reside in memory.

The platform plugin is only used when running ovitos in headless mode without an X server, for example when logged into a remote machine via SSH without active X forwarding. The platform plugin will be used instead when running on a local machine with an X display, or when logged in to a remote machine with active X forwarding ("ssh -X").

Qt provides a debugging option, which can provide some additional log output:

Please try running "QT_DEBUG_PLUGINS=1 bin/ovitos" to see if that produces any additional information that can help us understand what is going wrong.

Support Forum / Re: which gcc is used to compile ovito?
« on: September 16, 2018, 11:09:57 AM »
Dear Kyu,

please note following statement on the OVITO download page:

Note to users of RHEL and similar Linux distributions:

In case program startup fails with the error message "ovito: /usr/lib64/ version `CXXABI_1.3.8' not found", please download this version of and copy the two .so files in the lib/ovito/ subdirectory of the OVITO installation. They are required, because the existing version of libstdc++ on your system is not compatible with the OVITO binary.

On your Linux system it may be necessary to install the mentioned libraries to run ovito/ovitos.

I build the official binaries for Linux using gcc 5.1.1 under Ubuntu Linux 10.04.


Support Forum / Re: Steinhardt order parameters
« on: September 15, 2018, 10:44:01 AM »
This is not related to OVITO, but here is a simple C++ code I wrote more than 6 years ago for a review paper which can calculate the Steinhardt parameters (at least some of them):

Support Forum / Re: Steinhardt order parameters
« on: September 15, 2018, 10:39:00 AM »
No, Steinhardt parameter calculation is currently not a built-in function of OVITO.

If you are interested in doing this calculation with OVITO, it would be possible to write a user-defined modifier function in Python that implements the calculation of the Steinhardt parameters. The scripting documentation contains a code example demonstrating the calculation of a local order parameter from the neighbor vectors of an atom, which can serve as a good starting point:

Ovito 3.0-dev:

Ovito 2.9.0:

Support Forum / Re: CNA and bond-angle analysis criterion
« on: September 15, 2018, 08:53:28 AM »
The CNA is essentially based on a per-bond classification. In proceeds in three steps:

1. Generate the network of neighbor bonds, for example using a distance-based cutoff criterion.
2. Compute a triplet of integers for each bond in the network, which represents a fingerprint of the local topology of the network surrounding the bond.
3. Classify each atom based on the types of the bonds it has.

For example, those atoms which have exactly 12 bonds of type "4-2-1" are taken as FCC in the standard CNA method.

What you could do in OVITO is the following: The CNA modifier has a "bond-based mode". When activated, the modifier will skip step 1 above and instead use the existing explicit bond network. For instance, you could create the bonds explicitly by adding the Create Bonds modifier of OVITO before the CNA modifier. Furthermore, the CNA modifier will output the computed triplets for each bond as a new bond property. This gives you the opportunity to perform step 3 in the algorithm above yourself and implement different classification schemes. For this step, you'll have to write a user-defined modifier function in Python which gets executed after the CNA modifier.

I'm not sure how well it will work and what would be a good "relaxed" criterion for FCC atoms. For example, you could require them to have at least eight 4-2-1 bonds instead of exactly 12. It's probably a good idea to first manually inspect the CNA fingerprints computed for the bonds of atoms at the surface for which you think they should be classified as FCC and then derive appropriate criteria from that observation.

Support Forum / Re: Dislocation Analysis- tetragonal
« on: September 13, 2018, 07:41:03 PM »
Dear Bahman,

Currently, the rutile structure is not directly supported by the dislocation analysis function in OVITO. The main reason for it being that we don't have a good crystal structure structure identification method yet for this lattice type. For the dislocation identification to work, the perfect crystal material surrounding the dislocation cores must be properly identified by means of some algorithm.

What you can try though -if the crystal has a well-defined orientation- is to stretch the crystal along the c-axis to obtain a unit cell that is roughly cubic (you can use the Affine Transformation modifier of OVITO for that). Then select the Ti-atoms and apply the DXA dislocation analysis just to the selected atoms, which will look like a bcc lattice.


Support Forum / Re: Python Script Loop
« on: September 12, 2018, 09:57:41 AM »

Here is how it is typically done: Put the existing call to export_file() into a Python for-loop and repeatedly use FileSource.load() to replace the input of the data pipeline with a new file:

Code: [Select]
import os

# ... do the pipeline setup here

for filename in files_to_process:

    # Set a new input file for the current data pipeline:
    node.source.load(filename, multiple_frames = True)

    # Derive the name of the output txt file from the input dump file:
    output_filename = os.path.splitext(filename)[0] + ".txt"

    # Let OVITO do the processing:
    export_file(node, output_filename, "txt",
        columns = ['Timestep', 'Ca_Vac'],
        multiple_frames = True)

The list files_to_process should contain the names of the dump files you want to process.


They are the 4 components of the quaternion used to express the local lattice orientation computed by the PTM modifier for each identified crystal atom. Please see the Wikipedia if you are not familiar with quaternions and how they can be used to express orientations:

The PTM paper mentions a "right-handed orthogonal matrix Q" being computed for each atom, which is basically a 3x3 rotation matrix. In OVITO, this orientation information is translated into the more compact quaternion representation and stored in the "Orientation" output particle property.


Pages: [1] 2 3 ... 31