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 ... 17 18 [19] 20 21 ... 32
Support Forum / Re: Filtering defects by time or frame sequence
« on: November 23, 2017, 09:48:10 AM »
I don't have a clear picture of situation and can give you only general advice..

Typically, one would use a coordination-based criterion to filter out such spurious atoms. For example, you can employ the Compute Property modifier to count how many neighbors within given cutoff range of each new defect atom belonged to the initial defects. This information can then be used to select certain atoms, e.g. those which are close one of the initial defects, with the Expression Select modifier and remove them.

Support Forum / Re: Reading data file without x y z in ITEM line.
« on: November 22, 2017, 02:08:36 PM »
Hi Zhu,

Yes, OVITO will first complain about the missing x y z columns in the dump file, but after that you can specify a custom mapping of file columns to the xyz position property. Press the "Edit column mapping" button as shown in the attached screenshot. Then make sure that the f_ave[1/2/3] file columns are mapped to the Posiition.X/Y/Z particle property.


Support Forum / Re: Filtering defects by time or frame sequence
« on: November 21, 2017, 11:22:44 PM »

If we focus on the point defects for the moment, I suggest to use Freeze Property modifier for that. Here is what I have in mind:

First, you identify the atoms that form point defects in the very first simulation frame and select them. You then apply the Freeze Property modifier to "freeze in" the Selection particle property so that it doesn't change anymore even if new defects are created at later frames. You can now highlight this static selection of atoms using the Assign Color modifier. It might make sense to insert a Compute Property to dynamically modify the atom selection and restrict it to just those atoms which were selected in the first frame and which are still defects in the current frame.

Dislocation line defects identified via DXA are a different story. I'm not sure how to do it here. It is possible, at least in principle, to save the dislocations found in the first frame and overlay them with the defects dynamically identified in later frames. However, those dislocation will then appear twice. The problem is that dislocations do not have a unique identity and unlike atoms they cannot be tracked over time.


I was now able to reproduce the file parsing error. It looks like the system function for floating-point number parsing behaves differently on Windows (or the Microsoft C++ compiler). The system's locale might play a role as well if it is set to a non-english language, but I'm not sure.

In any case, it doesn't seem to be an issue anymore in the new 3.0 version of OVITO, which uses double precision numbers internally. The error only occurred in the 2.9.0 version, which uses single precision floating-point numbers internally, which cannot represent very small numbers like 1e-205.

Please switch to the current development version if you want to get rid of the error.

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.

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.


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?

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

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.

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.

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

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.

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

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:

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.


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:

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

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.

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

Pages: 1 ... 17 18 [19] 20 21 ... 32