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 ... 20
1
Support Forum / Re: Failed to initialize Python interpreter.
« on: March 18, 2019, 03:38:38 PM »
Hi Corolina,

Did you install one of the Ovito packages we provide on our website? If so, which version? This question is just to make sure you did not install an old version of Ovito from the Debian package repository, for example.

In which location on your computer did you extract the Ovito archive during installation? The error message suggest you have installed it under /usr/bin/. Is this correct? Ovito is commonly installed under a user's home directory.

How did you run "ovito" (the graphical program)? If you run it from the terminal in the same way you run "ovitos", the two should behave exactly the same. Depending on how you run the two, they may see different environment variables (e.g. PYTHONPATH), which in turn may affect the loading of Python modules.

-Alex

2
Support Forum / Re: Lattice rotation
« on: March 18, 2019, 11:32:33 AM »
Dear Rajdeep,

Note that your transformation matrix is not a proper rotation matrix: ([111], [1-10], [11-2]), because its column vectors are not normalized. A rotation matrix must have unit column vectors, all orthogonal, and its determinant must be 1. Since your matrix doesn't fulfill these criteria, you are getting something that is not a pure rotation.

It should suffice to normalize each column vector to obtain a rotation matrix, i.e.

([111]/sqrt(3), [1-10]/sqrt(2), [11-2]/sqrt(6))

-Alex

3
Support Forum / Re: Modifying particle type name in latest Beta
« on: March 15, 2019, 03:28:13 PM »
Hi,

Catching the exception won't help. The ParticleType object, whose name you are trying to change, is locked by default. This is to prevent accidental and permanent modification of data that actually belongs to the upstream pipeline. Modifiers are only allowed to modify copies of data, which are generated along the way down the pipeline. They can never alter the original input data objects.

That being said, here is how you can request a copy of the ParticleType object, which can then be safely modified within the modifier function:

Code: [Select]
    ptype_property = data.particles_['Particle Type_']
    for defect_type in ptype_property.types:
        mutable_defect_type = ptype_property.make_mutable(defect_type)
        mutable_defect_type.name = defect_names[defect_type.id]

The code uses the yet undocumented DataObject.make_mutable() method, which allows you to turn a sub-object into a modifiable version. In this case the ParticleType object is a sub-object of the Property object. That's why we call make_mutable() on the ptype_property. The method basically has the same effect as the '_' notation, just doing it explicitly.

Note that this code does not rename the original particle types. It renames copies of these types that are made along the data pipeline. Thus, the changes will only be visible to modifiers following your Python modifier function in the pipeline.

If you would instead like to modify the original particle types, you would have to do it from outside of a modifier function.

Let me know if you have any further questions.

-Alex

4
Support Forum / Re: Fatal Python error: deallocating None
« on: March 15, 2019, 02:32:09 PM »
Hi Michelle,

It turned out that this error is due to a bug buried deep down in the Python interface layer of Ovito. It took me a while to figure out what is going on, because the bug only leads to a visible problem after creating a new global attribute in the DataCollection.attributes dictionary more than approx. 10,000 times.

I've fixed the bug in the source code:

https://gitlab.com/stuko/ovito/commit/d4f42c1a4723ff2460dcca9d7a91e5294e42a87e

You can download the new build 3.0.0-dev352 for Linux, which should solve the problem.

-Alex

5
Support Forum / Re: remove surface mesh
« on: March 14, 2019, 08:40:18 AM »
Hi,

The DislocationAnalysisModifier is currently not providing direct access to the visual element of the defect mesh. This is a mistake, which I am going to fix in the next development build of Ovito 3.0.

In the meantime, you can use the following workaround:
Code: [Select]
defect_mesh = pipeline.compute().surfaces['dxa-defect-mesh']
defect_mesh.vis.enabled = False

-Alex

6
Support Forum / Re: surface mesh creation in for loop version 3.0.0
« on: March 12, 2019, 09:17:40 PM »
Hi Chris,

Please don't keep appending additional instances of the ConstructSurfaceModifier to the same pipeline in your loop. This may easily lead to a situation where Ovito needlessly constructs the surface mesh multiple times during every call to Pipeline.compute().

That being said, the first real problem in your script I see is in this line:
Code: [Select]
node.compute

This isn't a proper function call, because the parentheses are missing. Unfortunately, Python silently accepts this syntax and won't tell you about the fact that the pipeline doesn't get computed. Please correct it to
Code: [Select]
node.compute()


