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 5 ... 16
31
So far I was not able to reproduce the problem under Windows with the current development version Ovito 3.0.0-dev52. I didn't have the chance yet to test v2.9.0.

If you have a dump file that raises the error and is not too large, please post it here.

32
Support Forum / Re: Problem with remote file loading
« on: November 20, 2017, 07:09:54 PM »
Dear Jérôme,

I tried to find out more about this error online, but this doesn't seem to be a common problem. There are two possible explanations: (1) the SSH server is not properly configured, or (2) there is a compatibility problem between the SSH/SFTP client library used by OVITO and the SSH server.

I know that OVITO's built-in SSH client has some limitations, in particular with regard to the key encryption methods it supports. However, this particular type of error message has not been reported before. So it is entirely possible that the problem lies on the server side. FileZilla might be smarter and can work around the problem, or it using another protocol.

Unfortunately there is not much I can do from here. I am by no means an expert for SSH client/server communications and the SFTP protocol. The third-party code library used by OVITO for remote file transfer hasn't been updated for some time now and is not really well supported. But it is the only solution currently available. If the remote access doesn't work for you, you might be forced to copy your files to the local computer first before you can open them in OVITO.

-Alex

33
Support Forum / Re: creating and manipulating geometry
« on: November 20, 2017, 03:42:36 PM »
I do have plans to extend Ovito in this direction, but given the limited spare time I have available for the development, these plans have only low priority at the moment. Steps in this direction will be contingent upon our ability to secure funding for further development of the software.

Currently, Ovito can only analyze and manipulate existing particle configurations. Here is a rough roadmap I have in my mind for extending Ovito's capabilities toward the creation of new configurations:
  • Possibility to write user-defined modifiers in Python that can manipulate an existing system and add new particles to it (works already)
  • Support for user-defined Python functions that can generate entirely new particle datasets from scratch and which can act as sources for data modification pipelines in Ovito
  • Integrating LAMMPS as an engine into Ovito, visualizing a live view of the LAMMPS simulation. This will make it possible to use LAMMPS scripting within Ovito as a means to generate simulation setups. Here, Ovito mainly provides an environment for rapid prototyping and testing of LAMMPS scripts.
  • Adding functions to Ovito for the interactive creation and manipulation of particle configurations (e.g. a "crystal builder").

You are invited to post your own ideas. What would be most useful functions for manipulating and creating atomic configurations? And how should they be made available to the user?

34
That's surprising. Which program package version are you using? Is it the same version on Linux and Windows?

35
Support Forum / Re: charge atom indexation ends on 99999
« on: November 17, 2017, 02:24:39 PM »
By the way:

You can fix the problem of wrong particle identifiers by assigning new IDs within OVITO: Simply use the Compute Property modifier to set the 'Particle Identifier' property. Enter "ParticleIndex+1" as expression. After that you should be able to export the dataset to a valid LAMMPS data file.

36
Support Forum / Re: charge atom indexation ends on 99999
« on: November 17, 2017, 02:18:03 PM »
Thanks. I checked the PDB file in a text editor: Atom serial number in the second file column run from 1 to 99999. After that, the serial number is replaced by the string '******'. OVITO converted that string to the number 0. That's why particle identifier run only from 0 to 99,999 after file import in OVITO.

I now changed the file parer code and added a special handling of the ***** case. It's be available in the next development version of OVITO.

Can you please say something about the origin of that PDB file? Which code was used to produce it? Source that I find only all say that the legacy PDB format cannot store more than 99,999 atoms and any dataset with more atoms needs to be split into multiple files then.

37
Support Forum / Re: Void in amorphous material
« on: November 17, 2017, 11:41:52 AM »
Hi,

there are two approaches that come to my mind:

(1) You can use OVITO's Voronoi Analysis function to compute the atomic volume. The volume per atom can be taken as a local measure of the density. Note that it might be necessary to flatten out local fluctuations. This can be done using the Compute Property modifier or the Bin and Reduce modifier.

(2) The Construct Surface Mesh modifier allows you to reconstruct the outer and inner surfaces of a solid. Hence, it can be used to identify pores in a material. Here, the probe sphere radius parameter of the modifier controls the minimum size of the pores to be identified.

38
Support Forum / Re: charge atom indexation ends on 99999
« on: November 16, 2017, 06:00:26 PM »
Hi,

This sounds as if there is a problem in the PDB file parser in OVITO, which I wrote. I have no personal experience with the PDB format and I simply tried to follow the official format specification:

