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 ... 23 24 [25] 26 27 ... 31
361
Support Forum / Re: Vorotop modifier
« on: July 20, 2017, 01:40:49 PM »
This modifier is missing in the Linux build of OVITO (the Windows version has it). I wasn't aware of that, so thanks for notifying me.

I'll try to post new dev builds as soon as possible, probably tomorrow. If you can't wait and want to use the VoroTop modifier immediately, please build OVITO from source yourself.

362
Support Forum / Re: RDF
« on: July 13, 2017, 10:38:59 PM »
Yes, OVITO can read GSD files (written by the HOOMD code). Let me know if you experience any problems with this. I wrote the GSD file parser myself, but I couldn't test it very much, because I didn't have many GSD files at hand.

The RDF calculation as it is currently implemented in the Coordination Analysis modifier of OVITO is very simplistic: It includes every particle pair in the system, irrespective of the molecules the individual atoms/particles are part of. I guess you can call this "inter-molecular", but I am not familiar with the precise nomenclature.

363
Support Forum / Re: RDF
« on: July 13, 2017, 09:58:00 PM »
Hi,

Most analysis functions in OVITO, including the Coordination Analysis, operate on a per-frame basis. The program cannot know that your system is in equilibrium and that you want to take a time average.

I suggest you write a small Python script for OVITO which performs the time averaging for you. Here is how you calculate the RDF for a single frame:

http://ovito.org/manual/python/modules/ovito_modifiers.html#ovito.modifiers.CoordinationNumberModifier

How to load a simulation sequence and step through the frames is described here:

http://ovito.org/manual/python/introduction/file_io.html

-Alex

364
Support Forum / Re: Run error on the example of WS Python Script
« on: July 11, 2017, 11:48:42 AM »
This error probably occurs for the same reason as in your other forum post: The input data files contains only a single atom species. In this case the occupancy array is only one-dimensional. The modify() function in your script, however, expects it to be two-dimensional.

365
Support Forum / Re: Some problems on OVITO WS Python Script
« on: July 11, 2017, 11:42:05 AM »
Hi,

A possible explanation for this error is that your input simulation file contains only one atomic species. In this case setting per_type_occupancies=True has no effect. The generated occupancy array is still one-dimensional and you cannot refer to vector components like Occupancy.1 when exporting the results.

Please check if that is the case. You can check the number of atom types in the input and inspect the dimensionality of the Occupancy array by adding something like this to your script:

Code: [Select]
print("Number of particle types: %i" % len(node.source.particle_properties.particle_type.type_list))
print(node.compute().particle_properties["Occupancy"].array.shape)

I noticed another, unrelated problem in your script: You should not add the SelectExpressionModifier and DeleteSelectedParticlesModifier modifiers inside the for-loop, because then you will insert them many times to the modification pipeline, which becomes very long. Instead, insert the two modifiers only once before entering the for-loop, like you already did with the WignerSeitzAnalysisModifier.

-Alex

366
Support Forum / Re: Ovito run problem
« on: July 07, 2017, 11:42:10 AM »
OVITO cannot be run through a remote X window connection. The reason is that it requires direct access to OpenGL graphics hardware.

The only remote execution solution which is supposed to work is TurboVNC/VirtualGL. Perhaps you can make use of that.

If not, you should run OVITO locally. Note that it provides a built-in SFTP client, which allows you to access data stored on remote machines.

367
Support Forum / Re: Export from OVITO to render in Paraview/Blender?
« on: July 03, 2017, 09:41:56 AM »
Hi,

Could you please clarify what kind of data you have in mind that should be exported to Paraview or Blender? Are you thinking about

  • atoms/particles
  • bonds
  • surface meshes
  • dislocation lines
  • camera setup
  • animation/trajectories

or all of the above? I'm asking because not all file formats support all kinds of data, so the choice of exchange format depends on what you would like to transfer.

The only export format which supports all types of data and which can be directly written by OVITO is the POV-Ray scene description format. However, as far as I know, this format cannot be read by Blender (and certainly not Paraview). Surface meshes can be exported from OVITO to the VTK format, which can be opened with Paraview. This requires a call to the export_vtk() Python function.

I have been working on an Alembic file exporter for OVITO for some time. This file format can be read by Blender and even supports animated meshes. However, that development work is incomplete and currently paused.

Writing a Python script for OVITO to export data to disk in a file format of your choice is possible, at least when it comes to particle and bond data. For example, I have written a script that exports the current particle set to a IDTF model file for embedding the particle data in PDF documents. Surface mesh data is currently not accessible via the Python interface. Thus, for these things, a real file exporter plugin must be written in C++, similar to the already existing POV-Ray exporter.

Best regards,
Alex

368
Support Forum / Re: Running scripts without a user being logged in
« on: June 27, 2017, 06:17:42 PM »
Hi Alex,

thanks for reporting this issue. I have created a corresponding issue in our tracking system:

https://gitlab.com/stuko/ovito/issues/31

