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 ... 18
Support Forum / Re: Not Able to Print a Variable While Looping Over Frames
« on: November 19, 2018, 08:50:58 AM »
I assume you are currently using the following code line to determine the max. z-coordinate of all particles:

Code: [Select]
output.attributes["High_Z"] = numpy.max(input.particles["Position"][:,2])

Here the ':' selects all particles. You can replace it with an index list which selects only particles of a specific type:

Code: [Select]
selection1 = (input.particles["Particle Type"] == 1)
selection2 = (input.particles["Particle Type"] == 2)
output.attributes["High_Z(1)"] = numpy.max(input.particles["Position"][selection1,2])
output.attributes["High_Z(2)"] = numpy.max(input.particles["Position"][selection2,2])

What is being used here is a technique knows as Boolean indexing of a Numpy array. The first two lines generate two selection arrays using Boolean expressions, which refer to the "Particle Type" property. The following two code lines use these selection arrays to filter the "Position" property array.

Support Forum / Re: Not Able to Print a Variable While Looping Over Frames
« on: November 17, 2018, 07:56:42 PM »
Please attach the script code. Without it, it is hard to tell what went wrong.

Support Forum / Re: Updating Molecule IDs in Replicate Copies
« on: November 16, 2018, 08:45:44 AM »

This appears to be an accidental slip in the implementation of the replicate modifier. Thanks for reporting this.

I fixed the issue in the source code of Ovito today.

You can work around this problem by applying the Compute Property modifier after replicating the atoms. Use the following formula to recompute the Molecule Identifier property:

Code: [Select]

This will assign new unique molecule IDs to the atoms. Note, however, that the Compute Property in the current dev build Ovito 3.0.0-dev contains another bug that sets the expression variable 'N'  to zero. Thus, in this program version you might have to replace the dynamic variable 'N' in the formula above with the literal number of (replicated) atoms.


Support Forum / Re: Name on the particle
« on: November 14, 2018, 02:52:47 PM »
Please subscribe to this GitLab issue in case you want to get notified of any developments regarding particle text labels or if you have any suggestions:

Support Forum / Re: Name on the particle
« on: November 14, 2018, 11:26:33 AM »
No, sorry, this feature is not implemented yet. I am currently working on completing the 3.0 release, not adding any significant new features beyond what is already there. Text labels for particles is something that is planed for a later program version, e.g. Ovito 3.1, which I will be working on sometime in 2019. My day job doesn't leave me as much time to work on Ovito as I'd like to.

For the time being, the only solution is for you to use the Python viewport overlay function and write script code to draw the text labels yourself.

Support Forum / Re: Time average Positions
« on: November 14, 2018, 09:28:23 AM »

Ovito currently doesn't have a built-in function for doing this. So there is no "easy way", sorry.

If I was you and you are working with LAMMPS dump files, I would use LAMMPS to do the time-averaging using the "fix ave/atom" and "rerun" commands. Otherwise, I would use OVITO's scripting interface to load the trajectory data and implement the time-averaging using Python code. That's kind of a "hard way" of course.

If you think that this is a very common problem for which Ovito should provide a built-in solution, let us know. Perhaps I can add it in the future. Computing time-averaged atomic positions is technically not much different from computing interpolated atomic positions, which the new Interpolate Trajectory modifier of Ovito 3.0.0 already does. 


Support Forum / Re: Not Able to Print a Variable While Looping Over Frames
« on: November 12, 2018, 12:05:20 PM »

First note that the following code line should not be indented:
Code: [Select]
That is because this statement needs to be part of the main program and not the compute_max_z() function.

The error occurs, because you did not specify an absolute path of the output file when calling the export_file() function. Without specifying a path, the function will probably try to write the output file to the root directory of your machine, which is a write-protected location. To avoid the error message, specify a full path for the output file, like you did for the input file when calling import_file().


Support Forum / Re: Not Able to Print a Variable While Looping Over Frames
« on: November 08, 2018, 09:55:22 PM »

When loading a legacy-type XYZ file, you need to tell Ovito what the meaning of the file columns is. This is done using the "columns" keyword parameter. See the section on "File columns" here.

For example:

Code: [Select]
node = import_file("", columns=["Particle Identifier", "Particle Type", "Position.X", "Position.Y", "Position.Z"])

