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 ... 19
1
Support Forum / Re: How can we get a bond angle distribution in ovito?
« on: February 19, 2019, 07:21:42 PM »
The script builds up a histogram of bond angles over the [-1,+1] value range of cos(theta). This histogram is stored in a Numpy array in the variable "angle_cosine_histogram". You can use the numpy.savetxt() function to write the numeric data to a text file in the current directory. For example, add the following line to the end of the script:

Code: [Select]
np.savetxt("distribution.txt", angle_cosine_histogram, delimiter=',')

You can then use your favorite plotting tool (e.g. Microsoft Excel, Gnuplot, etc.) to import this text file and create a graph from the numeric data. There is currently no direct way of exporting the visual plots you can find within the graphical version of Ovito as images.

2
Support Forum / Re: wrong atom type
« on: February 19, 2019, 07:06:41 PM »
Hi,

Yeah, the old Ovito version had problems reading XYZ files with varying sets of elements. This bug has been fixed, and the current development release 3.0.0-dev341 of Ovito handles these files much better. Please upgrade to the new program version.

See also the old bug report: https://gitlab.com/stuko/ovito/issues/137

-Alex

3
Support Forum / Re: How can we get a bond angle distribution in ovito?
« on: February 17, 2019, 06:46:02 PM »
Hi SC,

Constanze went on vacation, so let me answer your question.

Yes, "ovitos" is a command line application for executing Python scripts that do run outside of the graphical Ovito user interface. It is typically used when automating analysis and rendering tasks which do not require user intervention.

On Windows, you can find "ovitos.exe" in the installation directory of Ovito. You should run it from the Windows command line prompt as specified by Constanze in order to see the console output your Python script produces.

-Alex

4
Hi,

I would say switching to the Ovito 3.0-dev release is right choice, because sooner or later you will need to adapt your scripts in any case.

The data structures in Ovito 3 have changed and it wasn't possible to keep the Python interface fully backward-compatible. One of the classes that have been removed completely is ParticleProperty. That's why you get the error message. The Type.XXX constants are still available in the Particles class. Thus, you can now write Particles.Type.Selection. However, the new documentation suggests you better specify the property using its string name, i.e. "Selection". Instead of the old create_particle_property() method, the new interface provides the PropertyContainer.create_property() method:

Code: [Select]
sel = output.particles_.create_property("Selection")

Note the _ (underscore) that has been appended to the particles accessor. It is required to express your intention to modify the Particles property container that this accessor field returns. Without the underscore suffix, the returned object will be locked and any attempt to modify it will result in an error message.

-Alex

5
Support Forum / Re: Data collection error
« on: February 14, 2019, 11:40:04 AM »
Yeah, I thought so.

The reason for this difference is that the table in the modifier panel lists the prescribed dislocation classes, which all have manually assigned names. In contrast to this, the names of the output attributes are auto-generated from the prototype Burgers vectors, and the algorithm puts all zero entries at the end of the Miller notation.

I should rename the predefined dislocation classes in the code to make them consistent with this scheme.

6
Support Forum / Re: Data collection error
« on: February 14, 2019, 11:17:24 AM »
Hi,

The naming of the output attribute is different. It is "DislocationAnalysis.length.1/3<100>" (not <001>), as you can see in the attributes data inspector of Ovito (attached screenshot).

-Alex

7
Support Forum / Re: dump bond length for each atom
« on: February 12, 2019, 08:06:31 PM »
Yes, the class is available in Ovito 2.9.0 as well:

http://ovito.org/manual/python/modules/ovito_data.html#ovito.data.CutoffNeighborFinder

It's just the example script in the old docs doesn't demonstrate how to access properties of the neighboring atom such as their chemical type. But it works the same way as shown in the newer documentation for Ovito 3.0.0: You simply need to use the neigh.index field to look up the neighbor's information in the 'Particle Type' property array.

8
Support Forum / Re: dump bond length for each atom
« on: February 12, 2019, 07:56:25 PM »
I see, you seem to want a method for visiting all neighbors of an atom within a certain cutoff range, independent of whether they are bonded to the central atom or not. For this purpose the Ovito scripting interface provides the CutoffNeighborFinder utility class:

http://ovito.org/manual_testing/python/modules/ovito_data.html#ovito.data.CutoffNeighborFinder

