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 ... 21
Dear Fan Li,

You wrote that you divided the system along the z axis into bins. How exactly did you do that? Are all atoms still contained in one file? I am wondering what the difference between the divided system and the original system is.


Support Forum / Re: Changing Particle Shape Automatically
« on: Today at 06:44:02 AM »

What is the best strategy in this case depends on whether the data for the "Aspherical Shape" property should be loaded from the input file or is to be generated on the fly after loading. From the scripts you posted I read that you want to assign the same aspherical shape (0.5,2.,0.5) to all particles. Is that right?

Let's assume you want to set the aspherical shape property for all particles to the same uniform value. In this case, the Compute Property modifier is your best choice. You can use it to set the component values of the "Aspherical Shape" particle property to specific values such as 0.5, 2.0 and 0.5.

There are different ways to apply this modifier: You could do it by hand within the GUI and enter the values for the three components. But then you would have to do this every time you are loading a new simulation file. One way to simplify this step is to define a modifier preset. Then setting the aspherical shape takes just one or two clicks.

The third option is to use scripting commands. Since the Compute Property modifier is already doing the job of setting the property for you, you won't need to write a user-defined Python modifier. You only need to insert an instance of the ComputePropertyModifier into the current data pipeline.

When you run ovito (not ovitos) from the terminal with the --help command line option, you will see that it supports the --exec option, which lets you execute arbitrary Python commands after program startup. We can use it to insert the ComputePropertyModifier after the simulation file has been loaded:

Code: [Select]
ovito --exec "import ovito; from ovito.modifiers import ComputePropertyModifier; ovito.dataset.selected_node.modifiers.append(ComputePropertyModifier(output_property='Aspherical Shape', expressions=['0.5','2.0','0.5']))" <datafile>

Alternatively, you can put these script commands into a .py file and use the --script command line option to execute the script file on program startup. The effect is the same as if you would manually choose Run Script File from the menu in the GUI.


Dear Afshin,

The steps you describe sound correct. I tried the same, and it worked.  So I'm not sure what the two of us have been doing differently, or if there is a problem in OVITO.

To find out, let me start by sending you my test data files (attached). The reference configuration (config.0.poscar) is a perfect bcc crystal made of 54 atoms. The displaced configuration (config.1.poscar) is the same crystal plus one extra atom positioned somewhere. When I perform the WS analysis on this config, using the new 'Keep current configuration' option, I get exactly two atoms with Occupancy==2. The rest has Occupancy==1.

Can you tell if you have been doing something differently?

Furthermore, I am not sure if I understand your suggestion. Even with the new  'Keep current configuration' option, you won't see both configurations simultaneously. You only have the choice to either work with the reference config or the displaced config. If you really need to work with both configurations simultaneously and need to know exactly which set of atoms from the displaced configuration occupies which site from the reference configuration, then this is beyond the current capabilities of the WS modifier and OVITO's data model. You would probably have to do it yourself using a custom analysis code.


Support Forum / Re: Open a xyz file with quaternion's orientatiton
« on: March 19, 2018, 09:32:29 PM »
I've already put a new program version online (3.0.0-dev146) which contains the small addition mentioned above. With this version, you should be able to read extended XYZ files containing a field specification like this:

Code: [Select]

Support Forum / Re: Open a xyz file with quaternion's orientatiton
« on: March 19, 2018, 05:41:05 PM »
Well, unfortunately, the Aspherical Shape property is not automatically mapped yet. You can look up the keywords to put in the XYZ file header for the various standard properties in the source code here:

I will add the Aspherical Shape property to the code and publish a new development version of OVITO within the coming days. In the meantime, you have to go back to the standard XYZ format and set up the mapping of columns to particle properties by hand.

Support Forum / Re: Open a xyz file with quaternion's orientatiton
« on: March 19, 2018, 08:57:46 AM »

Two problems here:

Your file doesn't follow the specification of the XYZ format. Note that an XYZ file should begin with the number of atoms on the first line, followed by a comment line, followed by the actual data columns. Your file is lacking the first two header lines. The second problem is on OVITO's side: The program doesn't recognize the format error and reads the number of atom from the first line, which starts with "4.549...". The file parser simply takes this as a "4" and reads four particles starting at line 3. I think this is a bug in the program: OVITO is too tolerant and should instead inform you about the fact that the first line doesn't consist of a single integer number. I will try to fix this in the code.

Here is another useful hint: There exists an extended XYZ file format specification, which OVITO can parse:

This extension allows you to embed parsing information in the second line of the XYZ file, the comment line, telling OVITO how to interpret  the 7 columns of your file. You should add the following two lines to the header of your file and OVITO will load the file without even asking you for the meaning of the 7 columns:

Code: [Select]
4.5493... ... ... ... ... ... ....


