ttk icon indicating copy to clipboard operation
ttk copied to clipboard

[MPI] Endless loop when using ExplicitTriangulation in 2D

Open m-s-will opened this issue 1 year ago • 4 comments

Describe the bug Paraview gets stuck in an endless loop when preconditioning the ExplicitTriangulation on 2-dimensional data.

To Reproduce Steps to reproduce the behavior:

  • Run Paraview with mpirun with more than 1 rank
  • Use the Wavelet filter to generate a 2D dataset
  • Use the Tetrahedralize to force TTK to use the ExplicitTriangulation
  • Use any filter accessing the triangulation e.g. `ScalarFieldSmoother
  • Paraview will get stuck in an endless loop with the message Re-sending global ids to neighbors... in èxchangeDistributedInternal`. The call to this function is in https://github.com/topology-tool-kit/ttk/blob/caa916ef6b2ff9f71cc96242401acada73cc351d/core/base/explicitTriangulation/ExplicitTriangulation.cpp#L1240

This zip contains a statefile that will generate a 3D wavelet where everything works without problems. When setting the z extent to [0,0], the error appears. wavelet_explicit.pvsm.zip

Expected behavior It should behave as in the 3D case, by e.g. smoothing the scalar field without endlessly looping

System (please complete the following information):

  • OS: Ubuntu 22.04

  • Paraview 5.10.1, current ttk-dev

Additional information If forcing the while(doIter)-loop in exchangeDistributedInternal to exit (e.g. by adding a step variable), the rest of the pipelien executes without problems. So it appears to correctly exchange the data, but iterCond() is still true.

m-s-will avatar May 09 '23 12:05 m-s-will

I've been able to reproduce this issue. The infinite loop occurs when exchanging global edge identifiers between neighbors to label edges "belonging to" ghost cells. The iterCond (here the lambda defined at ExplicitTriangulation.cpp:1254) checks that all edges are labeled (global identifiers can come from neighbors of neighbors). An infinite loop might mean that some edges cannot be labeled with a global identifier.

pierre-guillou avatar May 09 '23 19:05 pierre-guillou

Hi all,

I've discussed this problem with @julien-tierny. Currently, this algorithm isn't really useful: it is done so that if the global identifiers for vertices and cells are produced independently of the number of processes, then the global identifiers of intermediary simplices will also be produced independently. However, at the moment, the global identifiers of vertices and cells are not created independently of the number of processes. This begs two questions:

  • Should we keep this algorithm or create a simpler one?
  • Should we try and make the global identifier generation of vertices and cells independent of the number of processes? Julien was leaning more towards the second, but the decision isn't set in stone just yet.

eve-le-guillou avatar May 12 '23 08:05 eve-le-guillou

@eve-le-guillou can I close this issue? (it looks like this discussion is outdated)

julien-tierny avatar Dec 11 '23 12:12 julien-tierny

The discussion is indeed outdated, however the original bug of this issue is still present (I just tested it on my machine).

eve-le-guillou avatar Dec 11 '23 12:12 eve-le-guillou