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 ... 27
226
Christophe,

I'm sorry, but I now noticed that there was a mistake. As it turned out, the dev46 version double precision computations were not enabled in the dev46 build. I didn't immediately notice it, because my Linux virtual machine only allows me to build the Ovito executable but not run it.

Not surprising then, of course, that your measurements didn't show any significant deviations from the dev39 build. I'm sorry for having wasted some of your time here. If you still have the chance, it would be nice if you could run the benchmark again with the dev52 build. It has double precision calculations enabled (see OpenGL information dialog, accessible from the help menu).

-Alex

227
Hi Jer,

Ovito doesn't have a built-in function for calculating the Warren-Cowley SRO, but it should not be too difficult to implement the calculation as a user-defined Python script modifier.

I would first use the Create Bonds modifier of OVITO to build a list of nearest neighbour bonds. Then all the user-defined analysis script would have to do is iterate over the bond list and do the counting of bond types.

I don't have such a script immediately ready for you. But I could support you as needed in writing it.

-Alex

228
Support Forum / Re: group/group force calculate
« on: October 28, 2017, 01:11:39 PM »
Dear Mostofa,

It's not clear to me what you are after. For instance, how are the groups of 8 atoms supposed to look like?

But more importantly, note that OVITO cannot perform any force calculations. That is because OVITO doesn't know anything about the interactions between atoms. For that kind of calculation you need an MD simulation code such as LAMMPS. OVITO is only able to perform structural or kinematic types of analyses.

229
Support Forum / Re: Compute Property Question
« on: October 27, 2017, 12:03:08 PM »
Thanks. I was able to reproduce the problem. But I now think that is not related to your particular dataset or the fact that your simulation cell is sheared.

The problem is the large cutoff radius. As soon as it is larger than half the periodic box size (in your case the cell size along the z-axis), the relative displacements vectors calculated by the atomic strain algorithm turn out wrong. The reason is some sort of ambiguity and/or the minimum PBC image convention.

I am still trying to figure out whether that ambiguity can be resolved or not. For the time being, I suggest you use a smaller cutoff radius. In any case, there is not really a point in using a cutoff distance which is on the order of the simulation cell size. Only smaller cutoffs, typically on the order of a few interatomic distances, will give you spatially resolved strain information.

230
Support Forum / Re: Data from Polyhedral Template Matching
« on: October 25, 2017, 01:51:17 PM »
Note that Voronoi cells of particles can be classified by the PTM as 'Other' for two reasons:

  • The point-to-point correspondence cannot be established for any of the reference structures
  • It can be established for at least one reference crystal structure, but the resulting RMSD value (i.e. the structural deviation) is too large and exceeds the RMSD threshold value set by the user

The latter only applies if a non-zero RMSD threshold has been set. I assume your question pertains to the second case, where a point-to-point correspondence exists.

Currently, this intermediate information is not exposed by the algorithm and is not accessible by the user. You would have to touch the C++ code of OVITO to access the point-to-point mapping. If you are willing to do some code development, an alternative is to contact Peter Larsen, the author of the PTM method. He has made a C++ PTM code library available (same one used by OVITO), which you could work with.

231
Support Forum / Re: OVITO opens with black window only
« on: October 25, 2017, 01:40:30 PM »
I don't think this issue is in any way related to the path OVITO is installed in. Typically, a black window like this is a sign for graphics system problem.

Please check if your graphics driver is installed correctly. Sometimes reinstalling it can solve such a problem. Sometimes simply restarting the computer may help as well (because the Linux system packages are being automatically updated in the background, which can temporarily put the OpenGL graphics system into a non-working state).

Please also check whether other OpenGL-based programs work correctly or not. It may be a system-wide issue. For example, you can start the "glxgears" test program, which comes with most Linux distributions, from the terminal.

That being said, let me also answer your question:

OVITO stores its application settings in the config file $HOME/.config/Ovito/Ovito.conf under Linux. You can delete this file to reset OVITO into its default state.

232
Support Forum / Re: Compute Property Question
« on: October 25, 2017, 12:27:47 PM »
Your table shows that the results are correct for smaller cutoff radii but appear to be incorrect for large cutoff radii (cutoff on the order of the simulation cell size).

I can think of two possible sources for this error:

  • The atom neighbor lists generated by OVITO for the non-orthogonal (sheared) simulation cell are wrong and lead to incorrect strain calculation results
  • Or the minimum image convention used in the strain calculation routine leads to wrong results

