Stopping a long running AlphaWrap

[sgayda2]

I am using alpha_wrap_3 in a semi interactive way. I have it running in its own thread, but give the user the ability to cancel the processing if its taking too long or they change their mind about the params or the call itself.

What is the preferred way to do this, since i would rather have this stop gracefully and not have to kill the thread/process. Is there even a way?

[afabri]

Hi Stoyan,
please have a look at the Alpha Wrap plugin. It enables to visualize snapshots during the wrapping, and the process can be stopped.
You can contact @MaelRL direc;tly if you want more details.

[MaelRL]

You can also have a look at https://github.com/CGAL/cgal/blob/main/Alpha_wrap_3/examples/Alpha_wrap_3/pause_and_resume_wrapping.cpp.

Note that when you're interested in interrupting the wrapper, you should define the macro CGAL_AW3_USE_SORTED_PRIORITY_QUEUE, to use a queue that is sorted by facet size rather than a LIFO queue by default. The latter is faster, but then the wrapper carves deep rather than wide and an interrupted wrap with this strategy will likely not be very useful.

[sgayda2]

I think for my use case i am ok with not having usable results if i have to cancel as i am more worried about wasted compute/time as the user has already decided they don't want the result anyway.

[MaelRL]

Then you can you just plug your interrupter in the visitor like the example above and that should be sufficient.

And just to be maybe a bit clearer on "not usable" : whichever queue you use and whenever you interrupt, you will get a valid result in the sense that it will be a manifold, self-intersection-free mesh that contains the input. The difference is that if you use the sorted queue, the carving is homogeneous over the domain, as if you were using a smaller and smaller alpha (like on https://doc.cgal.org/latest/Alpha_wrap_3/aw3_bike_lod.jpg), whereas for the unsorted queue, you can imagine that a portion of the bike is already at its most refined level while the rest of the bike is still very coarse, which is likely not a very useful result. It's akin to BFS versus DFS.