cells that not been marked but refined

[Lei Qiao]

Dear all,

 

I noticed this problem because more cells than required are refined.

After some investigations I found there are some cells that not are marked to refine 

actually refined after execute_coarsening_and_refinement ().

Here is the pictures before 

and after 

cell refinement.  The refine_flag in picture is mapped to bool

and not the exact return value of cell->refine_flag_set().

In the above figures, the two cells that marked by green point are not marked

 to refine but refined after execute_coarsening_and_refinement ().

The used  triangulation type is parallel::distributed::Triangulation<dim> and 

the triangulation object is initialized with default Smoothing flags which should be "none".

Moreover, the above showed refinement flags are outputted immediately after

prepare_coarsening_and_refinement() and before execute_coarsening_and_refinement

within a loop.

Although the distributed triangulation, this result is produced with only one process.

The refinement behavior looks like the smoothing flag "limit_level_difference_at_vertices"

is set, but I think this should not happen with MeshSmoothing = none.

Does this imply there may be something wrong in parallel::distributed::Triangulation<dim>,

or just in my understanding?

Best,

Lei

[Timo Heister]

Interesting, maybe we never checked this. Can you go and test if the following patch works? (ultimately we should do CONNECT_FULL if the limit_level_difference flag is set and CONNECT_FACE otherwise):

diff --git a/source/distributed/tria.cc b/source/distributed/tria.cc

index 9b16877..bbffbd9 100644

--- a/source/distributed/tria.cc

+++ b/source/distributed/tria.cc

@@ -3551,10 +3551,10 @@ namespace parallel

                (dim == 2

                 ?

                 typename dealii::internal::p4est::types<dim>::

-                balance_type(P4EST_CONNECT_FULL)

+                balance_type(P4EST_CONNECT_FACE)

                 :

                 typename dealii::internal::p4est::types<dim>::

-                balance_type(P8EST_CONNECT_FULL)),

+                balance_type(P8EST_CONNECT_FACE)),

                /*init_callback=*/NULL);

--
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.
For more options, visit https://groups.google.com/d/optout.

--

Timo Heister
http://www.math.clemson.edu/~heister/

[Lei Qiao]

On Monday, September 21, 2015 at 12:49:40 PM UTC-5, Timo Heister wrote:

Interesting, maybe we never checked this. Can you go and test if the following patch works?:

diff --git a/source/distributed/tria.cc b/source/distributed/tria.cc

index 9b16877..bbffbd9 100644

--- a/source/distributed/tria.cc

+++ b/source/distributed/tria.cc

@@ -3551,10 +3551,10 @@ namespace parallel

                (dim == 2

                 ?

                 typename dealii::internal::p4est::types<dim>::

-                balance_type(P4EST_CONNECT_FULL)

+                balance_type(P4EST_CONNECT_FACE)

                 :

                 typename dealii::internal::p4est::types<dim>::

-                balance_type(P8EST_CONNECT_FULL)),

+                balance_type(P8EST_CONNECT_FACE)),

                /*init_callback=*/NULL);

This patch works partially, say, only for the upper left one of the two cells.

This in more weird than the original case.

The difference I can tell is that the lower right cell has a refined face neighbor

while upper left one doesn't. But this done't break the 2:1 hanging node limit.

 (ultimately we should do CONNECT_FULL if the limit_level_difference flag is set and CONNECT_FACE otherwise)

 

I think execute_coarsening_and_refinement() should concern nothing about mesh smoothing, which should be done

in prepare_coarsening_and_refinement(). The function execute_coarsening_and_refinement() just has to refine and coarsen cells

blindly according to corresponding flags.

So, does something like "balance_type(P4EST_CONNECT_NONE)" available?

Best,

Lei

[Lei Qiao]

The difference I can tell is that the lower right cell has a refined face neighbor

while upper left one doesn't.

 Should be "a newly refined face neighbor", the existing refined face neighbor can 

 not get cell refined.

[Timo Heister]

> I think execute_coarsening_and_refinement() should concern nothing about
> mesh smoothing, which should be done
> in prepare_coarsening_and_refinement(). The function
> execute_coarsening_and_refinement() just has to refine and coarsen cells
> blindly according to corresponding flags.

This is not enough. The problem is that even if each processor locally
adjusts the flags to adhere to the smoothing flags, the global mesh
might still violate that condition.

> So, does something like "balance_type(P4EST_CONNECT_NONE)" available?

No, but FACE should do the correct thing (only enforce 2-1 across
faces). I have no idea why it doesn't work for you.

[Lei Qiao]

Thank you. 

I will try to create a simplest test case that can reproduce this phenomena.

[Lei Qiao]

I created a small test case, and found the refinement behavior is related to whether the cells are belonging to one tree or not,

even with the patch using "balance_type(P4EST_CONNECT_FACE)".

If I initialize the triangulation by 

      std::vector<unsigned int> repetitions;
      repetitions.push_back (2);
      repetitions.push_back (2);
      const Point<dim> p1 (0, 0);
      const Point<dim> p2 (1, 1);
      GridGenerator::subdivided_hyper_rectangle (triangulation,
                                                 repetitions,
                                                 p1,
                                                 p2);

then the extra refinement will happen:

-> 

And if I initialize the triangulation by

    GridGenerator::hyper_cube(triangulation);
      triangulation.refine_global(1);

then no extra refinement  occurs :

->

But I have no idea on why this happens and how to prevent the extra refinement. 

What an annoying issue.

Attached is the source code of the test.