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 On Sun, Aug 9, 2020 at 7:47 PM Wolfgang Bangerth <bange...@colostate.edu> wrote: > 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: bange...@colostate.edu > www: http://www.math.colostate.edu/~bangerth/ > > -- > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/dealii/a66b9374-6612-d30b-e1b4-1eb6ee9ea505%40colostate.edu > . > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/CAMmJ626qzTJHF0Puy6iMtSQqfCXgwfrSMOU%2B%3DBMtg4rXh%3DTQgg%40mail.gmail.com.