The example script (for Ovito 3.0) shows how to print a list of neighbors for each atom, their distance from the central atom and how to access their type.

Is that what you were looking for?

9
Support Forum / Re: dump bond length for each atom
« on: February 12, 2019, 06:39:53 PM »
For Ovito 3.0.0-dev the code looks similar:

Code: [Select]
    atom_types = data.particles['Particle Type']
    bond_list = data.bonds['Topology']
    bond_lengths = data.bonds['Length']
    for atom_pair, bond_length in zip(bond_list, bond_lengths):
        print(atom_types[atom_pair], bond_length)

The main difference is that Ovito 3.0.0 works with full bonds, not half-bonds. Thus, it is no longer necessary to skip every other bond in the loop.

The Compute Bond Lengths modifier has been removed in Ovito 3.0.0. The simple type of computation it performs can now be accomplished with the standard Compute Property modifier. You should set it to operate on bonds instead of particles, set the output property name to "Length", and enter "BondLength" as expression.

10
Support Forum / Re: dump bond length for each atom
« on: February 12, 2019, 06:32:39 PM »
Here is a Python code snippet for Ovito 2.9.0, which prints the list of all bonds in a data collection, listing the types of the two atoms connected by a bond and the bond's length:

Code: [Select]
# Get the atom type property:
atom_types = data.particle_properties['Particle Type'].array

# Get the array containing the bond topology, i.e. pairs of atom indices;
bonds_list = data.bonds.array

# The the 'Length' bond property array previously computed by the Compute Bond Lengths modifier:
bond_lengths = data.bond_properties['Length'].array

# Simultaneously iterate over the bond topology array and the bond lengths array:
for atom_pair, bond_length in zip(bonds_list, bond_lengths):

# Skip every other half-bond, because Ovito 2.9 stores A->B and B->A bonds.
if atom_pair[0] < atom_pair[1]: continue

# Use the atom index pair to look up the types of the two atoms connected by the current bond:
print(atom_types[atom_pair], bond_length)
The code assumes that you have applied the Compute Bond Lengths modifier, which creates the 'Length' bond property being accessed in the script.

The code produces output that looks like this:

Code: [Select]
[1 2] 1.22793
[2 1] 1.13556
[1 2] 1.17782
[2 1] 1.21634
[1 2] 1.24922
...

11
Support Forum / Re: dump bond length for each atom
« on: February 12, 2019, 08:42:48 AM »
Dear Zhao,
would you like an answer for Ovito 2.9.0 or for the new 3.0.0 development release?

12
Support Forum / Re: "Locking in" particles
« on: February 11, 2019, 10:51:30 AM »
Hi,

Ovito currently doesn't provide a built-in solution to this problem. You can imagine that this isn't a trivial problem as clusters can typically grow and shrink over time or split and merge. There is no clear-cut criterion for deciding what is the "identity" of a cluster, which is necessary for tracking the cluster through time.

It's up to you to choose (and then implement, probably using a Python script) an appropriate method for deciding whether two clusters from two consecutive frames are the same or not. Ovito gives you only the list of atoms/particles that belong to each cluster in each frame.

-Alex

13
Support Forum / Re: Name on the particle
« on: February 07, 2019, 11:29:40 AM »
Not yet, sorry.
My current current focus is on getting the 3.0.0 release over the finish line. Particle labels are a feature planned for a follow-up release.

14
Support Forum / Re: Problem in loading file in OVITO 3.0.0-dev334 on macOS
« on: February 01, 2019, 09:38:54 AM »
Let's try it one more time (if you don't mind). This the current Ovito version built against the old Qt library version (5.9.7):

http://ovito.org/download/testing/ovito-3.0.0-dev341-macos.dmg

Let's see if it works any better than the previous build on your machine.

15
Thanks for letting me know.
One more thing I would like you to do: In the non-working Ovito version, please go to the Help menu, select "OpenGL Information" and send me the displayed system information. Thanks.

16
Thanks.

The main difference between builds dev234 and dev334 is the version of the included Qt library, which is used by Ovito for its user interface and also the 3d viewports. The latter Ovito build comes with Qt 5.12.0, which could be the reason for the reported problem, but I am not sure. Sometimes, things that used to work become broken in new Qt versions.
The Qt people have just published the Qt 5.12.1 maintenance release. My hope is that it includes a fix for the problem. I uploaded Ovito build dev340 to the www.ovito.org website today. Please give it a try.

