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 ... 28
1
Support Forum / Re: error reading XDATCAR files for npt simulations
« on: July 17, 2018, 11:45:05 AM »
Dear Ilya,

The support for XDATCAR files has been improved in Ovito recently. While older versions could only read files with fixed cell geometry, the latest development version supports more variants of the XDATCAR format, corresponding to various settings of the ISIF parameter of VASP. So please download the latest dev build of Ovito and try again.

-Alex

2
I am collecting the most important changes on this page of the new scripting reference manual that ships with OVITO 3.0:

http://ovito.org/manual_testing/python/introduction/version_changes.html

3
Hi,

A few of the Python interfaces have changed in OVITO 3.0, in particular those related to bonds. Instead of using a half-bond representation, OVITO now uses a full-bond representation. Furthermore, the bond topology is now stored in a regular bond property named 'Topology' instead of a special Bonds object. Finally, the BondsEnumerator class constructor now expects a DataCollection object as argument, not a Bonds object anymore.

I adapted your script code to the new programming interface (without running it). Hope I didn't miss something. I tried to mark the key lines that have changed with a <---- comment.

Code: [Select]
from ovito.io import *
from ovito.modifiers import *
from ovito.data import *   # <------

# Import standard Python and NumPy modules.
import sys
import numpy

# Load the simulation dataset to be analyzed.
pipeline = import_file("input.dump")

#create a output file
file = open('output_file.txt' , 'w')

# Create bonds.
pipeline.modifiers.append(CreateBondsModifier(cutoff = 3.5))

# Compute CNA indices on the basis of the created bonds.
pipeline.modifiers.append(
        CommonNeighborAnalysisModifier(mode = CommonNeighborAnalysisModifier.Mode.BondBased))
                     
# Let OVITO's data pipeline do the heavy work.
data = pipeline.compute()

# A two-dimensional array containing the three CNA indices
# computed for each bond in the system.
cna_indices = data.bonds['CNA Indices']      #<------

# This helper function takes a two-dimensional array and computes the frequency
# histogram of the data rows using some NumPy magic.
# It returns two arrays (of same length):
#    1. The list of unique data rows from the input array
#    2. The number of occurences of each unique row
def row_histogram(a):
    ca = numpy.ascontiguousarray(a).view([('', a.dtype)] * a.shape[1])
    unique, indices, inverse = numpy.unique(ca, return_index=True, return_inverse=True)
    counts = numpy.bincount(inverse)
    return (a[indices], counts)

# Used below for enumerating the bonds of each particle:
bond_enumerator = BondsEnumerator(data)  # <------

# This will be needed later:
bond_topology = data.bonds['Topology']  # <-----

# Loop over particles and print their CNA indices.
for particle_index in range(data.particles.count):   # <-------
   
    # Print particle index (1-based).
    sys.stdout.write("%i " % (particle_index+1))
    # Create local list with CNA indices of the bonds of the current particle.
    bond_index_list = list(bond_enumerator.bonds_of_particle(particle_index))
    local_cna_indices = cna_indices[bond_index_list]

    # Count how often each type of CNA triplet occurred.
    unique_triplets, triplet_counts = row_histogram(local_cna_indices)
   
    # Print list of triplets with their respective counts.
    for triplet, count in zip(unique_triplets, triplet_counts):
        sys.stdout.write("%s:%i " % (triplet, count))
        file.write("\n%i %s:%i " % (particle_index+1, triplet, count))

# Loop over bonds of current atom.
# Note that OVITO 3.0 doesn't use half-bonds anymore. It works with full bonds,
# which means the bonds enumerator will return bonds TO as well as FROM the
# current atom.
    for bond_index in bond_enumerator.bonds_of_particle(particle_index):
        atomA = bond_topology[bond_index, 0]  # <-------
        atomB = bond_topology[bond_index, 1]  # <-------
        assert(atomA == particle_index or atomB == particle_index)   # <-------
        print("\nAtom %i has a bond to atom %i" % (atomA, atomB))
        file.write("\nAtom %i has a bond to atom %i" % (atomA, atomB))

    # End of particle line
sys.stdout.write("\n")
file.close()

