Mesh Refinement & Periodic B.C.

56 views
Skip to first unread message

Stephen

unread,
Apr 7, 2021, 2:24:43 PM4/7/21
to deal.II User Group
Hi all,

Has anyone here successfully implemented mesh refinement for problems with (spatial) periodic boundary conditions before? If so, I'd welcome ideas on the best way to approach the problem. As far as I can tell, it is a requirement in deal.II for the elements on opposite sides of linked boundaries to be of the same size locally otherwise the constraints won't match and, I'd imagine, bad things would happen. What is the best way to maintain these constraints assuming an arbitrary refinement vector? I'm thinking the best approach is to just refine the mesh as normal then "patch it up" through a second sweep to ensure the mesh sizes on opposite sides of the linked boundaries are the same by forcing additional refinement if necessary.

Thanks,

Stephen

Wolfgang Bangerth

unread,
Apr 7, 2021, 3:10:38 PM4/7/21
to dea...@googlegroups.com
I think you should take a look at step-45 :-)
https://dealii.org/developer/doxygen/deal.II/step_45.html

Best
W.


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

Stephen

unread,
Apr 7, 2021, 3:48:22 PM4/7/21
to deal.II User Group
Thanks! I see they have mesh refinement in that tutorial. Maybe I misunderstood the way periodicity constraints work in deal.II; is it the case then that DoFTools::make_periodicity_constraints is able to automatically handle meshes in which the cells on periodic boundaries don't necessarily align?

Wolfgang Bangerth

unread,
Apr 7, 2021, 6:00:34 PM4/7/21
to dea...@googlegroups.com
On 4/7/21 1:48 PM, Stephen wrote:
> Thanks! I see they have mesh refinement in that tutorial. Maybe I
> misunderstood the way periodicity constraints work in deal.II; is it the case
> then that DoFTools::make_periodicity_constraints is able to automatically
> handle meshes in which the cells on periodic boundaries don't necessarily align?

I forgot how this work in the sequential case (Matthias?) but in the parallel
case, you can tell the triangulation that certain boundaries are periodic and
then the triangulation makes sure that the cells differ by at most one level
of refinement. The make_periodicity_constraints() function can deal with this.

Jean-Paul Pelteret

unread,
Apr 8, 2021, 3:35:32 PM4/8/21
to dea...@googlegroups.com
Hi Stephen,

I know that Wolfgang has already answered you and has mentioned that having the refinement levels differ across periodic interfaces is permitted. At some point I wanted to ensure that they were identical, and I wrote a little function to do that and have pasted it below just in case its of any use to you. From this part of you question

elements on opposite sides of linked boundaries to be of the same size locally otherwise the constraints won't match

I’m curious to know if you mean that the elements must be conformal across the interface? There seems to be a wide body of literature that discusses the weak imposition of periodic constraints, so I guess if you take that approach then there’s (probably) no specific requirements for the mesh to match across the interface.

Best,
Jean-Paul


template <int dim>
void
add_periodic_refinement_signals(Triangulation<dim> &triangulation)
{
// Before refining we ensure that periodic face pairs have the same
// refinement flag.
{
auto signal_periodic_faces_symmetric_marking = [&triangulation]() -> void {
for (typename Triangulation<dim>::active_cell_iterator cell = triangulation.begin_active(); cell != triangulation.end(); ++cell)
{
for (unsigned int face = 0; face < GeometryInfo<dim>::faces_per_cell; ++face)
{
if (cell->has_periodic_neighbor(face))
{
if (cell->refine_flag_set())
{
cell->periodic_neighbor(face)->clear_coarsen_flag();
cell->periodic_neighbor(face)->set_refine_flag();
}
else if (cell->periodic_neighbor(face)->refine_flag_set())
{
cell->clear_coarsen_flag();
cell->set_refine_flag();
}
else if (cell->coarsen_flag_set())
{
cell->periodic_neighbor(face)->clear_refine_flag();
cell->periodic_neighbor(face)->set_coarsen_flag();
}
else if (cell->periodic_neighbor(face)->coarsen_flag_set())
{
cell->clear_refine_flag();
cell->set_coarsen_flag();
}
}
}
}

// Its quite possible that, after all of this, we violate some
// of the 2:1 cell level ratio expectations... Thats this error:
// An error occurred in line <12816> of file <.../dealii/source/grid/tria.cc> in function
// virtual bool dealii::Triangulation<2, 2>::prepare_coarsening_and_refinement() [dim = 2, spacedim = 2]
// The violated condition was:
// cell_is_patch_level_1(cell)
// To fix this, we make the following call:
triangulation.prepare_coarsening_and_refinement();
};

// Add signals
triangulation.signals.pre_refinement.connect(signal_periodic_faces_symmetric_marking);
}
}

--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups "deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dealii+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/21c92dac-55de-4ef8-89c7-f3aee063c1a4n%40googlegroups.com.

Stephen

unread,
Apr 10, 2021, 9:13:05 PM4/10/21
to deal.II User Group
I just basically wanted to ensure that the code would work if there were hanging nodes on the boundary but it looks like the deal.II library already takes care of that; still your code could be useful if I decide  to go down that route so thanks!
Reply all
Reply to author
Forward
0 new messages