I think the general principle should be to minimize how much the user needs to know about DIY, while still allowing full access. This means on the one hand preserving tess(master), which assumes the blocks are prepared in the dblock_t format, while providing convenience functions that simply take points as input.
Create a function akin to tess(world, points), which would set up its own master (from the world communicator), redistribute the points, and compute the Delaunay triangulation. The user would simply get the local points (resulting from the redistribution) and local tetrahedra in return. Or maybe it's Ok to return the local dblock_ts; that much exposure to the internals should be Ok.
Move redistribute() from examples/pread-voronoi/pread-voronoi.cpp into the main tess library.
Create a simpler tess(master) that sets up its own quants and times. As interesting as those are to us, the users probably wouldn't care about them, so no need to expose them in an API.
Issue by Dmitriy Morozov Saturday Nov 22, 2014 at 22:00 GMT
I think the general principle should be to minimize how much the user needs to know about DIY, while still allowing full access. This means on the one hand preserving
tess(master), which assumes the blocks are prepared in thedblock_tformat, while providing convenience functions that simply take points as input.tess(world, points), which would set up its own master (from theworldcommunicator), redistribute the points, and compute the Delaunay triangulation. The user would simply get the local points (resulting from the redistribution) and local tetrahedra in return. Or maybe it's Ok to return the localdblock_ts; that much exposure to the internals should be Ok.redistribute()fromexamples/pread-voronoi/pread-voronoi.cppinto the main tess library.tess(master)that sets up its ownquantsandtimes. As interesting as those are to us, the users probably wouldn't care about them, so no need to expose them in an API.