[MOAB-dev] Reset pcomm

[Vijay S. Mahadevan]

Thanks for the update Lukasz. Good to know that recreating the pcomm
worked for your use case. Please let us know if you run into any
problems with the setup.

Vijay

On Tue, Nov 28, 2017 at 6:07 AM, Lukasz Kaczmarczyk
<Lukasz.Kaczmarczyk at glasgow.ac.uk> wrote:
> Thanks Vijay,
>
> Only to report, deleting and creating new pcomm, solved the problem.
>
> Lukasz
>
> On 27 Nov 2017, at 22:15, Lukasz Kaczmarczyk
> <Lukasz.Kaczmarczyk at glasgow.ac.uk> wrote:
>
> Hello,
>
> See attached figure. You can see red surface with is imprinted on the mesh.
> Surface is imprinted by edge splitting.  With this, I create  good quality
> mesh with node merging and flips. The surface is evolving and I solve PDE on
> it.
>
> What would you suggest, to create new pcomm on cloned mpi comm?
>
> Regards,
> Lukasz
>
>
> On 27 Nov 2017, at 22:06, Vijay S. Mahadevan <vijay.m at gmail.com> wrote:
>
> You could try calling the remove_pcomm to delete it from the global
> tag/internal set. Now calling add_pcomm should return a ParallelComm
> object with the same ID, potentially. This should theoretically help
> what you want to do, but I still don't entirely see the use of
> recreating the PComm object on the same MPI_Comm.
>
> Vijay
>
>
> On Mon, Nov 27, 2017 at 4:58 PM, Lukasz Kaczmarczyk
> <Lukasz.Kaczmarczyk at glasgow.ac.uk> wrote:
>
> Hello,
>
> Thanks for fast response. Yes, changes are in the original file set. On some
> subset of entities and new create new entities. I do mesh cutting with the
> arbitrary surface.
>
> Currently I resolve ents on that meshset, but before I reset tags,
> pstatus_tag(), sharedp_tag(), sharedps_tag(), sharedh_tag(), sharedhs_tag(),
> and in principle it works.  I do that on the same pcomm.
>
> I create pcomm like this
>
> ParallelComm *pcomm =
>        ParallelComm::get_pcomm(&moab, MYPCOMM_INDEX, &moab_comm_world);
>
> Is it a way to delete this and create a new pcomm on the same index?
>
> Regards,
> Lukasz
>
>
>
>
>
> On 27 Nov 2017, at 21:38, Vijay S. Mahadevan <vijay.m at gmail.com> wrote:
>
> Lukasz,
>
> Are the topological changes still part of the original file_set ? If
> yes, have you tried to just call resolve_shared_ents on that file set
> again ? Does this not solve the issue ? There is no global way to
> reset all the ParallelComm tags currently I think, but you could
> potentially create a new ParallelComm object spanning the same
> communicator as before and redo your operations on the older or a new
> file set containing the entity changes.
>
> Also, when you say repartition, do you mean dynamically load balance
> and redistribute entities ? If not, please explain.
>
> If neither of these suggestions are helpful, it would be useful if you
> can provide an example use case for us to better understand your
> workflow.
>
> Thanks,
> Vijay
>
> On Mon, Nov 27, 2017 at 4:02 PM, Lukasz Kaczmarczyk
> <Lukasz.Kaczmarczyk at glasgow.ac.uk> wrote:
>
> Hello,
>
> I do intense topological changes and need to keep precisely the same mesh an
> all procs, at least is the simplest solution.  I partition mesh and resolve
> shared entities. All calculations are distributed, and I build approx.
> fields only on partitions. It works great.
>
> However, I am not clear what is the best way to reset whole ParallelComm and
> ParallelComm tags, etc. and once again resolve shared entities. I
> repartition problem to balance mesh after some topological changes on the
> mesh. Can you give me any guidance and advice?
>
> Kind regards,
> Lukasz
>
>
> [University of Glasgow: The Times Scottish University of the Year 2018]
>
>
> <cut_sylinedr_with_holes.png>
>
>