-Alex

17
Dear Mahsa,

Please post a screenshot of the Ovito window here. I haven't seen this happening before and would like to get an idea of how it looks on your computer.

Please then try an older development build, for example this one:

http://ovito.org/download/testing/ovito-3.0.0-dev234-macos.dmg

Does it show the same problem?

-Alex

18
Hi again,

please ignore my previous statements regarding the WS modifier's inability to use frames from the reference trajectory other than the first frame. In the current development version of Ovito 3.0.0 the WS modifier already provides the "Reference frame number" field, which lets you select the desired frame from the trajectory. It's just that you cannot use the mentioned drop-down box to select it.

That being said, I have worked on the Ovito code in the meantime and added the missing capability of using a dynamically changing reference configuration. The newly available build Ovito 3.0.0-dev334 provides the "relative to current frame" option, which lets you use a reference configuration that is in sync with your defective configuration (see screenshot).

Just perform the following steps in the WS modifier panel:

  • Set "Reference configuration source" to "External file" and pick your dump file containing the reference trajectory,
  • select the "Relative to current frame" option, and
  • set "Frame offset" to 0.

You will also notice that the non-functioning drop-down frames list, which contributed to your confusion, is hidden now.
With the new extension you shouldn't need a Python script anymore to do what you wanted to.

-Alex

19
Hi liammo29,

Here is some additional info regarding the original problem from my side, the Ovito developer:

The Wigner-Seitz function is currently limited to static reference configurations. This is unlike the Displacement Vectors and Atomic Strain functions, which already support dynamically changing reference configurations. This option is needed to perform the frame-by-frame analysis of the defective trajectory with respect to the corresponding frames of the reference trajectory.

Unfortunately, there currently is a drop-down box in the WS-modifier user interface listing all frames of the selected reference trajectory. It may lead you to think that it allows you to select a reference frame from the trajectory. However, that is not the case. This drop-down list is only there, because Ovito re-uses the same UI panel as for the main trajectory, where it allows you to quickly jump in time to a specific frame. In case of the reference trajectory, it doesn't work like that though. The only way to select a different reference frame other than the first one from the trajectory dump file is to split the reference trajectory into a series of individual dump files. (Use Ovito's export function for that). Then you can load in a specific frame as reference configuration.

However, even with this approach the reference frame will still be static. So it doesn't solve the original problem, which is to update the reference in sync with the main trajectory. I agree with Constanze that the only solution to this problem currently is the usage of a Python script.

Note that her script is for the current 3.0.0 development release. Your screenshot suggests that you were still using the old 2.9.0 program release.

20
Support Forum / Re: Quantum espresso files
« on: January 23, 2019, 02:52:37 PM »
You are probably referring to the import_file() Python function. Yes, this function can load all file formats that are supported by the graphical program version, including the QE format.

21
Support Forum / Re: Unwrapping dislocation segments in the CA file
« on: January 22, 2019, 09:50:44 AM »
Hi,

The CA storage format reflects how the dislocation lines are represented in memory by Ovito: A single dislocation is always represented as one continuous line, which doesn't wrap back into the simulation box. The first vertex of the line is typically located inside the simulation box, but the other vertices of the line may be located outside of the box if it crosses a periodic box boundary.

When Ovito renders the dislocation lines in the viewports, it folds them back into the simulation box on the fly and splits segments when necessary. If you are interested in this "wrapped" representation of the dislocation lines, you should export the dislocation data to the "VTK Dislocation Lines" file format instead of the CA format.

-Alex

22
Support Forum / Re: run ovitos on HPC
« on: January 17, 2019, 08:44:30 AM »
Dear Zhao,

You can prevent "ovitos" from connecting to the X server by clearing the DISPLAY environment variable before executing "ovitos":

   export DISPLAY=
   ./ovitos yourscript.py

Or even simpler:

  DISPLAY= ./ovitos yourscript.py

-Alex

23
Support Forum / Re: Orbit center
« on: January 16, 2019, 04:04:57 PM »
Hi Chris,

OVITO uses the geometric center of the axis-aligned bounding box enclosing all objects that are currently visible as camera orbit center by default. Thus, if you hide some objects such as the simulation cell or the particles, the dynamically computed bounding box changes accordingly. In particular this will be the case if some of the particles are positioned outside the simulation cell (which otherwise determines the "bounding box" just by itself).

