Hi there,
when using Anari renderer with the following pipeline options in this sequence:
[ ... ]
# if I comment this line out it will work:
pipeline.modifiers.append(SmoothTrajectoryModifier(window_size=6, minimum_image_convention=True))
pipeline.modifiers.append(PythonScriptModifier(function=modcolor))
pipeline.add_to_scene()
cell_vis = pipeline.source.data.cell.vis
cell_vis.line_width = 0.025
cell_vis.rendering_color = (0.2, 0.4, 0.6)
pipeline.modifiers.append(WrapPeriodicImagesModifier())
data = pipeline.compute()
[ ... ]
the ovito python module crashes in "mesh generation " with
OVITO: Script execution
OVITO: Generating bonds
OVITO: Generating coordination polyhedra
OVITO: Rendering frame 396
OVITO: Preparing mesh for display
… as the last message. Then it will allocate all available memory on the machine (32GB in my case) and die with “bad allocation” in viewport.py.
vp.render_image(
File "C:\WinPython-3.12.4\python-3.12.4.amd64\Lib\site-packages\ovito\vis\_viewport.py", line 120, in _Viewport_render_image
fb = rs.render_scene(self.scene.anim, layout)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
MemoryError: bad allocation
This happens only with one of the hundreds of files. As soon as I disable SmoothTrajectoryModifier it will work.
Thanks for reporting this issue. That’s something we should reproduce and investigate in more detail.
However, it will be necessary to use your script and your data for this, I’m afraid. There is really no direct connection between the SmoothTrajectoryModifier and the subsequent mesh rendering. This means it is likely that the mesh rendering steps crashes due to a pathological configuration of the input mesh, which occurs by chance, only when the SmoothTrajectoryModifier slightly changes the input particle positions.
Would you be willing to provide a file package that allows us to reproduce the problem? You can share it with us by sending an email to [email protected].
Hi Alexander,
I will provide this. Interestingly, with small window size:
pipeline.modifiers.append(SmoothTrajectoryModifier(window_size=1, minimum_image_convention=True))
the script goes through without problems (nothing else changed).
- - - - - - [ Addendum ] - - - - - - - -
window_size = 1 OK
window_size = 2 OK
window_size = 3 OK
window_size = 4 OK
window_size = 5 OK
window_size = 6 CRASH
window_size = 7 OK
window_size = 8 OK
etc.
I sent a zip file to [email protected]
It’s the data file d.39600000.lcd (LAMMPS coordinate dump) that leads to crashes.
Thank you for providing us with a data archive that allowed us to reproduce the problem.
A more detailed analysis today revealed the following:
- The issue has nothing to do with the image rendering process, but occurs in a preparation step (constructing the cap polygons of a periodic surface mesh)
- The cause is a bug in a polygon tessellation routine used by OVITO (the OpenGL Utility Library (GLU) by Silicon Graphics, Inc.)
- It only occurs in very rare, pathological situations and leads to an infinite loop within the tessellator, in which more and more memory gets allocated.
- Some platforms, e.g. macOS, are not affected by the issue, probably because a different compiler or processor architecture slightly alter the outcome of floating point calculations, avoiding the numerical precision issue.
Unfortunately, the GLU library is no longer maintained, the source code is very complex, and there are no robust alternatives that we could use instead. It was therefore only possible to detect the infinite loop and abort it if necessary to prevent the crash (a successful construction of the cap polygons is not possible for the pathological configuration).
I would ask you to test this workaround yourself to double check that it is effective. You can find a dev build of version 3.12.4 of the OVITO Python module here, which includes the fix:
https://pypi.org/project/ovito/3.12.4.dev2/