I would like to investigate this issue further (and hopefully solve it). For that, it would be helpful if you could send/upload your simulation file. Just the first frame should be enough.
Thanks.

233
Support Forum / Re: Compute Property Question
« on: October 24, 2017, 09:57:55 PM »
Yes, if the reference configuration is the same as the current configuration, then the (shear) strain values should be virtually zero for all atoms.

You are saying that this was indeed the case for the first simulation you analysed, but for some reason it is not the case for the second simulation (with the sheared simulation cell).

From what you wrote and the screenshots I cannot tell what went wrong. It might be necessary that you also upload the original data files so that we can reproduce the problem.

There is a typical source of error that can lead to unusually large strain values. Please check if it applies to your case:

For the atomic strain calculation the displacement of each atom needs to be computed. This requires that each atom has a unique identity so that its motion can be tracked over time. LAMMPS (assuming that is the MD code you use) tends to reorder atoms from time to time during a simulation. If you didn't write out the atomic IDs to the dump file, then OVITO might create a wrong mapping between the atoms in the current and the reference configuration. The computed atomic displacements and strains will then come out wrong.

However, this problem can only arise if the current and the reference configuration are not loaded from one and the same file. If it is the same file, then we'll have to look for other explanations. Did you check if the value of the Cutoff Radius parameter or the Eliminate Homogeneous Cell Deformation option have any influence on the computed strain values?

Best,
Alex

234
Support Forum / Re: Compute Property Question
« on: October 23, 2017, 05:22:41 PM »
Yes, the scalar "Shear strain" property, which is output by the Atomic Strain modifier of OVITO, is computed according to equation 7 in the book chapter.

235
Support Forum / Re: Compute Property Question
« on: October 21, 2017, 05:39:34 PM »
The atomic strain calculation is a little more elaborate than comparing average bond lengths. First, an atomic deformation gradient tensor is calculated, from which the atomic strain tensor and finally the volumetric and shear strain values are derived.

You can find technical details in the OVITO user manual and in section 3.2 of the attached document.

236
Great. Thanks for the quick effort.
Looks like the extra costs of double-precision computations are negligible. That's good news.

237
In the latest dev build of OVITO I have switched from single-precision to double-precision numbers as default floating-point data type. All calculations will now be performed with double precision in OVITO and the memory footprint becomes larger.

I would be interested in determining how that affects performance. If you have the time, it would be great if you could redo the benchmark run with the newest OVITO build to see if there is any measurable effect.

238
Support Forum / Re: segmentation fault
« on: October 20, 2017, 09:09:58 AM »
The log certainly shows that my instructions for turning off the network access during program startup did not work for some reason. If you have access to another macOS computer with a working Ovito installation, you can test whether the changes to the .plist settings file take effect. The updates.check_for_updates key in the settings file controls the user option "Auto-refresh news page from web server" in the Ovito application settings dialog. So setting it to false should uncheck the corresponding check box and vice versa.

I uploaded a new dev build of Ovito (3.0.0-dev46) yesterday. The macOS binary is build against the latest version of the Qt library (5.9.2). If you have the time, please try if that makes any difference.

239
Support Forum / Re: segmentation fault
« on: October 19, 2017, 07:11:59 PM »
This is surprising. Did you check if the program crash really is due to the same error as jjmolina reported above?

After the Ovito app crashes, a system dialog should appear. Click the "Report" button to see the error log. It should be similar to jjmolina's: 

Code: [Select]
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   org.qt-project.QtNetwork      0x000000010b5c4425 0x10b525000 + 652325
1   com.apple.CFNetwork            0x00007fffad35f5c4 PAC::PACClient::invokeClientCallback() + 102
2   com.apple.CoreFoundation      0x00007fffae0bd321 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17

If it's different, please post the error log here.

240
Support Forum / Re: Compute Property Question
« on: October 19, 2017, 01:14:08 PM »
Dear Debasis,

Yes, you are right: The Compute Property modifier stores the computed values as a new particle property which is non-visual at first. There are various ways to make that data visible.

For a vector property such as "Displacement", Ovito can render an arrow for each particle in the viewports. For this, you need to check the box next to the "Displacement" entry under the "Display" section of the pipeline editor. See the attached screenshot.

Another option to make property data visible is to use the Color Coding modifier to translate a scalar property (e.g. "Shear Strain" computed by the Atomic Strain modifier) into a particle color. So if you add this modifier to the pipeline, particles will be assigned a color based on the value of the selected particle property.

-Alex

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