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 ... 28
16
The bug was reported earlier here:

https://gitlab.com/stuko/ovito/issues/91

17
Dear Zhen,

I think the problem you describe is a bug that was present only in that particular development build of OVITO (3.0.0-dev185). It should be gone in more recent dev builds, which you can download from the ovito.org website.

-Alex

18
Support Forum / Re: Is there a way to make bonds transparent?
« on: June 13, 2018, 11:51:39 AM »
Dan, Jérôme,

Please excuse my long silence in this matter.

The answer is negative: Support for semi-transparent bonds is lacking in OVITO. It hasn't been implemented yet, mostly because it would require a more complex OpenGL rendering pipeline and the resulting visual quality would not be as expected, because bond cylinders typically intersect with the particle spheres.

I have now created an official feature request for this. Maybe I can find time in the future to add support for semi-transparent bonds:

https://gitlab.com/stuko/ovito/issues/100

I cannot really think of a good workaround. Perhaps, in some cases, it is possible to render the particle/bond system fully opaque using OVITO and then superimpose the image on a background using a photo-editing software and make it semi-transparent. Not really a great solution, I know...

-Alex

19
Support Forum / Re: Question about Voronoi calculation
« on: June 08, 2018, 11:52:13 PM »
Dear Shuai,

I suspect you are trying to run this script using Ovito 3.0.0-dev. Is that right? The example code you took from the website is for the stable release 2.9.0. The current development release 3.0.0-dev is not 100% backward-compatible, because the Python programming interface did slightly change.

An updated version of the Voronoi analysis script for Ovito 3.0.0-dev is included with the new documentation that gets installed along with the program and which can also be found online:

http://ovito.org/manual_testing/python/introduction/examples.html#example-compute-voronoi-indices

-Alex

20
Support Forum / Re: The ImportError: cannot import name 'DataObject'
« on: June 08, 2018, 07:10:13 AM »
Hi Shuai,

This error is quite unusual and could be the result of a broken installation.
 
Which program version of Ovito did you install? Note that, for Windows, there also exists a zip archive with the program, which can be downloaded form the ovito.org website. This archive can be extracted in any location on your computer without installation. Maybe you want to try this one again.

-Alex

P.S.: It's not guaranteed that Ovito will work when you install it over an older installation in the same directory. It's currently recommend to remove the old version first before installing the new one.

21
Support Forum / Re: rotation single frame
« on: June 06, 2018, 07:39:04 PM »
1) The animated object will always rotate around its origin, i.e. (0,0,0) in the simulation coordinate system. But note that you can make use of the Affine Transformation modifier to shift all particles and the simulation cell by an arbitrary translation vector. With that, you can adjust the (apparent) center of rotation.

2) I'm not sure what you mean with that. My instructions were based on the assumption that you have loaded exactly one static simulation frame and that you have used the animation settings dialog to set the length of the animation to N animation frames (N>1). So what kind of frame do you mean when you ask how to make a movie using one "frame"? And yes: The idea is to set the rotation angle of the object to 0 degrees at animation frame 0, and to 360 degrees at the last animation frame. The program should interpolate between the two values.

If you think you did something wrong, and don't know what it is, please save the scene to an .ovito file and uploaded it here. I will take a look.

22
Support Forum / Re: Regarding atomic strain modification
« on: June 06, 2018, 11:20:35 AM »
With "strain tensors" you mean the 6 individual components of the atomic strain tensor (in 3d), right?

OVITO should have computed those tensor components given that you did not disable the Atomic Strain modifier, the "Output strain tensors" option of the modifier has been activated, and there is no error message being displayed by the modifier. Note that the Stress Tensor particle property may not be visible in selection box of the Color Coding panel while the Atomic Strain modifier is still computing its results.

Also note that, by default, the Atomic Strain modifier outputs only the Shear Strain property for each atom. You need to activate the "Output strain tensors" option in order to get all 6 strain components (3 of which will be zero in case of a 2d system).

23
Support Forum / Re: Regarding atomic strain modification
« on: June 05, 2018, 05:14:17 PM »
Thanks. I tested it myself and it worked as expected. Here is what I did:

1. Load the file dumpf.dat in OVITO.
2. In the "XYZ" panel, activate the option "File contains time series"
3. Go to the 'Simulation cell' panel and activate the 2D mode.
4. Insert Atomic Strain modifier, set "cutoff radius" parameter to a value of 3.0
5. Scroll down to "Reference: External file" panel and use the "Pick new file" tool button to load the reference configuration (dump_initial positions.dat).

24
Support Forum / Re: Regarding atomic strain modification
« on: June 05, 2018, 03:34:10 PM »
I didn't really check if the atomic strain calculation works, because you did attach only a single dump file ("dump_initial positions.dat") in your first post. Is there a deformed configuration that you can upload as well?