The error occurred, because Ovito didn't now where to take the data for the "Position" particle property from. Particles must have a "Position" property, filled with the data from three columns of the input file.


Support Forum / Re: Not Able to Print a Variable While Looping Over Frames
« on: November 08, 2018, 05:46:20 PM »
Thanks for letting us know that you were able to solve the problem.

Yeah, additional pages are easy to miss in the forum. I'm sorry about that. I just bumbed up the maximum number of posts per page to 30 to reduce the likeliness of additional pages showing up.

Support Forum / Re: Atoms Shifting to one end
« on: November 07, 2018, 08:38:07 AM »
Thanks for sending me the POSCAR files. The simulation cell flips in the 9th frame, because the corresponding POSCAR file contains a cell matrix with negative elements (which is not the case for the first 8 files):
Code: [Select]
 -2.464513105012   0.000000374102  -0.000000000000
  0.000000620222   4.267423898079  -0.000000000000
 -0.000000000000  -0.000000000000 -19.658225471601
Ovito is operating normally, I would say. This likely is an error in the code that wrote the POSCAR files.


Support Forum / Re: Problems with the access of property data
« on: November 05, 2018, 08:05:19 AM »
Dear Linyuan,

I'm sorry for the confusion. This error is due to recent changes to the Python data access interface of OVITO and also the underlying data model (introduced with build 3.0.0-dev264), which have not been documented yet. I will try to update the documentation within the coming days (maybe weeks) to explain this important change in more detail.

Here is the main rule you need to follow according to the changed data access interface:

Whenever you are going to modify a data object in a data collection in any way, you need to explicitly request a mutable version of that object. This is done by appending a '_' to the end of the identifier of the object.

In your particular case, you need to write:
Code: [Select]

pos_property = data.particles_['Position_']
with pos_property:
    pos_property[0] = (0,0,0)

A _ has been appended to the particle property name "Position", because you are going to modify the per-particle values stored in that Property object. And note that the _ was also appended to the DataCollection.particles accessor, because you are going to modify one of the sub-objects of this PropertyContainer.

This brings me to the second rule:
A mutable version of a data object can only be requested from a parent data object that is mutable itself. In other words, when modifying a sub-object in the hierarchy of data objects, the container object needs to be made mutable as well using the _ notation.

Any attempt to modify a data object that is marked as read-only (immutable state) will raise an error like the one you saw. By default, all data objects that get passed to a user-defined modifier function by the system, or which are contained in a DataCollection produced by the Pipeline.compute() method, are immutable. The reason is that these data objects are owned by the data pipeline system and must be preserved in their original state to avoid unexpected side effects. Requesting a mutable version of these objects using the _ notation creates a data copy that is safe to modify by the user code.


Support Forum / Re: Problems starting Ovito on Linux Centos 7
« on: November 04, 2018, 08:18:31 AM »
Thanks for posting the LD_DEBUG output. This gave me a first idea what is failing during startup. It seems like the (incompatible) library file /lib64/ is getting loaded instead of the internal version ovito-3.0.0-dev284-x86_64/lib/ovito/lib/ for some reason.

On your system, the LD_LIBRARY_PATH environment variable is set to the value /lib64:/usr/lib64. Do you know whether this is the default value under RHEL 7, or did you set LD_LIBRARY_PATH yourself? I am wondering if it makes a difference when you run Ovito without LD_LIBRARY_PATH being set (like it is the case under Ubuntu, for example):

  LD_DEBUG=libs LD_LIBRARY_PATH= ./bin/ovito

Another fix you could try (not sure if it will work):

  cd ovito-3.0.0-dev284-x86_64/lib/ovito/plugins_qt/platforms/
  ln -s ../../lib/ .

Support Forum / Re: Atoms Shifting to one end
« on: November 04, 2018, 07:15:20 AM »
Hi Anuja,
So far, I don't have an explanation for this behavior. Can you send us the data files (or attach them to a reply posting) and tell us how to reproduce the problem?

Support Forum / Re: Problems starting Ovito on Linux Centos 7
« on: November 02, 2018, 10:37:46 AM »
Hi Tanh,

