Dear Saleh,
I think that the answer to your question mostly depends on your solver and your applications.
The algorithm for parallel remeshing implemented in ParMmg is best suited for the adapted generation of large meshes that you could not handle on a single machine due to memory limitations.
Since the algorithm performs several iterations of internal domain remeshing (with no adaptation on parallel interfaces) and mesh redistribution (to move previous parallel interfaces inside the domain to be remeshed), you could expect suboptimal performances on small cases running on few cores. Anyway, in this case the parallel remeshing performances should be compared with the cost of keeping in your solver the sequential bottleneck of gathering the mesh on a single process to sequentially remesh it, with the additional data structures communication/reconstruction that happens in the solver.
I could suggest, if you are already coupling the sequential version, to test the sequential adaptation with Mmg to assess your needs, measure the cost of the sequential bottleneck in your solver, and assess the results of ParMmg by command line.
Please keep in mind that ParMmg currently does not support all the features of Mmg3d, notably the Lagrangian motion, but should have no problems in adapting internal domains with body-fitted fixed boundaries if the metrics is not too anisotropic.
Also, the ParMmg API is basically conceived as an extension of the Mmg3d API. So, once you get accustomed to Mmg3d library functions, moving to ParMmg should not be too far from changing some function prefixes and adding the specific ParMmg functions needed to setup the parallel mesh interfaces.
Hope this helps,
Luca
