Re: [deal.II] Hanging nodes of a read-in mesh

[Wolfgang Bangerth]

On 8/9/20 1:58 PM, Feimi Yu wrote:
>
> I am doing a grid study of a 2D mesh. At first I simply applied a local
> refinement in the code for a specific region,
> but it turns out this caused the load to be unbalanced among the ranks (the
> rank carrying the refined mesh is much more loaded than others)
> and the computation became very slow.

Are you partitioning the mesh yourself, or are doing different things on
different parts of the domain? I'm assuming that you are using
parallel::distributed::Triangulation, which automatically partitions the mesh
so that every process has roughly the same number of cells.


> Then I tried refine the mesh and output
> it as a file, then read it in as regular mesh.
> This time it seems that the hanging nodes are not properly treated.

Yes. That's because the mesh format does not record which cells neighbor which
cells. The only way to re-construct this kind of neighborship relationship is
by checking which cells share a common face -- which refined children do not
with their parent's neighbor.


> (DoFTools::make_hanging_node_constraints() only search for cells
> that have children, which is lost after the I/O I did). Is there any way to
> resolve this problem, by either re-balance the
> computation load after local refinement or make the solver realize the hanging
> nodes?

Writing out and reading in will not work. The question is why your mesh is not
load balanced.

Best
W.


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

[Feimi Yu]

Hi Wolfgang,

I realized something after I posted my question, so I removed it after a while. Sorry that my original post is not shown in the thread. After checking the output block IDs in ParaView I found that it was not

the unbalanced load that caused the slow computation, but somehow the hanging nodes themselves, which caused the change of condition number in the system matrix. So I think the best way to resolve

this might be to re-mesh my domain and get rid of the hanging nodes if there is no better solution for it.

Thanks!

Feimi

--
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/a66b9374-6612-d30b-e1b4-1eb6ee9ea505%40colostate.edu.

[Wolfgang Bangerth]

On 8/9/20 7:22 PM, Feimi Yu wrote:
>
> I realized something after I posted my question, so I removed it after a
> while. Sorry that my original post is not shown in the thread. After checking
> the output block IDs in ParaView I found that it was not
> the unbalanced load that caused the slow computation, but somehow the hanging
> nodes themselves, which caused the change of condition number in the system
> matrix.

No, that too isn't your problem. Hanging nodes don't make the condition number
significantly worse. What's the equation you're solving, and what's your
solver and preconditioner?

[Feimi Yu]

I'm solving for a SUPG stabilized slightly compressible Navier-Stokes equation, with a Schur complement type preconditioner.

Feimi

--
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/8b2fa2ba-08a9-d5f2-fa65-54166a35ab9e%40colostate.edu.

[Feimi Yu]

Forgot to say, an FGMRES iterative solver

To unsubscribe from this group and stop receiving emails from it, send an email to dea...@googlegroups.com.

[Wolfgang Bangerth]

On 8/9/20 10:10 PM, Feimi Yu wrote:
> I'm solving for a SUPG stabilized slightly compressible Navier-Stokes
> equation, with a Schur complement type preconditioner.

I don't see why hanging nodes would make any kind of difference for this
combination (in fact, for any equation). If I were you, I'd try to dig a bit
further to come up with concrete evidence that the hanging nodes are your
problem (I suspect that the problem is actually elsewhere) and then see how to
address this. Having used hanging nodes for 23 years now, your hypothesis
sounds unlikely to me.

[Feimi Yu]

I see. I will try if I can find something. For now, the slowdown happens in the FGMRES solver by the way. Thanks!

Feimi

--
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/e2611cf5-f3b2-b1c8-6f70-9930e2b99b73%40colostate.edu.