I have to admit I am not familiar with the Xmanager product. But from what I read I got the impression that it is a something like a X server, just for Windows. For pure Linux environments, where both the X client and the X server run on Linux machines, I can say that OVITO won't work (well) through remote X connections, and I think Xmanager is also a dead end. The reason is the design of the X protocol: The client (in this case OVITO running on the remote computer) sends drawing commands to the X server (your local PC), which will execute the commands to produce the screen output. Typically, this is works quite okay for regular windowing applications. The so-called GLX extension allows to also transmit OpenGL rendering calls through the same connection to display 3d graphics. The big problem with this approach, however, is the following: To render a large number of atoms, the X client has to send a large number of rendering commands to the X server. These commands and the corresponding data, in this case the XYZ coordinates of all atoms, need to be transmitted over the network. That means the total data size transmitted through the X window connection is on the same order of magnitude as the original simulation data size! In other words, any advantage over simply transferring the simulation data file to the local PC is completely lost. In fact, the situation is much worse: Every time the screen is refreshed, OVITO would have to transmit data for every atom over the network, again and again.

The much better solution (which I referred to as "remote desktop connection" in my previous post) is to perform the OpenGL rendering on the remote machine, right where OVITO is running and where the simulation data is stored. No atom coordinates need to be transmitted over the network, only the final viewport picture (basically a live video of the OVITO program window) needs to be streamed to the local PC, which requires much lower bandwidth. Such solutions exist, typically they use the VNC remote desktop protocol, and one available product is TurboVNC.

Just to give you and other OVITO users an example for the solution I described: The computing centre of Argonne National Lab offers a VNC connection to access their visualisation cluster called "Cooley", which I recently tested successfully with OVITO:


Remote X windows connections are not the way to go with OVITO. What makes OVITO different from the simple programs you mentioned is the fact that it uses the OpenGL interface to render 3d graphics. Modern OpenGL doesn't work through SSH/X window connections.

The solution is to use a VNC-based system, i.e. a true remote desktop connection. With such an approach, OVITO uses the OpenGL graphics hardware on the remote system and all drawing commands are executed on the remote machine. Only the final picture of the program window is streamed to your client computer.

TurboVNC is an example for such a software. Please ask your HPC support staff if VNC is available. Typically, this is the case for dedicated visualisation clusters, which have nodes with GPU graphics hardware. Regular compute clusters may not have GPUs or OpenGL support, in which case it's unlikely that you can run a graphical OVITO session on them.


Support Forum / Re: 30 Million atoms DXA
« on: March 16, 2018, 09:52:54 AM »
Dear Gopal,

Are you asking because you don't have a computer with the required memory capacity (ca. 30 Gb in your case), or because you are new to OVITO and don't know how to use the DXA function in general?

To analyse the dislocation defects in simulation datasets of that size I typically run OVITO in batch mode on a computing cluster. Larger computing centers typically have specific clusters for data visualisation and post-processing. Their compute nodes typically have much more than 30 Gb of memory.


Support Forum / Re: Identification of Burgers vector of defects
« on: March 14, 2018, 01:57:22 PM »
Hi Christophe,

Please excuse the late reply. I was away from work for some time and lost track of the incoming requests.

The DXA function of OVITO can identify dislocation loops (including their Burgers vector) if they are not too small. What "not too small" means is not so easy to define precisely, but it basically means that the defect must be ring-like and not sphere-like. There must be some "good" crystal material in the center of the defect and the defect atoms should form a loop structure around it. Then the DXA function will identify it as a dislocation loop with a certain Burgers vector and produce a corresponding line representation of the defect.

Hope that answers your question. Let me know if you need further help.


Support Forum / Re: atomic strain
« on: March 14, 2018, 01:51:41 PM »
Yes, you could compute the M matrix using OVITO's Compute property modifier (using the neighbor compute mode). Note, however, that you would need to define one modifier for each of the 9 components of the M matrix, because the modifier lets you only perform scalar computations.

A second option is to write a user-defined modifier function in Python. This would be the easier solution if you already have knowledge of Python.

Support Forum / Re: lattice orientation of a complex structure
« on: March 13, 2018, 09:41:58 AM »

I am afraid that isn't much that can be done. The only chance you have is if two of the six sub-lattices you mentioned would form a HCP lattice. Then you could select these atoms and use the PTM modifier on the subset of atoms only.

I would be interesting in knowing what kind of crystal structure you are dealing with. What's the name of the crystal structure (or the material)? Perhaps you have a picture of unit cell. I can discuss with Peter Larsen, the developer of PTM, whether it would be possible to add support for the structure to his identification algorithm.


Support Forum / Re: atomic strain
« on: March 13, 2018, 09:35:09 AM »
I understand your concern. But the reasoning behind this behaviour is the following: Strain is a quantity that is always calculated with respect to some reference configuration. For atoms within the perfect bulk, it is easy. The perfect lattice is used as ad-hoc reference configuration in the elastic strain calculation. For atoms within the grain boundary core, however, it's not clear what would be the right reference configuration. OVITO has no information about how a perfect, elastically unstrained twin boundary should look like. This kind of information can only be provided by the user, but then we are basically performing a regular atomic strain calculation again, which requires an explicit reference configuration.

Support Forum / Re: atomic strain
« on: March 13, 2018, 12:51:37 AM »
It is essential that you activate the 'Adjust simulation box size' option in the 'Show periodic images' modifier. Without it, the atoms are duplicated, but the periodic volume remains the same. Then you get overlapping atoms, which let's the structure identification algorithm fail.

Support Forum / Re: atomic strain
« on: March 13, 2018, 12:02:13 AM »
Please upload the structure. I will take a look myself and let you know if something is wrong with it.

Pages: [1] 2 3 ... 21