Thanks for letting me know that the problem persists. I'm not sure, this time it may be a different library issue.
Perhaps I will find some time to install RHEL on one of our machines to test this myself, but in the meantime it would be helpful if you could execute Ovito with the LD_DEBUG environment variable set. This should produce log output that can help me diagnose (and perhaps solve) the problem:

  LD_DEBUG=libs ./bin/ovito

Please save the generated output to a text file and attach it when posting a reply. Thanks.


Support Forum / Re: Problems starting Ovito on Linux Centos 7
« on: November 01, 2018, 12:28:48 AM »

Thank you for sharing your solution of the problem, which seemed to be due to a library path configuration issue in the older Ovito program packages. I hope I was able to fix this issue in the latest Ovito package (development build v3.0.0-dev284) that is available now. It should run out of the box, without the need to change the LD_LIBRARY_PATH variable on CentOS Linux. Let me know if it doesn't.


Then how about using the Slice modifier to select atoms within a plane? This modifier lets you specify the width of the slab of atoms that should be selected. Furthermore, you need to specify the normal vector of the selection plane (in spatial coordinates though, not in crystal lattice coordinates). Subsequently, you can apply the Assign Color modifier to give all atoms selected by the Slice modifier a new color of your choice.

Support Forum / Re: Quantum espresso files
« on: October 25, 2018, 08:36:24 AM »
Yes, we may be able to add I/O support for QE files to Ovito in the future.

I am not familiar with the QE software myself and the data file formats it uses. Would you be interested in reading just the input files of QE with Ovito, or also the output files? Perhaps you can post an example file that you would like to open with Ovito. That would be helpful.

It's likely that the error only occurs for files fetched via SFTP, but I cannot promise that it doesn't also occur for files stored locally.

I would be interested in knowing how many files you are processing and after how many the error occurs. You can find out by adding a print statement to your modifier function to print the current frame being processed:

Code: [Select]
def compute_max_z(frame, input, output):

As a workaround, you could process the frame sequence in chunks. Call ovitos several time to process one chunk at a time and then combine the generated output files into one using a text editor. The export_file() function allows you to specify a (sub-)range of frames to process. Let's say the error occurs only after 1000 frames have been processed succesfully, then you can limit the script to frames 0-999:

Code: [Select]
export_file(node, "max_z2.part1.txt", "txt", columns=["Ocount", "x_coord"], start_frame = 0, end_frame = 999, multiple_frames = True)

Dear Ali,

You specified the crystal orientation and a slip system. Can you please clarify what the atomic parameter is according to which you would like to color the atoms?


Thank you.
Are you processing a large number of CFG files? The error message ("ERROR: Failed to open input file: Too many open files") suggests that Ovito reaches some sort of resource limit, which might be a bug in the software. I am wondering if it makes a difference whether you load the data files via SFTP protocol or from a local filesystem, like you did before.

Dear jatink,

Could you please attach the script file ('') so we can see the entire code. This would be helpful to understand where this error comes from.



Support Forum / Re: Name on the particle
« on: October 23, 2018, 07:08:32 PM »

The current version of OVITO does not support the rendering of text labels next to or on top of individual particles. This feature has been requested a few times before by other users and is on the wish list I keep. Once I have completed the 3.0.0 release, I will start working this and other new useful features as soon as possible.


Support Forum / Re: Problem in executing OVITOS
« on: October 23, 2018, 12:14:54 PM »
The first set of error messages suggest that you have two installation of the Qt libraries on your computer, one in the directory  /usr/local/opt/qt/lib/Qt*, the other in /Users/3sd/Qt/5.11.1/clang_64/lib/Qt*. Both libraries version are being pulled in during compilation of OVITO leading to a version conflict.

It's important to make sure that one and the same Qt version is being used during compilation of OVITO and during execution. You can control which Qt installation is being used during compilation by setting the CMAKE_PREFIX_PATH variable in CMake, e.g.

  cmake -DCMAKE_PREFIX_PATH=/Users/3sd/Qt/5.11.1/clang_64/ ...

The Python interface of Ovito uses the PyQt5 module, which provides the Python bindings for the Qt library functions. At runtime, the statement "import PyQt5.QtGui", which appears in the error message, will load the PyQt5 module and with it the native Qt libraries. My guess is that at this point the libraries from the second Qt installation directory get loaded, leading to a version conflict with the Qt libraries that are needed by the Ovito core, i.e. the ones from the first Qt installation that was specified at build time.

