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 ... 14 15 [16] 17 18 ... 31
Support Forum / Re: Python script for cluster size
« on: January 22, 2018, 07:21:01 PM »
Is this the entire script code? It surprises me that the initial script version was failing with an error message in the numpy.savetxt() line, but now the corrected script, which doesn't generate the permission-denied error anymore, doesn't produce any file output. I cannot imagine that it gets stuck inside the savetxt() function.

How are you running this script? Are you using the "Run Script file" function form the menu (which would be correct), or are you running this in the context of a Python script modifier (which would be wrong)?

Support Forum / Re: Atomic Strain tensor
« on: January 22, 2018, 06:58:50 PM »
What concerns me is that you conducted this analysis in 3d-mode. For a true 2d-system like a graphene sheet, which is exactly planar in the undeformed configuration (I assume), the strain tensor calculation in 3d-mode will yield in unpredictable results --or an error message if you are lucky.

The reason is that you cannot calculate a 3x3 deformation gradient from a 2d-system where all atomic z-coordinates are zero. Tensor components such as F_zz, which involve the derivate of the displacement field with respect to the z-coordinate, remain undefined in this case. The implementation should catch this kind of degenerate situation, but it might not always be able to do so due to numerical errors. If that happens, tensor components like F_zz may take on arbitrary values. Consequently, the strain tensor E calculated from F will also be arbitrary (all of its components, not just the ones involving z-coordinates).

Have you tried doing this calculation in 2d-mode? You can switch to 2d-mode in the properties panel of the simulation cell. In 2d-mode, OVITO does not try to calculate the z-coordinate elements of the F tensor. Instead, they are set to fixed values assuming a plane strain situation.

If you can, please also post the simulation files for the initial and deformed configurations. Then I can take a look at the displacements of the atoms myself and check the strain calculation. I particularly would like to know if there are any out-of-plane displacements.

Support Forum / Re: Python script for cluster size
« on: January 22, 2018, 06:34:50 PM »
Since you are working under Windows, the current working directory while you are running this script in Ovito is probably "C:\Program Files\Ovito\".
That means the call to numpy.savetxt("Cluster3.txt") will try to write to the output path "C:\Program Files\Ovito\Cluster3.txt", which probably refers to a write-protected location. The file I/O operation fails.

The solution is to specify an absolute output path by prepending the destination directory to the file name:

output_filepath = path + "\\Cluster3.txt"

Support Forum / Re: Computing Per-atom Change
« on: January 22, 2018, 08:15:55 AM »
Dear Farheen,

In this case, the Freeze Property modifier is your friend. Please see the "Example 2" on this page. It should answer your question.


Support Forum / Re: Atomic Strain tensor
« on: January 22, 2018, 08:11:24 AM »

Yes, this a strange result indeed. Is this calculation done in 2d-mode in OVITO? If so, how did you implement the plane strain calculation? In OVITO, particular elements of the V and W matrices are set to special values at some point of the calculation and then OVITO continues as if the problem where 3d (see source code).

And did you also compare the atomic deformation gradient with your solution? The def gradient is an intermediate calculation results and could help locate the source for this deviation.


Support Forum / Re: rotation single frame
« on: January 19, 2018, 08:35:53 AM »
Hi Enrique,

Yes, all you need to know about this is described on this page:

Here is an overview of the steps:

  • Open the Animation Settings dialog and set the desired animation length
  • Activate Auto-Key mode
  • Go to the last animation frame
  • Activate the Rotation tool in the upper toolbar and enter a rotation angle of 360° into the z-axis axis input field that appears below the viewports.
  • That's it, the selected object should now perform a 360° rotation. You can deactivate Auto-Key mode again

Support Forum / Re: DXA for molecular crystals
« on: January 18, 2018, 06:33:02 PM »
Yes, as long as the representative points form one of the currently supported lattice types. That is fcc, bcc, hcp, cubic diamond and hexagonal diamond.

Support Forum / Re: DXA for molecular crystals
« on: January 18, 2018, 05:11:11 PM »
Hi Debasis,

No, the algorithm doesn't support this kind of scenario at the moment. But couldn't you replace each molecule with a single particle (like its center of mass) and then feed this to the DXA? What kind of crystal lattice do the molecules form?