-Alex

4
Support Forum / Re: Python script for cluster size
« on: July 03, 2018, 10:07:45 AM »
Could you please let us know which operating system and version of OVITO you are using and upload the data file and the script file as an attachment here? Then I will try to reproduce the problem. Right now I don't have a clear idea what is happening.
... And if you perform any actions in the graphical user interface before running the script, please save everything as a .ovito state file and post that one too. Thanks!

5
Support Forum / Re: Question about output.particle_properties.*.array
« on: July 01, 2018, 07:57:57 AM »
Dear Shuai,

The following type of particle property access in a data collection works only for standard particle properties but not for user-defined properties:
Code: [Select]
output.particle_properties.c_pepa
Instead, for user-defined properties, you have to use the normal dictionary-based lookup approach (which will become mandatory for standard properties as well in Ovito 3.0):
Code: [Select]
output.particle_properties['c_pepa']

See the documentation of the DataCollection class.

Furthermore, you are working with a user-defined modifier function in your script. I noticed that your definition of the modify() function is not quite correct (but it probably works anyhow after fixing problem 1 described above). Modifier functions should, under normal circumstances, be pure (=stateless and deterministic) functions that do not access any scene objects that exists outside of the function. They should only access data that is being passed to them by the system via the input function parameter. Thus, you should change the reference to the external node.output field to the input data collection of the modifier function, i.e.:
Code: [Select]
def modify(frame, input, output):
    output.attributes['b'] = np.sum(input.particle_properties['c_pepa'].array)

-Alex

6
The Centrosymmety modifier of Ovito -in conjunction with a Color coding modifier- may help you visualise defects in the sheet. Set the number of neighbors parameter to 6.

http://ovito.org/manual/particles.modifiers.centrosymmetry.html

7
Dear Bahman,

This is true. OVITO has structure identification methods mostly for three-dimensional crystalline structures.

I am curious: What types of 2d structures would you like to analyse?

-Alex

8
Support Forum / Re: Non-affine mean displacements calculations
« on: June 26, 2018, 02:52:27 PM »
Hi Pablo,

Yes I agree, it would make more sense if the D2min were normalised (i.e. divided by) the number of neighbors that were included in the summation. OVITO doesn't do it for historic reason. The code for calculating D2min was contributed by somebody else, and he strictly followed the formulation given by Falk and Langer in their paper, which doesn't include a division by the number of neighbors. When I realised that it would be useful to automatically do the normalization, it was much to late to change the behaviour of OVITO.

So if you want to do the normalization yourself, you first need to determine the number of neighbors of each particle that enter into the calculation of the atomic deformation gradient and the D2min value. It's important to note that the set of neighbors that enters into this calculation is always determined in the undeformed configuration, which is static. On the other hand, the actual calculation of D2min happens in the deformed configurations. This distinction makes it somewhat cumbersome to do the normalization, because we need to perform the neighbor counting in the undeformed configuration, store the neighbor count of each atom, and use this information later when the actual D2min calculation is performed in the deformed configuration, i.e. in a later frame of the simulation.

OVITO allows you to do this using the following sequence of modifiers (listed in bottom-up order, like in the user interface):

4. Compute Property: The expression should be set to "NonaffineSquaredDisplacement/Coordination". So this modifier performs the actual normalization by dividing the D2min value calculated by the Atom Strain modifier by the "Coordination" property calculated by the Coordination Analysis modifier. The results of that calculation get stored in a new output particle property by the modifier.

3. Atomic Strain: That's the modifier calculating the D2min value for each atom.

2. Freeze Property: This modifier lets you preserve the values of the "Coordination" particle property computed at frame 0 (i.e. in the undeformed config). Once this modifier has been inserted into the data pipeline, the frozen property values will no longer change at the later simulation frames (which they would otherwise do, because particles are moving around and their coordinations dynamically change)

1. Coordination analysis (this modifier counts the number of neighbours that are within a given cutoff radius and stores the results as a new particle property named "Coordination". Make sure the cutoff radius parameter exactly matches the one used for the Atomic Strain modifier above.)

