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 4 ... 21
31
Regarding your second question: No, at the moment there is no way to select which coordinate axis points upward from Python. I will add a corresponding option in a future version of OVITO.

32
Hi,

You probably should set the Viewport.fov parameter to a smaller value. This should give you a more parallel type of perspective projection.

-Alex

33
Support Forum / Re: animated motion of particles using trajectory line
« on: April 18, 2019, 03:07:00 PM »
Yes, in Ovito 3.0.0-dev, the Generate Trajectory Lines modifier is all what is needed to produce this kind of animation.

-Alex

34
Support Forum / Re: error during compilation
« on: April 17, 2019, 06:50:56 PM »
Thanks for letting us know.

Could you please also give us some info on the environment in which you have been building Ovito. Like the OS name and version, and the version of the Libav library on your system.

Thanks.

35
Support Forum / Re: The DXA misjudges the burgers vector
« on: April 17, 2019, 12:13:06 PM »
Right, I forgot that the Affine Transformation modifier won't act on the dislocations lines. That's a missing feature I might add in a future version of Ovito.

Another option is to use the object rotation tool from the main tool bar, see the attached screenshot. It allows you to rotate the entire model around the coordinate axes.


36
Support Forum / Re: The DXA misjudges the burgers vector
« on: April 17, 2019, 11:06:49 AM »
There might be another solution, which is even easier than what I have proposed before:

You can apply an Affine Transformation modifier to your model prior to the Dislocation Analysis (DXA) modifier in order to bring the crystal (including the simulation cell) into a different orientation, which shows less spurious symmetry flips. The aim is to (roughly) align the [100] direction of your crystal with the x-axis of the global coordinate system, the [010] direction with the y-axis, and the [001] direction with the z-axis. For this specific crystal orientation, DXA includes extra measures to avoid symmetry flips and should yield a stable crystal lattice orientation.

I don't know the orientation of your crystal, but it shouldn't be too difficult to figure out the rotation matrix that is needed to transform the crystal into the [001] standard orientation. If you like, you can then apply a second Affine Transformation modifier, with a reverse rotation matrix, to bring the crystal and the extracted dislocation lines back into the original orientation after DXA has been performed.

37
Support Forum / Re: The DXA misjudges the burgers vector
« on: April 17, 2019, 09:59:49 AM »
The two screenshots you posted show only a single dislocation line, so there wouldn't be much to identify. But do you mean you actually have multiple dislocations in your simulation, all with different 1/2<111> Burgers vectors, that you would like to identify?

One way would be to look at the "spatial Burgers vectors" of these dislocations. As mentioned before, these vectors are all expressed in the same static and global coordinate system and are not subject to spurious lattice symmetry flips. However, they are subject to elastic lattice strains, meaning they will never be mathematically exact 1/2<111> vectors. Thus, you will have to apply some rounding procedure to determine the true Burgers vector of each dislocation.

Another possibility is to consider the lattice orientation that has been assigned to the crystal by the DXA. It can be used to detect symmetry flips and transform the crystal orientation (and with it the Burgers vectors of all embedded dislocations) to a specific orientation that you specify. Then you could directly work with the true Burgers vectors of the dislocations. However, this approach is probably more complicated and requires functions from Ovito's Python interface that are not documented. I would have to give you more information about this.

-Alex

38
Support Forum / Re: The DXA misjudges the burgers vector
« on: April 17, 2019, 07:39:45 AM »
Dear Peter,

This surprising behavior is not a bug in the DXA and can be explained as follows:

You are dealing with a BCC crystal. Every cubic crystal lattice has 24 equivalent orientations. Thus, given a crystal model that has some orientation in space, you have 24 different ways of defining the axis orientations of the crystal, i.e., the spatial directions of the [100], [010] and [001] Miller indices.

When the DXA sees your input crystal, it will pick one of these 24 physically equivalent rotations at random. It's important to note that the algorithm newly picks the orientation in each simulation frame in an uncorrelated manner, because it doesn't remember which orientation it has used for the previous frame.

So what you are observing is a flipping of the crystal lattice orientation to a different symmetrically equivalent orientation. Even though the dislocation doesn't change in any, the Burgers vector displayed by the DXA apparently does, because it gets expressed in a newly oriented lattice coordinate system.