You can manually override the dynamically computed orbit center by double-clicking on an object in the viewports. However, there currently is no way to specify the coordinates of the orbit center numerically.

-Alex

24
Hi Vivek,

From your error messages it seems that you are using a recent development version of Ovito 3.0.0. The script you mentioned is not compatible with that version anymore, because the programming interface has slightly changed.

The good news is that Ovito 3.0.0 provides a built-in capability to compute partial RDFs, see here:

http://ovito.org/manual_testing/particles.modifiers.coordination_analysis.html

You can access this new capability of the CoordinationAnalysisModifier from a Python script. Please see the first example script in the referenced Python docs. All you need to do additionally, is to set the partial option of the modifier to True.

-Alex

25
Dear Karthik,

the crash report that you sent suggests that the failure, which looks like an infinite recursion, occurs inside a third-party library routine, which is used by the DXA algorithm of Ovito to construct the Delaunay tessellation.

You are using Ovito 2.9.0. I suggest you try the current development build, Ovito 3.0.0-dev322. It comes with a newer version of the Geogram library. Maybe the problem has been solved by the authors of that library.

-Alex

26
Hi,

I've never heard of "Bus error 10" before, and I don't know what it means. But it is possible that it indicates an out-of-memory situation. Keep in mind that DXA is a memory intensive algorithm. You need at least 1 kilobyte of free memory per input atom!

However, Ovito should allocate memory only while the DXA analysis is running and release it again after DXA is done. Let me know if you have the feeling that the error is not memory related. Please use Activity Monitor of macOS to check the memory consumption of Ovito.

-Alex

27
Support Forum / Re: Varying Number of Particles
« on: January 03, 2019, 09:22:48 PM »
Hi,
I can confirm -after looking at the source code again- that Ovito should be capable of reading GSD files with varying number of particles, at least in principle. This may have never been tested though. As Constanze wrote, please send us a test file, and we'll investigate this further. Thanks.
-Alex

28
Support Forum / Re: Lammps data file bond property coloring
« on: December 29, 2018, 12:15:27 PM »
Hi,

Ovito's data file parser currently ignores the "Bond Coeffs" section in LAMMPS data files. There is no way to associate auxiliary information with bond types.

But I am wondering if this is really what you want anyway. It sounds like you would like to associate each bond with an individual property value, not each bond type. Right? Because that is also what would be needed as input for the "Color Coding" modifier. It operates on values of individual bonds, not bond types.

Let's say you first load in the bonds list from the LAMMPS data file, and you prepare a separate text file containing just the additional per-bond values which you would like to be available within Ovito. This second data file contains one line per bond and one numeric value per line. You can use a Python script modifier within Ovito to import this file (typically using the numpy.loadtxt() function) and assign it as a new property to the already loaded bonds. Subsequently, the new bond property will be available as input for the Color Coding modifier.

Do you think that approach would solve your problem? If so, I can help you with writing the Python script function for loading the bond property array and assigning it to the bonds.

-Alex

29
Support Forum / Re: remove atom from spherical system
« on: December 29, 2018, 12:00:39 PM »
Hi,

If your particle is exactly spherical, and if you know its size, you could use the "Expression Selection" modifier of OVITO to select all atoms in the interior of the particle whose coordinates are fall within a spherical region of a given radius.

If the shape of your nanoparticle is not precisely known, you need a way to adaptively determine the atoms that are located outside a certain distance from the particle's surface. A common way to do this is to use the atomic coordination number to select atoms which are fully coordinated and deselect those that are under-coordinated, because they are located close to the surface. In Ovito, you can use the "Coordination Analysis" modifier to compute the number of neighbors of each atom within a given range (let's say 3.0 Angstroms). Subsequently you can use again the Expression Selection modifier to select all bulk atoms having a coordination number above a certain threshold. Let's say 80% of the usual coordination number of bulk atoms in the interior of the nanoparticle.

-Alex

30
Support Forum / Re: Draw and color triangles/polygons
« on: December 29, 2018, 10:39:54 AM »
Hi Botond,

Where are the data values coming from that you want to use for coloring the triangles? Are they derived from some atomic property of the vertex atoms, or should they be loaded from a separate data file?

-Alex

Pages: [1] 2 3 ... 19