And please let us know which OVITO program release you are using. There are some subtle differences between the versions.

25
Support Forum / Re: grain boundary movement?
« on: June 05, 2018, 02:54:53 PM »
Hi,

OVITO doesn't have a function for identifying grains and grain boundaries yet. But this is a subject of ongoing research. In the meantime, perhaps this code is of interest to you:

http://rupert.eng.uci.edu/modeling.html

-Alex

26
Support Forum / Re: Regarding atomic strain modification
« on: June 05, 2018, 01:39:08 PM »
Dear Bahman,

The error message occurs because the strain calculation function thinks that the simulation cell has no (3d) volume.
When loading a XYZ file, OVITO cannot automatically detect whether it is a 3d or 2d domain. For 2d systems, you may have to explicitly activate 2d mode as indicated in the attached screenshot to avoid the error message.

-Alex

27
Support Forum / Re: A question about ' common neighbor analysis'
« on: June 05, 2018, 01:29:57 PM »
Your input file seems to be wrong. The simulation cell, which is visible in the last screenshot you posted, is much too small.

Normally, all particles should be positioned inside the periodic simulation cell, but in your case most of the particles are located outside. Note that the CNA calculation needs the simulation cell information in order to correctly implement periodic boundary conditions. Without the correct size information of the periodic domain, the calculation will yield wrong results (typically, the lattice structure cannot be identified correctly, because the periodic images of the crystal do not fit together).

28
Yes, you are right, slicing of dislocations has only an apparent effect on the visualisation of the lines. It doesn't actually remove the lines outside of the cutting region. This is unlike atoms, which actually get deleted by the Slice modifier.

The technical background is this: dislocation lines are extended objects that live in a periodic domain (when PBCs are used). Cutting and slicing typically doesn't make sense within that periodic domain, because there exists an infinite number of periodic images of the same object but only a single cutting plane. To resolve this ambiguity, cutting along the plane happens after a non-periodic version of dislocation lines has been produced by the program for visualisation purposes. This non-periodic version of the dislocation lines, in which lines crossing a periodic boundary are cut into multiple pieces, represents a transient configuration which is not visible to modifiers in the data pipeline or to Python scripts accessing the dislocation data.

The only way to access the transient state, i.e. the non-periodic and sliced dislocation lines, is by exporting the lines to a "VTK Dislocation Lines File". This export format is available in the current development version (3.0.0-dev200) of OVITO but not in version 2.9.0. Note that the "CA" export format always stores the periodic (and not yet sliced) version of the dislocation lines.

I'm afraid at the moment there is no other way to accomplish your goal. You need to export the lines to series of VTK files, slice by slice, then read in these files again (using a custom Python script, ParaView or the VTK programming framework) and compute the total line lengths yourself.

-Alex

29
Support Forum / Re: Colouring of atoms
« on: June 04, 2018, 04:02:34 PM »
I see. The automatic mapping only works for other file formats. The LAMMPS dump file parser of OVITO doesn't perform the mapping automatically, mainly because LAMMPS doesn't typically write out any color information. Maybe I can change that behaviour in a future version of OVITO if needed.

There are several workarounds which you can use in the meantime:

The Compute Property modifier of OVITO allows you to copy the values from the color.r, color.g and color.b properties over to the standard Color particle property. You can insert an instance of this modifier at program startup from the command line by using a Python script command:

Code: [Select]
ovito --exec "import ovito.modifiers; ovito.dataset.selected_node.modifiers.append(ovito.modifiers.ComputePropertyModifier(output_property='Color', expressions=['color.r','color.g','color.b']));" inputfile.dump

Or you save a preconfigured Compute Property modifier as a modifier preset for quick access within OVITO.

Alternatively, you can use a script command at program startup to import the LAMMPS dump file, override the default behavior and explicitly specify the column mapping:

Code: [Select]
ovito --exec "from ovito.io import import_file; import_file('inputfile.dump', columns=['Particle Identifier','Particle Type','Position.X','Position.Y','Position.Z','Force.X','Force.Y','Force.Z','Color.R','Color.G','Color.B']).add_to_scene();"

30
Support Forum / Re: Colouring of atoms
« on: June 03, 2018, 05:21:07 PM »
There is no need to use the Color Coding modifier. The purpose of this modifier is to map a scalar particle property to an RGB triplet. But in your case you already have the triplet.

Property names are case-sensitive in OVITO. Only if a property is named "Color" and has three vector components, then OVITO will use the stored values to color the particles during visualization. If the property is named "color", then it will treated as a user-defined property by the program with no further meaning. OVITO will not use its values when rendering the particles.

Please adjust the naming of the columns in the input file accordingly. If you need help with that, please post the header of the input file. I am still not sure what kind of file format you are dealing with.

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