Parallel issue with an HP-refinement FEM Poisson problem

[Mikael Vaillant]

Hi everyone,

We are currently working on a prototype to solve a Poisson non-linear problem using hp-refinement. The prototype was first tested using a linear equation. The problem is that we obtain multiple non-linear newton iterations to solve our linear equation after a couple of adaptation steps. This issue appears only when running the code in parallel. We don't have the problem when running the code using only p refinement, only h refinement or with certain geometries. We based our prototype on the step-75 but have not been able to identify if the issue is contained within our code. We found the issue appears when two cells sharing a vertex and that are not part of the same subdomain have an FE degree difference of more than two or when the first one has a p-refinement and an h-refinement superior than a cell sharing its vertex.

Here are some pictures of the outputted results in Paraview. A threshold is applied to look at some cells where the residual is abnormally high.

I was wondering if functions such as limit_p_level_difference() allow for cases where a neighbouring cell sharing a vertex has a polynomial order difference of more than 2? Im also wondering why this problem is only appearing in parallel. I'm looking for any insight that could help me understand what could cause this issue.

Thank you,

Mikael 

[Mikael Vaillant]

Hello again,

We found the issue thanks to Peter Munch. When setting up our problem, we can use the function make_consistent_in_parallel() with our constraints after the line constraints.close(). If the Deal.II team think it's appropriate, I could submit a small PR next week to add this line and a quick explanation to the step-75 tutorial so others don't run into the same issue in the future. 

Thank you,

Mikael

[Wolfgang Bangerth]

On 4/25/25 09:32, Mikael Vaillant wrote:
>
> We found the issue thanks to Peter Munch. When setting up our problem, we can
> use the function make_consistent_in_parallel() with our constraints after the
> line constraints.close(). If the Deal.II team think it's appropriate, I could
> submit a small PR next week to add this line and a quick explanation to the
> step-75 tutorial so others don't run into the same issue in the future.

Yes, please.
Best
W.

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

[Marc Fehling]

Hello Mikael,

> We found the issue appears when two cells sharing a vertex and that are not part of the same subdomain have an FE degree difference of more than two or when the first one has a p-refinement and an h-refinement superior than a cell sharing its vertex.

> We found the issue thanks to Peter Munch. When setting up our problem, we can use the function make_consistent_in_parallel() with our constraints after the line constraints.close().

This indeed sounds like a constraints issue. You can verify whether your constraints are consistent among all processes with the function is_consistent_in_parallel().

So far we encountered these types of inconsistencies only on 3d domains. You can correct them with make_consistent_in_parallel(), as you already found out.

> If the Deal.II team think it's appropriate, I could submit a small PR next week to add this line and a quick explanation to the step-75 tutorial so others don't run into the same issue in the future.

It is best practice to ensure that constraints are consistent. I agree that we should add this to step-75. Feel free to write a patch for it! (Please mention that this is technically only necessary for 3d problems.)

> I was wondering if functions such as limit_p_level_difference() allow for cases where a neighbouring cell sharing a vertex has a polynomial order difference of more than 2?

The function limit_p_level_difference() only compares the polynomial degrees of finite elements that are neighbors over faces. Thus over edges, the difference of polynomial degrees can be twice as high as the prescribed max_difference.

Thanks,
Marc