During the development of ovitos I did pay attention to making it work even when there is no X server running under Linux (so-called "headless" operation). However, I didn't consider a similar situation under macOS, mainly because I didn't know until now that it is even possible to run macOS computers without a graphical session.

I'll try to look into this issue when I find some time. Perhaps it is possible to detect the headless environment and then implement a similar behavior as under Linux.

369
Are you sure that setting the cell dimension in this was has no effect whatsoever? My expectation was that the behaviour is similar to what happens in the graphical OVITO version: Manually and temporarily changing the box size is possible, but any changes will be overwritten as soon as another simulation frame is loaded, e.g. by stepping to the next animation frame.

So changing the dimensions of the node.source.cell should be possible as long as you do not trigger a reload of the input file.

Note that, as a workaround to the normal behaviour, you can use the AfffineTransformationModifier. It allows you to permanently overwrite the cell vectors loaded from the simulation file.

370
Support Forum / Re: Switch renderer in a python script
« on: June 22, 2017, 01:09:41 PM »
Hi Katey,

you can replace the renderer in a Python script by creating an instance of the TachyonRenderer class and assigning it to the renderer field of the RenderSettings object.

This can be done either for the global render settings object:

Code: [Select]
rs = ovito.dataset.render_settings
rs.renderer = TachyonRenderer()
viewport.render()

or by creating an ad-hoc render settings object, which is then passed to the Viewport when rendering an image:

Code: [Select]
rs = RenderSettings(renderer = TachyonRenderer())
viewport.render(rs)

371
Support Forum / Re: Anaglyphs in OVITO
« on: June 20, 2017, 09:08:34 AM »
Hi Carlos,

Thanks for the feedback and the suggestion.

What I can say is that I already implemented anaglyph (blue/red) rendering in the interactive viewports of OVITO one or two years ago for testing purposes. But that feature is incomplete (due to my lack of time) and not enabled in normal builds of OVITO. You'll find it in debug versions of OVITO if you build from source. I still need to implement user controls for the eye-distance and other projection parameters. What I don't like about anaglyph rendering is that the effect works only well for colorless datasets. Color coding and other important visualizations tools don't play well with it.

The latest dev build of OVITO contains an extended POV-Ray rendering module, which allows producing omni­directional stereo projection videos. These are 360 degree stereoscopic videos that can be watched with VR headsets or uploaded to Youtube.

There is also a VR module for OVITO under development, which enables realtime walkthroughs of the scene using headets like Oculus Rift and HTV Vive. This is actually very cool. We use it for demo purposes mainly. Some more fine tuning of user controls is necessary for a public release.

-Alex

372
Dear Christophe,

I don't think this is a bug; it's normal behavior.

First, allow me to correct you: I assume that you used the Wigner Seitz analysis modifier (not the Coordination Analysis modifier) to compute the occupancy numbers. This is important, because the WS modifier performs a replacement of the dataset: It replaces all atoms from the current configuration with the set of sites loaded from the reference configuration, including all their particle properties. This replacement is done, because the occupancy numbers calculated by the WS modifier are per-site properties, not per-atom properties (It's the atoms that occupy the sites). So you loose per-atom energies and other properties during this step and you are left with only the sites loaded from the reference configuration + information on how many atoms (of the displaced configuration) occupy these sites.

If you really need to select sites based on their occupancy numbers AND the energies of the atoms that occupy the sites, then we have to think about possible solutions. There are different avenues that come to my mind.

-Alex

373
Support Forum / Re: python interpreter update in ovito
« on: June 13, 2017, 09:16:08 AM »
The Scipy package is not included in the Python interpreter that ships with Ovito. For installing modules in that interpreter or other options, see

http://ovito.org/manual/python/introduction/running.html#using-third-party-python-modules-from-ovito-scripts

The latest dev version of Ovito also provides the possibility to use the Ovito modules from the standard system interpreter:

http://ovito.org/manual_testing/python/introduction/running.html#using-the-ovito-package-from-other-python-interpreters


374
Support Forum / Re: What does a particle radius of 1.0 represents?
« on: June 11, 2017, 08:45:47 PM »
Particle radii in Ovito are specified in natural length units of your simulation, topically angstroms.

The value of 1.0 [angstroms] for the default particle radius is only used as a fallback if no per atom type radius has been set or if it is zero. Otherwise the per-type radii take precedence. If the data file contains named atom types (e.g. "Cu"), Ovito should automatically assign a reasonable radius to the types (e.g. 1.28 angstroms for "Cu"). The default radii for the chemical elements can be modified in the application settings dialog. You can also change the current per-type values after loading a data file by selecting the "Particle types" entry in the list box on the right of the main window.


375
Support Forum / Re: Ovito
« on: June 07, 2017, 08:15:57 PM »
Sorry, I no longer provide current program packages for 32-bit Windows. It would mean a lot of extra work and the demand is quite small. The last program version available for 32-bit Windows was Ovito 2.7.1. You can still download it here:

http://ovito.org/download/

Pages: 1 ... 23 24 [25] 26 27 ... 31