http://www.wwpdb.org/documentation/file-format-content/format33/sect9.html#ATOM

I was under the impression that atom IDs can only be 5 digits long, meaning that the PDB format can store only up to 99999 atoms. What you write suggests that my assumption was wrong.

Please post your PDB file here. I will try to fix the problem in OVITO.

-Alex

39
Support Forum / Re: rendering problem
« on: November 16, 2017, 12:31:44 PM »
I meant the "override usage of point sprites" setting and the "override usage of geometry shaders" setting in the application settings dialog.

Here is another thing you can try: Set the rendering quality for particles to "low". This is done in the parameter panel for the "Display"/"Particles" entry in the pipeline editor:

http://ovito.org/manual/display_objects.particles.html

The final workaround I can recommend, of course, is to use the Tachyon renderer instead of the OpenGL renderer to produce image frames.

40
Support Forum / Re: Applying conventional CNA
« on: November 15, 2017, 07:51:48 AM »
OVITO has originally been designed for simulation datasets with typical inter-particle distances on the order of 1 unit of length, because most molecular dynamics simulations use Angstroms as units. The neighbor list builder in OVITO refuses your dataset, because its internal threshold for the box volume is set too large. A box with volume ~1e-15 m^3 is currently considered degenerate. The cutoff radius parameter has no influence on this as the volume threshold is hardcoded.

I will see if I can make changes to the source code to better prepare OVITO for simulations that use SI units. Other analysis and visualization functions of OVITO might suffer from similar limitations at the moment. Perhaps you have a typical simulation data file for me as a test case.

For the time being you should be able to work around the problem by rescaling the dataset. You can do this within OVITO by applying the Affine Transformation modifier. Set the three diagonal elements of the matrix to 1e6 or so to scale up the entire box and its contents.

After that, the CNA analysis modifier should work. BTW: If you just want to color particles according to their coordination numbers, you can do so using the Coordination Analysis modifier followed by a Color Coding modifier. The CNA modifier is more appropriate though if you want to detect structural order in your system, like you said.

41
Support Forum / Re: rendering problem
« on: November 14, 2017, 09:11:02 AM »
This rendering bug is likely due to a nonconforming OpenGL graphics driver installed on your system. Please post the system report generated by OVITO when you chose "OpenGL information" from the Help menu.

You may be able to work around the graphics driver bug by changing some of the OpenGL-related settings in OVITO's application settings dialog (found under the 'General' tab).

42
Support Forum / Re: PTM analysis - orientation of reference templates
« on: November 13, 2017, 08:21:03 AM »
Carolina,

I have received a reply from Peter and need to correct myself:

The template neighbor vectors for the HCP structure are found in line 92 of the source file https://gitlab.com/stuko/ovito/blob/master/src/3rdparty/ptm/index_ptm.h
Orientations computed by the PTM modifier are relative to this (fairly arbitrary) reference orientation.

43
Thanks for the instructions how to reproduce the crash. They were helpful.

I was able to reproduce the error and I think I was able to fix it. The maximum number of recursions in the Tachyon raytracer was set too high, leading to a stack overflow at runtime when there are a many semi-transparent objects in the scene. I have reduced this limit from 1000 recursions to 50, without notable differences in the generated image. Now it seems to work without problems. The change is included in ovito-3.0.0-dev54 (macOS version now available on the website).

44
Support Forum / Re: Extract Nye's tensor component from Ovito
« on: November 12, 2017, 06:29:21 PM »
My apologies, this time it wasn't your fault. The last (and essential) code line was missing from the old version of the Python documentation. Here is the current version of the manual, where the error has been fixed:

https://ovito.org/manual_testing/python/introduction/examples.html#example-visualize-local-lattice-orientation

45
Support Forum / Re: Extract Nye's tensor component from Ovito
« on: November 11, 2017, 08:24:50 PM »
Hi Anuj,

1)

Both the Elastic Strain Calculation and the PTM modifier can compute the atomic elastic deformation gradient tensor F. This is, if I remember correctly, the inverse-transpose of the lattice correspondence tensor G mentioned in the original publication of Hartley and Mishin [Acta Materialia 53 (2005) 1313]. The Nye tensor is the negative curl of this G tensor, which must be calculated using a finite differences scheme. OVITO doesn't do this last step for you, sorry.   

2)

I think you didn't copy/paste the complete script from the example page. The implementation of the modify() function in your screenshot is obviously incomplete.

-Alex

Pages: 1 2 [3] 4 5 ... 16