9
In principle, you can draw anything you like using the painting functions of the QPainter class from the Qt framework. The rudimentary scale "bar" was okay for my purposes when I wrote that demo code, but anything beyond that requires that you write additional Python code yourself.

10
Your code only calls the fillRect() function. I think, additionally, you need to call drawRect() to draw a border on top. The thickness and color of the border will be determined by the pen that was previously set on the QPainter object. So probably another call to setPen() is in order as well to first specify the border color.

11
Hi,

I assume you are working with the latest development version of OVITO 3.0. Here, the programming interface has changed in a way that is not backward compatible with previous versions.

It is longer possible to access the loaded input data using the expression 'pipeline.source.particle_properties', because the data source is no longer a data container itself. You need to evaluate the data source and request the data collection instead using its compute() method:

atypes = pipeline.source.compute().particles['Particle Type'].types

See the 'data access' section of the FileSource class documentation. Note that I have further adapted the code line to the new programming interface.

-Alex

12
Support Forum / Re: Non-affine mean displacements calculations
« on: June 17, 2018, 01:44:24 PM »
... And thank you for the positive feedback on OVITO. I really appreciate it and I'm glad you find the program useful.

13
Support Forum / Re: Non-affine mean displacements calculations
« on: June 17, 2018, 01:43:16 PM »
Dear Pablo,

I'm not sure whether (and why) the system-average D^2 value and the MSD value should really match as you claim, but I can imagine that under certain circumstances the two quantities should correlate and show a similar magnitude.

One detail that may not become clear from the documentation of the Atomic Strain modifier is that the D^2 value computed by OVITO does not get normalised by the number of neighbors of an atom. The D^2 value of one atom is simply the sum over the squared non-affine relative displacements of all its neighbors.  If you increase the cutoff radius parameter, more neighbors will contribute and the resulting D^2 value will naturally rise.

I think this might provide an explanation why the D^2 values you observe are so much higher than the per-atom MSD values. To correct them, you need to divide the D^2 values by the number of neighbors within the cutoff range, basically to avoid double counting displacements. the number of neighbors in the reference configuration can be determined using the Coordination Analysis modifier and a Freeze Property modifier.

-Alex

14
Support Forum / Re: Problem with export_file
« on: June 15, 2018, 12:24:18 PM »
Leila,

I noticed the following in your script:

You first import an entire file sequence, but then you import each individual file again in the for-loop, it seems:

Code: [Select]
node1 = import_file("/home/leila/Leila_sndhard/codes/gb_mobility_test/gb_mob/results_dE0.01/gb_ts100_T800/f.010/zdump/zdump.*.out", multiple_frames = True)
...
for i in range(n_f):
    node = import_file (filenames[i+1])

OVITO 2.9.0 contains a software bug, which leads to an I/O error when you call import_file() too often from a script (typically a few hundred times). This may be why you got the error message. The problem is fixed in the newer development versions.

But importing the file sequence just once should be enough in your case. Simply remove the import_file() call from the loop and use the existing pipeline node1 instead for processing each frame.

In fact, you don't even need the for-loop in the present case. The following lines should be enough (and will generate one big output file with all displacements for all frames, which you asked for):

Code: [Select]
node1 = import_file("/home/leila/Leila_sndhard/codes/gb_mobility_test/gb_mob/results_dE0.01/gb_ts100_T800/f.010/zdump/zdump.*.out", multiple_frames = True)
dmod = CalculateDisplacementsModifier()
dmod.reference.load(filenames[i])
node1.modifiers.append(dmod)
export_file(node1, "msd_data.txt",format = "xyz", columns = [ "Particle Identifier", "Particle Type", 'Displacement Magnitude'], multiple_frames = True)

15
Support Forum / Re: Problem with export_file
« on: June 14, 2018, 05:10:15 PM »
Dear Leila,

Please say something about the "MSD" array. How is it generated? And does it represent per-particle information or something else?

It seems that the "MSD" field currently is a global attribute and not a particle property. That is because the "txt" file export format only allows to export global attributes but not per-particle data. If you would like to export particle/=-based information, then you have make sure that "MSD" is a particle property first, and then use the "xyz" export format.

-Alex

Pages: [1] 2 3 ... 28