The column "Spatial Burgers vector" shows that the physical Burgers vector, which is obtained by transforming the calculated true Burgers vector from the lattice coordinate system to the simulation coordinate system, indeed does not change. [2.4739,0.00,0.00] and [2.4739,0.00,-0.00] are essentially the same spatial vector --small numerical errors aside that typically occur due to elastic distortions of the crystal.

The dislocation line changes color, because you selected to color the lines "by Burgers vector" and not "by dislocation type". In the latter mode, the line would probably stay green, because 1/2[111] and 1/2[11-1] belong to the same class of dislocations.

Note that the spurious flipping of the crystal orientation only occurs for certain alignments of the crystal lattice, like in your particular case where the <111> direction is aligned along the y-axis of the simulation coordinate system. For the DXA, this orientation is right on the edge of a standard orientation triangle. So even an infinitesimal reorientation of the crystal into an adjacent standard triangle, which is associated with a symmetry flip of the lattice. Other orientations, which are located more in the interior of the standard triangle, won't show this unstable behavior and DXA will typically maintain the same orientation over time.

-Alex

39
Hi Liam,

It is okay to lower the probe sphere parameter somewhat below the recommended value. However, be aware that the surface construction is not made to detect very small voids. With 'small' I mean a size on the order of one or two vacancies (note that vacancies can easily form during dislocation plasticity). If you lower the probe sphere radius, at some point the algorithm may start to detect holes in the material that are actually single vacancies or a pair of them. However, whether it detects them or not will depend on the details of the local atomic configuration, thermal displacements, elastic strains, etc. Sometimes you will be lucky, sometimes not. In other words, it's not really a good analysis tool in this size regime.

I would crosscheck whether the defects marked by the Construct Surface Mesh algorithm are indeed voids. Use, for example, the Polyhedral Template Matching function in combination with Select Type and Delete Selected modifiers to filter out all perfect FCC atoms. Then inspect the local defect configurations around the "void" identified by the Construct Surface Mesh modifier to see how big they actually are in terms of missing atoms.

-Alex

40
Support Forum / Re: VGL Error
« on: March 28, 2019, 11:34:03 AM »
Hi,

Ovito has been based on Qt5 from the very beginning. Ovito 2.9.0 was using version 5.7 of the Qt libraries, the new Ovito 3.0.0 builds for Linux use Qt 5.9.

I'm not an expert for this, but yes, the error message seems to suggest that the system libraries on the host machine are outdated and would need to be replaced with a newer version in order to run Ovito through the VNC connection. If that is also the conclusion of the sys admins, then there probably isn't an easy way out, sorry.

-Alex

41
I have made a new development build of Ovito 3.0.0 available which shoudn't show the blank main window on macOS 10.14.4:

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

Please note that the (unrelated) error message "This file has been written by ovito 2.9.0 and ovito 3.x cannot read it anymore." means exactly that: Because the internal data structures of Ovito 3.0.0 have changed dramatically, it is not possible to open old .ovito files with the new program version. You will either have to recreate the visualization with Ovito 3.0.0 from scratch, or stick to the old release.

Let us know if you experience any problems with the new build.

-Alex

42
Support Forum / Re: the unit of dislocation length in DXA analysis
« on: March 25, 2019, 02:03:57 PM »
Hi June,

Ovito, including the DXA function, does not use any particular units of length. It operates with those units in which the data are given that you loaded into the program. So, if atomic coordinates are given in Angstroms, then the DXA will yield dislocation line lengths in Angstroms as well.

-Alex

43
Support Forum / Re: OVITO Crashes when Loading File
« on: March 25, 2019, 01:59:18 PM »
Hi Egor,

No, we haven't tested the GSD file reader of Ovito with files of that size. I just run a few test with much smaller datasets when I developed the code.

How many frames and how many particles does your GSD file contain?

-Alex

44
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

45
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

46
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

47
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

48
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

49
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

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

51
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

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

53
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).

54
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

55
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

56
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

57
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

58
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

59
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

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

Pages: 1 [2] 3 4 ... 21