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 ... 25 26 [27] 28 29
Support Forum / Re: GSD File Format Type Issues
« on: February 23, 2017, 07:19:38 AM »
Maybe the GSD file reader still isn't fully confirming to the standard in this regard.

I couldn't test the aspect of changing particle numbers so far, because we don't use hoomd in our group (yet). Thus, a test file would be super helpful, maybe you have one for me. Thanks.

Note that SelectExpressionModifier only selects particles. That is, it sets the Selection property of certain particles to 1, but it doesn't remove the other particles. That's why the total number of particles is still the same.

Thus, in addition to the SelectExpressionModifier, you need to add a DeleteSelectedParticleModifier. And since you want to keep the sites with occupancy == 0, the selection must be inverted first (or you simply invert the selection expression):

Code: [Select]
node.modifiers.append(SelectExpressionModifier(expression = 'Occupancy == 0'))
vacancies = node.compute()

Yeah, true. I overlooked this.

I checked the IPython documentation now. Here is the way it's correctly done:

Code: [Select]
import IPython

Regarding your question how to stay in console mode after executing a script file:

There is no such option in the ovitos interpreter, but you can try to append the following lines at the end of your script:

Code: [Select]
import IPython


As stated here in the documentation, the current version OVITO requires that scripts are executed by the ovitos interpreter. You cannot use your standard interpreter to import the ovito Python module. The main reason for this restriction is that the Python module requires a fully initialised program environment as a context. Historically, OVITO has been a graphical program and the Python programming interface was added later as an extension plugin that allows controlling the program functions programatically. A second reason is that the precompiled Python extension modules coming with the binary version of OVITO may not be compatible with all Python interpreters, because they were built specifically for the embedded ovitos interpreter.

However, this status is likely going to change. I am working on making the ovito Python package loadable from external Python interpreters without having to start ovito or ovitos first. In a first version I will make OVITO's analysis and file I/O functions available to scripts. Later, visualization and rendering functions will follow.

In the meantime you might be able to integrate the ovitos interpreter, which behaves almost like the standard CPython interpreter, into Spyder if that IDE allows you to configure the Python interpreter to use. Let me know if you have any further questions.

Support Forum / Re: Build error: undefined reference in libbotan
« on: February 18, 2017, 07:07:32 PM »
I have moved this forum post to a new topic, because it deals with a different kind of compilation error.

Which version of Ubuntu do you work on?

The error message suggests that some dependencies of the Botan library are not met. It could be that OVITO needs to be linked against the openssl library if it's a dependency of Botan, but I am not sure.

The first thing I would try to work around this issue is to deinstall the Botan lib:

sudo apt-get remove libbotan1.10-dev

Then run 'cmake .' again and recompile. OVITO will now be built against the internal copy of the Botan lib that is included in the OVITO repository.


OVITO doesn't have a built-in function for computing global quantities from per-atom properties, but you can implemented this with a little Python modifier script. Simply apply a Python script modifier to the dataset and copy-paste the following script:

Code: [Select]
import bumpy as np

def modify(frame, input, output):
    total_pot_energy = np.sum(input.particle_properties['poteng'])
    total_kin_energy = np.sum(input.particle_properties['kineng'])
    total_energy = total_pot_energy + total_kin_energy
    output.attributes['total_energy'] = total_energy

Here I have assumed that the per-atom potential energy and kinetic energy are stored in the poteng and kineng particle properties respectively. You have to adjust the names in the script to your case.

The last line in the script saves the computed total energy in a so-called attribute. You can then use OVITO's file export function to export this quantity as a function of simulation time to a text file.

Support Forum / Re: Compile error
« on: February 17, 2017, 03:02:29 PM »
It looks like there is another user facing the same issue described in this forum thread. He created an issue on GitLab:

@krege: Can you please describe your solution. Which changes to the source code did you exactly make to fix the compilation error?


Support Forum / Re: connection error reading from remote HPC
« on: February 17, 2017, 02:57:42 PM »

The error message suggests that the SSH client of OVITO does not reach the SSH server at all. I assume you already double checked that the hostname is correct. (It might be a good idea though to also use the 'ping' command in the terminal to check if the server is responding).

What about the port? Does the SSH server listen on the default port 22?

Which Windows software do you normally use to connect to the HPC machine?

And do you have any firewall software installed on your local PC that may be blocking OVITO from connecting to the remote host?

Support Forum / Re: Building docs
« on: February 16, 2017, 08:09:00 AM »
I'm glad it worked. Thanks for letting us know.

Support Forum / Re: Building docs
« on: February 15, 2017, 10:22:30 AM »

Normally, the CMake build script takes care of building the Python documentation using Sphinx. It should be sufficient to run "make scripting_documentation" in the build directory. Is this what you were doing? The console output you posted suggests that you run Sphinx manually. But that being said, the way you ran Sphinx looks okay to me.

I haven't see this type of error before. To me it looks like an internal error in the Sphinx machinery which is not really related to OVITO. All I can say is that I didn't have any problems generating the docs with the same version of Sphinx (1.4.8 ) as you.

I'm sorry that I could not provide any real help here.

Support Forum / Re: regarding ovito use on HPC
« on: February 15, 2017, 10:10:03 AM »

I'm not sure what this error message means, I haven't encountered it before. However, I have seen a very similar type of message in the terminal: "setNativeLocks failed: Resource temporarily unavailable". It is due to a bug in an older version of the Qt library used by OVITO ( It occurs every time OVITO writes to its program configuration file in the user's home directory if it is located on a network drive. In this case locking the configuration file to prevent shared access fails due to the Qt bug. However, this warning message can be safely ignored in my experience.

This being said, let me ask you:

1) Does OVITO work normally despite the message, or is it terminating right after printing that message?
2) Did you build OVITO from source, or are you using the official binaries?


Support Forum / Re: Unit of D^2
« on: February 09, 2017, 09:46:44 PM »

Yes, this is correct. The unit of this quantity is length squared in whatever units of length your input data is.

Support Forum / Re: How to hide background atom in OVITO
« on: February 07, 2017, 09:34:16 AM »
In the reference picture you posted the hexagonal rings have been filled with semitransparent polygons. Currently, OVITO doesn't provide a function to do exactly this. You may be lucky by using OVITO's "Construct surface mesh" modifier function though. It creates a surface mesh around atomistic structures. However, it has originally been designed for solid structures, not sheet-like objects like your nanotube. I'm pretty sure it would work for a straight nanotube, but for the helical tube I'm not so sure. You probably have to play around with the "probe sphere radius" parameter.

Support Forum / Re: GSD File Format Type Issues
« on: January 29, 2017, 02:22:30 PM »
I have fixed the loading of GSD files now. Please check out the newest development version available here.

Loading of GSD files with static data like the particle types was not correctly implemented, mainly because I didn't have appropriate test data available. Thanks for providing a file. Let me know if you notice any remaining problems with the new program version.

Pages: 1 ... 25 26 [27] 28 29