Question on transferring adaptive refinement

[Artur Safin]

Hello,

I am implementing a sequence of two simulations using a global mesh that contains both a fluid and a structure. My first simulation (elasticity equation) involves only the structure subdomain, and so I intend to run it on the structure submesh (by extracting it from the global mesh using GridGenerator::create_triangulation_with_removed_cells for instance), and the second simulation will be done on the entire mesh.

Before starting my second simulation, I will have to transfer the adaptive refinement from the structure submesh from my first simulation to the corresponding subdomain in the global mesh. This is the part that I am not sure how to implement. I am also using the p::d::triangulation class, which further complicates things, as the refinements may be split across multiple processors.

The only idea I can come up with is to associate refinement with a physical point in the domain. After solving the elasticity eq-n, I would cycle through the coarsest level of a triangulation, and store the cell->center() point with the cell's refinement history into some file. For the second simulation on the global mesh, each cell would have to find its counterpart from the first simulation by making sure their center points match, and then load in the refinement. While possible, this seems a bit like an overkill.

So I am curious if there is a better alternative than what I'm thinking of. Any suggestions?

Thanks,

Artur

[Daniel Arndt]

Artur,

Depending on how much the structure subdomain differs from the entire domain, it might be a good idea to just solve the elasticity equation on the whole mesh and impose constraints on inner dofs (at the interface between fluid and structure domain) that correspond to the boundary constraints for the problem restricted to the structure subdomain. This way solving the first simulation gets more expensive but you save on transferring the solution vector afterwards.

Best,

Daniel

[Wolfgang Bangerth]

On 09/27/2017 09:49 PM, Artur Safin wrote:
>
> The only idea I can come up with is to associate refinement with a
> physical point in the domain. After solving the elasticity eq-n, I would
> cycle through the coarsest level of a triangulation, and store the
> cell->center() point with the cell's refinement history into some file.
> For the second simulation on the global mesh, each cell would have to
> find its counterpart from the first simulation by making sure their
> center points match, and then load in the refinement. While possible,
> this seems a bit like an overkill.
>
> So I am curious if there is a better alternative than what I'm thinking
> of. Any suggestions?

A better quantity to compare is cell->id() that returns a CellID object
that is globally unique in a parallel distributed triangulation and that
avoids the comparison of floating point numbers you have when looking at
the center of cells.

In general, I think Daniel is right that if you can avoid transferring
data between parallel distributed meshes, then that is the way to go.
It's just too cumbersome and inefficient to do so.

Best
W.


--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

[Artur Safin]

Daniel, Wolfgang,

Thank you for the answers!

Out of curiosity, there is support for saving and loading refinement using save_refine_flags() and load_refine_flags() in the triangulation class. Am I correct to assume that these functions are not designed to work with a p::d::triangulation?

Artur

[Wolfgang Bangerth]

On 10/04/2017 02:37 PM, Artur Safin wrote:
>
> Out of curiosity, there is support for saving and loading refinement

> using /save_refine_flags/() and /load_refine_flags/() in the

> triangulation class. Am I correct to assume that these functions are not
> designed to work with a p::d::triangulation?

It will work for a p::d::Triangulation *on each processor separately*.
That may or may not be what you want to do, though.