Support Forum / Re: What's the default radius for atom
« on: January 14, 2018, 12:41:49 PM »
Dear Justin,

The default atom radii of OVITO are predefined in this source file. The radius values match those used by the VESTA software. Here, the radii/colors are defined in the file elements.ini that is part of the VESTA distribution. It's likely that OVITO's defaults were taken from there.

However, it's still unclear what the physical meaning of these radius values is. I'm not sure, I must admit.

If you have the feeling that these default values are not reasonable or should be replaced with something better, please let me know. I would be willing to replace them if it makes sense.


Thank you for the suggestion. I extended the user manual to describe how and where OVITO keeps its configuration data:

Support Forum / Re: cannot construct mech in dislocation analysis
« on: January 04, 2018, 05:14:09 PM »
Thanks Ann, I downloaded your test file. However, I was not able to reproduce the problem on my computer. Probably, I am using other DXA parameters than you. The easiest way to exactly reproduce your settings on my local machine would be if you save your setup as an .ovito file and give that file to me. For that, first make sure OVITO is giving you the error message. Then save the scene using the File/Save program state function in the menu. Finally, upload the .ovito state file here.

Furthermore, I noticed that your simulation is periodic only in the X-Y plane, but not along the Z direction. When loading the XYZ file, OVITO assumes by default that periodic boundary conditions are used in all three directions. This may lead to problems, because the z-coordinates of some of atoms are actually outside the simulation box in your case. Please try if turning off periodic boundary conditions along Z makes any difference. You can do that in the Simulation Cell panel.

Support Forum / Re: how to display dumbbells through W-S defect analysis
« on: January 04, 2018, 04:56:44 PM »
Yes, I agree, this is an interesting question  :) I do not see that the current version of OVITO provides a solution to this problem, which others have been facing before.

Basically, the W-S modifier needs to be extended (requiring code modifications). Here is what I have in mind: We could add an option that turns off the normal behavior of the W-S modifier: Instead of replacing the current configuration with the reference configuration, the current configuration is kept. The occupancy numbers that are assigned to the individual atoms then represent the total occupancy of the sites the atoms have been assigned to. The two atoms forming a dumbbell configuration, for example, would both have Occupancy==2. Of course, in this mode it would not be possible to select vacancies, because there are no atoms occupying vacancy sites. Also, the "Output per-type occupancies" option would not make any sense in this mode.

What do you think?

In principle, it is possible to implement this algorithm using a custom "Wigner-Seitz" modifier written in Python. So if you have an urgent need for this approach, that would be the way to go. Otherwise, let me create an issue for this feature request on our GitLab site and I will try to extend the built-in W-S modifier when I find some time.

Support Forum / Re: Segmentation fault -- (Linux) OVITO 3.0.0-dev60
« on: January 04, 2018, 10:29:28 AM »
I was able to reproduce and analyze the segfault. It seems to be due to a bug (or a limitation?) in the OSPRay code. I filed a bug report to the OSPRay developers:

I will try to develop a workaround in the OVITO code for the bug.

Support Forum / Re: cannot construct mech in dislocation analysis
« on: December 27, 2017, 07:13:01 PM »
One possible explanation for this error could also be that the (periodic) simulation cell you are analysing is too small. The DXA may not be able to handle such datasets with a very short periodic length. In this case a possible workaround would be to use the "Show periodic images" modifier to replicate the crystal and increase the simulation cell size by some factor prior to applying the DXA modifier.

Support Forum / Re: cannot construct mech in dislocation analysis
« on: December 27, 2017, 07:09:47 PM »
Dear Ann,

This is an unexpected failure of the DXA routine, which should never occur under normal circumstances. If it does occur, it probably means that the DXA routine needs to be improved in some way to correctly handle your dataset.

To this end, I am asking you to upload the input dataset (at least those simulation frame(s) for which the error occurs) or send the data file(s) directly to me. I will then try to reproduce the problem and find a fix. Please do not forget to also specify the DXA modifier settings that you used, as they may affect the occurrence of the error.

As a possible workaround, I suggest you slightly perturb the atomic positions of the input dataset. For example, you could use the Affine Transformation modifier to shift all positions by some amount before applying the DXA modifier. Maybe this helps to avoid the error, but I am not certain.


Pages: 1 ... 14 15 [16] 17 18 ... 31