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 ... 22
Support Forum / Re: OVITO launching but display is blank
« on: Today at 11:00:19 AM »
Looks like somebody else had the same problem before:

In 2016, I had received another report from a user via email, who also experienced seemingly the same problem (on Fedora 22). Unfortunately, I never heard back from any them. So it's unclear whether theses users simply gave up or eventually found a workaround for the "black program window" problem. It doesn't seem to be a very common problem, given that many thousands of users run OVITO under Linux successfully.

Let's see what's your response to my previous questions, and then we can think about further actions.

Support Forum / Re: OVITO launching but display is blank
« on: Today at 08:47:23 AM »
What stands out in your ldd output is the fact that some .so libs, e.g. libstdc++, get loaded from a GCC 6 installation on your system instead of the system directories. This may or may not be a problem. At the moment, I cannot think of a reason why this should affect just the UI graphics but not the general operation of the OVITO program though. Perhaps you can clear the LD_LIBRARY_PATH env variable to see if running OVITO with the system libs makes any difference.

Do you see any terminal output from OVITO? (Normally there shouldn't be any, but perhaps Qt is reporting problems).

Just to make sure: You are not running OVITO through a remote desktop connection or even a virtual machine, right?

Support Forum / Re: how to create bonds accoding to bins
« on: March 23, 2018, 09:08:13 PM »
I would make use of the intro_molecule_only option of the CreateBondsModifier. Normally, it is used to prevent bonds between different molecules. But you can abuse this option here, and make each bin a separate molecule first. This can be achieved by outputting the bin number computed by the ComputePropertyModifier to the "Molecule Identifier" particle property instead of the "bins" property:

Code: [Select]
node = import_file("my.lammpstrj",multiple_frames = True)
compute_property_modifer.output_property="Molecule Identifier"
compute_property_modifer.expressions=["rint(ReducedPosition.Z * 10 + 0.5)"]
create_bonds_modifier = CreateBondsModifier(cutoff=cutoff, mode=CreateBondsModifier.Mode.Pairwise, intra_molecule_only=True)
create_bonds_modifier.set_pairwise_cutoff('Type 11', 'Type 12', cutoff)


Support Forum / Re: OVITO launching but display is blank
« on: March 23, 2018, 08:59:55 PM »
Hi Steve,

I'm not sure: This could be an OpenGL/graphics driver problem (please check if other OpenGL-based applications (e.g. ParaView) work on the same machine or not; also check if your Linux distro provides other graphics drivers that you can install). Or it could be a compatibility problem of the Qt library, which is used by OVITO for the user interface. You can try the current development release of OVITO, which ships with a newer version of the Qt library.


If you are using the compute chunk/atom, you can write the chunk IDs assigned by LAMMPS to each atom to the output dump file. OVITO will read this extra per-atom information and you can work with it in the program. For instance, you could use the Expression select modifier to select all atoms with a certain chunk ID, i.e. which belong to a certain bin.

Of course, this requires to re-run the simulation if you didn't dump the per-atom chunk IDs before. Alternatively, you can compute the bin number of each atom within OVITO. For that, I suggest you use the Compute Property modifier. Enter "Bin number" into the name field for the output property and enter the following formula into the expression field:

Code: [Select]
rint(ReducedPosition.Z * 10 + 0.5)

Replace "10" with the number of bins you want to create. This formula computes the bin each atom is in from its current Z coordinate.

OVITO has now assigned the "Bin number" property to each atom, and you can subsequently use this information to select atoms from certain bins or visualize the bin assignment using the Color Coding modifier.

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: March 21, 2018, 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.


Pages: [1] 2 3 ... 22