Probably the resolution to this problem is to build the PyQt5 module form source instead of using a precompiled or prepackaged version. When building the PyQt5 python module, you need to specify the path to the same Qt library installation that is also used to build Ovito. At least this is what I do to build the official binaries for Ovito for Mac. I download the PyQt5 sources, build them against the same Qt version as Ovito and install them in the Python interpreter (see here).

May I ask why intend to build Ovito/ovitos from source on macOS in the first place instead of using the prepackages binaries?

Support Forum / Re: Steinhardt order parameters
« on: October 21, 2018, 04:44:24 PM »
Ok, yeah. I'm sorry for the confusion. The "asa-code" package you are referring to is not related to OVITO in any way. I was just not willing to register another top-level internet domain to host this little code package, which was written for academic purposes back in 2012. That's why I decided to simply put the code archive on a sub-domain of the existing web server to make it available to the readers of my paper on atomic structure identification methods, which it was written for.

Steinhardt order parameter calculation is currently not part of OVITO. You can either use the ASA code package to calculate them (Note that the code currently computes only two specific ones, I think. So you might have to extend it a little depending on your needs), or you can implement the order parameter calculation yourself within OVITO as a user-defined analysis modifier function using the Python scripting interface. The third option is to create an official feature request on our GitLab site for OVITO.


Support Forum / Re: sort_particles
« on: October 21, 2018, 09:33:13 AM »
Hi Leila,

The sort_particles option is not yet included in the program version your are using (3.0.0-dev200). Please upgrade to the latest available version (3.0.0-dev234 or newer).

Every now and then I upload new test builds for the 3.0 release, and the published feature list and documentation set always reflect the state of the newest test build.


Support Forum / Re: Generate trajectory lines of a dynamic group
« on: October 19, 2018, 03:19:07 PM »

I agree, this is a missing feature that has been requested before. I've put it on the list of things that need to be worked on:

I am not aware of a workaround for the current Ovito version, sorry.


Support Forum / Re: which gcc is used to compile ovito?
« on: October 19, 2018, 03:05:37 PM »

When running ovitos on a remote machine non-interactively, it is always a good idea to clear the DISPLAY environment variable first:
Code: [Select]
export DISPLAY=

If this variable is set, ovitos will think that an X server is running and will try to connect (that's a built in behavior of the Qt library). When running compute jobs on an HPC cluster, the job will typically inherit the current value of the DISPLAY variable when the job is submitted to the queuing system. At this point the DISPLAY variable may be set, because the login node may be running an X server or because your were using X forwarding over SSH. But later, when the job gets executed and ovitos is started, no X server will be available. That's why you should explicitly clear the DISPLAY variable to tell ovitos not to look for an X server.


Support Forum / Re: Partial radial distribution function (RDF)
« on: October 17, 2018, 09:05:08 AM »
Dear Safy,

Don't paste the code into the 'modifier name' input field. Instead, click the 'Edit script...' button. This will open the code editor window. Replace the existing default script in this window with the one you copied from the forum topic.


Support Forum / Re: Dislocation in Tensile Test
« on: October 10, 2018, 08:31:12 PM »
Ovito provides an analysis function (see here)  for identifying and tracking dislocation line defects. But it only works for 3D bulk crystals. It cannot be applied to sheet materials or CNTs for that matter.

However, Ovito provides a collection of general tools for analyzing simulations and visualizing defects. Perhaps they can be useful for your purposes. Right now we don't have a good idea what you want to do and how your simulation model looks. If you like, give us some more insight into your problem. Perhaps we can provide some hints how Ovito can be useful.


Support Forum / Re: Problem in executing OVITOS
« on: October 10, 2018, 12:26:54 AM »
Under macOS, the "ovitos" executable may not be fully functional or not even present in the subdirectory under the build directory where you ran "cmake" and "make". Instead, you should find an executable named "ovitos.exe" in that location, which should work. The final "ovitos" executable gets created in the installation directory only when you run the "make install" step.

In any case, before you try running "ovitos", please confirm that the "ovito" graphical program is working normally and that the embedded Python interpreter operates as expected.

Pages: 1 [2] 3 4 ... 18