Here is how I would translate the script to the new Ovito 3.0 style:

Code: [Select]
pipeline = import_file(file)

pipeline.modifiers.append(SelectParticleType(types = {'W'}) #constructing a surface over water molecules
mod = ConstructSurfaceModifier(only_selected = True)
pipeline.modifiers.append(mod)

loops = numpy.linspace(5,16,50)

for radius in loops:
    mod.radius = radius
    data = pipeline.compute()
    area = data.attributes['ConstructSurfaceMesh.surface_area']
    fraction = data.attributes['ConstructSurfaceMesh.solid_volume'] / data.cell.volume

7
Support Forum / Re: set echo off when using ovitos with sftp
« on: March 11, 2019, 11:48:21 AM »
Thanks for letting us know.

I'm not sure why Ovito 2.9.0 ignores the username you provide as part of the SFTP URL, but since it seems to work with the current development build, I won't take further actions for now. Let me know if you need anything else.

8
Support Forum / Re: twinning
« on: March 08, 2019, 08:42:39 AM »
Hi Wang,

DXA only identifies the dislocation lines themselves, but it cannot tell you where twinning took place in the crystal (which isn't strictly associated with the presence of dislocations). I would say the most natural way to identify twinning is to do a strain field analysis. In OVITO you can use the Atomic Strain modifier for this. In regions of the crystal that have undergone twinning, you should see a characteristic shear strain level. As an additional criterion, you could use the Common Neighbor Analysis to restrict the selection set to perfect FCC atoms (in order to exclude HCP-like stacking fault atoms, which may exhibit the same atomic shear strain values).

-Alex

9
Support Forum / Re: Building OVITO from source
« on: March 08, 2019, 08:35:26 AM »
There seems to be a problem with the library "/projects/opt/centos7/anaconda3/lib/libQtGui.so.4" from the Anaconda distribution. Is this the right installation of the Qt 5.x libraries that you intended to use? I can't tell for sure from the error message, but at least I can imagine that this crash results from a conflict between several Qt5 installations present on your system. Perhaps Ovito was compiled against a different Qt version than the one being loaded at runtime. Please attach the CMakeCache.txt file from your build directory. Then I will take a look at your build configuration.

10
Support Forum / Re: Building OVITO from source
« on: March 07, 2019, 06:05:56 PM »
Please run just "make", not "make -j8". When doing a parallel build, error messages can easily get lost in the verbose console output. If you run just "make" to perform a serial build, any error messages should follow at the very end and should be easily visible.

I would find it very surprising if the build succeeds but there is no /bin/ovito executable being produced (unless you've set OVITO_BUILD_GUI to OFF for some reason).

11
Support Forum / Re: Building OVITO from source
« on: March 07, 2019, 03:16:25 PM »
The dependency of the CrystalAnalysis plugin on the NetCDF library has been introduced just recently, and only for an experimental feature that you don't need. If required, you can temporarily remove this dependency by removing the following lines from the CMake script:

https://gitlab.com/stuko/ovito/blob/master/src/plugins/crystalanalysis/CMakeLists.txt#L24
https://gitlab.com/stuko/ovito/blob/master/src/plugins/crystalanalysis/CMakeLists.txt#L70

And the three lines in the other CMake file linked in my post above.

-Alex

12
Support Forum / Re: Building OVITO from source
« on: March 07, 2019, 02:37:37 PM »
Hi,

First of all, let me mention that you should be able to run Ovito from inside the build directory. Thus, it may not really be necessary to first install it via "make install". Please try.

Now regarding your question: Even though its name may suggest otherwise, the "NetCDFPlugin" is not the only module that depends on the NetCDF/HDF5 libraries. The "CrystalAnalysis" plugin also requires the NetCDF/HDF5 libraries. Thus, unless you also set the "OVITO_BUILD_PLUGIN_CRYSTALANALYSIS" CMake variable to OFF, the build script will still try to build and install the "NetCDFIntegration" target, which in turn requires the NetCDF & HDF5 system libraries to be available on your system.

See this part of the CMake code:
https://gitlab.com/stuko/ovito/blob/master/src/3rdparty/CMakeLists.txt#L39-41

So one way to resolve your build problem is to disable the CrystalAnalysis plugin as well. You will then loose the Construct Surface Mesh and Dislocation Analysis modifiers though. I'm not sure if you need them.

I tried to build and install Ovito on my Ubuntu machine with OVITO_BUILD_PLUGIN_NETCDFPLUGIN set to OFF and OVITO_BUILD_PLUGIN_CRYSTALANALYSIS set to ON. This worked without problems. This suggests that the error you encountered is specific to the Centos environment. Is this why you had to disable the NetCDF plugin in the first place?

-Alex

13
Support Forum / Re: How can I output all the burger's vectors?
« on: March 07, 2019, 08:47:02 AM »
Hi,

Yeah, there currently is no convenient way of exporting this specific table to an output file. The only option you have is to use a Python script to print the information of each dislocation line to the console or an output text file. The example code snippet found here shows how do this. It's a simple loop over all dislocation lines:

Code: [Select]
data = pipeline.compute()
for segment in data.dislocations.segments:
    print("Segment %i: length=%f, Burgers vector=%s" % (segment.id, segment.length, segment.true_burgers_vector))

-alex

14
Support Forum / Re: Find neighbors of atoms(structure = 0)?
« on: March 07, 2019, 08:37:27 AM »
Hi,

You wrote that you would like to select atoms whose neighbors all fulfill a specific criterion. I am wondering how you define what is a neighbor atom in this case. The code snippet you posted uses the NearestNeighborFinder class, which will visit the N nearest neighbors of the central atom (N=12 in your example). Here, it doesn't play a role how far these 12 neighbors are away from the central atom. And this approach ignores the fact that a non-crystalline atom may actually have fewer or more than 12 nearest neighbors.

An alternative approach would be to use the CutoffNeighborFinder instead and consider all neighbors that are within a specific range. This would make your life easier, because then you could directly make use of the Compute property modifier to identify the desired atoms, without the need to write a Python script.

The attached screenshot shows how to set it up: The Boolean expression "StructureType != 0" has been assign to both the central atom field and the neighbor atom field. This expression will yield non-zero contributions in case either the central atom or any of its neighbors within the given cutoff radius have a non-zero structure type. Thus, all you have to do next is use the Expression selection modifier to create a selection set containing all atom whose "MyProperty" particle property (created by the Compute Property modifier) is zero.

-Alex

15
Support Forum / Re: cluster size through WS analysis
« on: March 05, 2019, 09:45:21 PM »
Hi LB,

The only "mistake" I can spot in your script is in this part:

Code: [Select]
select_vacancies_mod = node.modifiers.append(SelectExpressionModifier(expression ='Occupancy==0'))
node.compute(select_vacancies_mod )

The modifiers.append() method doesn't return anything which could be assigned to a variable. Neither does the node.compute() method accept a modifier as an argument. So you probably should just do:

Code: [Select]
select_vacancies_mod = SelectExpressionModifier(expression ='Occupancy==0')
node.modifiers.append(select_vacancies_mod)
node.compute()

By the way, there is no need to repeatedly call node.compute() in between adding modifiers to the pipeline. It's sufficient to call it just once at the very end once the pipeline has been completely set up and when you want to retrieve the final results.

I'm not sure why you are not getting any output. Perhaps the sequence of modifiers ends up deleting all particles for some reason? Have you already tried running your script via the "ovitos" interpreter from the command line (instead of from within Ovito)? This approach has the advantage that you can add print() statements to your program to write information and intermediate results to the console.

-Alex

16
Support Forum / Re: selecting certain frames of trajectory files
« on: March 01, 2019, 09:40:02 AM »
Hi,

This doesn't seem possible with the current version of Ovito, at least not in the graphical user interface. What are you trying to accomplish? Do you want to render an animation?

The only way to do this right now is with a Python script, in which you actively turn the modifier on or off while stepping through the trajectory frames with a for-loop.

-Alex

17
Ah, I see. So instead of using the discrete deformation mapping computed by Ovito's Atomic Strain modifier, you would rather like to compute a continuous deformation field based on a Delaunay tessellation.

You sure do have the right to read (and modify) the source code of Ovito. There main source files related to the Construct Surface Mesh modifier are the following:

https://gitlab.com/stuko/ovito/blob/master/src/plugins/crystalanalysis/modifier/ConstructSurfaceModifier.cpp
https://gitlab.com/stuko/ovito/blob/master/src/plugins/crystalanalysis/util/DelaunayTessellation.cpp
https://gitlab.com/stuko/ovito/blob/master/src/plugins/crystalanalysis/util/ManifoldConstructionHelper.h

There is an old code of mine (no longer maintained), which supports calculating the continuous deformation mapping for a particle system based on the Delaunay tessellation:

https://gitlab.com/stuko/crystal-analysis-tool

See the user manual in doc/ subdirectory (the PDF may not display correctly in the web-browser; better download it). This standalone code could serve you as another starting point for your own developments. The code can output the calculated deformation gradient for each Delaunay element to a VTK file.

18
Hi,

The Delaunay tetrahedra are thrown away once the surface mesh has been built (and before the triangle mesh is being smoothed in the final algorithm step). Thus, there currently is no way to access this information in the output of the modifier pipeline. You would have to hack the C++ sources of the Construct Surface Mesh modifier in order to access the Delaunay structure.

Why are you interested in getting hold of the tetrahedra forming the solid region?

-Alex

19
I didn't pay much attention to this detail, but I think you are getting this error due to the way you are running the script from the command line. You do

   ovitos < scriptName.py

but instead you should just do

   ovitos scriptName.py

Piping the script file into the interpreter using the "<" operator seems to work with your first script (a fact that is very surprising to me) but not with the second script containing the loop, probably because the indented loop code block gets not executed correctly.

20
Hi Nick,

You wrote that it "stops working". Could you please elaborate on what happens. Do you get an error message? Do you get wrong or no results?

Just from looking at the scripts I don't see an obvious reason why the second version shouldn't work. However, since all loop iterations operate on the same input data file, I suggest you rearrange the script a bit in order to avoid loading the same input file over and over again. The following version will re-use the existing pipeline, just reconfiguring one of the modifiers during each iteration:

Code: [Select]
node = import_file("dump.mycoords.5000")
modifier1 = SelectExpressionModifier()
node.modifiers.append(modifier1)
mod = ConstructSurfaceModifier(radius = 3.5, smoothing_level = 10, only_selected = True)
node.modifiers.append(mod)
for x in range(1, 107):
modifier1.expression = 'MoleculeIdentifier=={x}'.format(x=x)
filenameW = "New" + str(x) + ".txt"
export_file(node, filenameW, "txt", multiple_frames = False, columns = ["Frame", "ConstructSurfaceMesh.solid_volume", "ConstructSurfaceMesh.surface_area"])
print("particle %i completed" % (x))

-Alex

21
Support Forum / Re: set echo off when using ovitos with sftp
« on: February 21, 2019, 09:51:00 AM »
No, normally this should not happen. Can you please post the script so I can see how you specify the SFTP address?

If you have switched to Ovito 3.0.0-dev already, you can activate verbose log messages by setting the OVITO_SSH_LOG environment variable. This will show you more information about the SSH connection and authentication process:

Code: [Select]
export OVITO_SSH_LOG=1
./ovitos your_script.py

Note that you can test the SSH/SFTP remote file access also from within the graphical Ovito program. If it works there, it should also work the same way from a Python script.

22
Support Forum / Re: Surface indexing using ovito
« on: February 21, 2019, 07:34:33 AM »
Hi Angel,

I don't think that Ovito can directly solve your problem. But I am still trying to understand exactly what you would like to do, or what you would like Ovito to do for you.

As you said, the PTM already allows to calculate the local crystal orientations at each atom. If I understand you correctly, you would like to take an input vector in the simulation coordinate system, for example the normal vector of a slicing plane, and transform it to the local lattice coordinate system. Is this the information you are interested in?


-Alex

23
Support Forum / Re: set echo off when using ovitos with sftp
« on: February 20, 2019, 09:18:08 AM »
Hi,

That's a good question. I never thought about it before. The "set echo off beforehand!" message is meant as a warning to you, because Ovito has no way of concealing your keyboard input when you enter the password. Thus, the password will appear as clear text in the terminal and every bystander can potentially see it.

Unix/Linux terminals, however, provide a way to hide all keyboard input entered by the user. You can activate this mode using the "stty -echo" terminal command (to reactivate the display again use "stty echo"). You need to activate the "echo-off" mode before running ovitos.

https://egloo.wordpress.com/2008/10/13/turn-off-echo-in-a-terminal/

Note that newer versions of Ovito provide support for public-key SSH authentication. Thus, if you use this type of authentication instead of password authentication, the above problem is no longer an issue and you have the advantage of your ovitos script running without any user intervention.

-Alex

24
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.

25
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

26
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

27
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

28
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.

29
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

30
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.

Pages: [1] 2 3 ... 20