p4est_partition_ext
Zlava opened this issue · comments
p4est_partition_ext and p4est_partition are currently doing the same thing. A useful thing the extended version could be doing is allowing the user to process the cells before they are sent and after they are recieved with callback functions just like p4est_refine_ext is is implemented (p8est_replace_t replace_fn).
I would also suggest another feature that is related to partitioning but is more controversial. It is splitting the cell user data into 2 structures. One is for user data that should be sent to another process if the cell is partitioned or with the ghost layer. Another is for user data that will never be sent to other processes and is for local use only.
Yes, they do, which has historical reasons. These functions are so fundamental that we are not changing them.
The functionality you suggest can be achieved by calling p4est_iterate with a volume callback only, before and after the partitioning.
You are free, and also encouraged, to create user-allocated per-quadrant data in your applicitation.
Should you require repartitioning part of this data, please consider the p4est_transfer functions.
Yes this is exactly what I was doing for the last few years (volume iterating and user allocation). Iterating only through cells that are to be sent is faster than iteration through all of them, but I get the reason it is as it is. Thanks for the answer!
Good point. In practice, however, most quadrants change process on partitioning. This is the basis for the near-optimal load balancing that we guarantee by partition, no matter how aggressively refinement and coarsening are designed by the caller, and entirely eliminating any dependence on refinement history.
So an optimization like the one suggested would be mostly theoretical.