Re: [deal.II] Hanging nodes of a read-in mesh
I see. I will try if I can find something. For now, the slowdown happens in the FGMRES solver by the way. Thanks! Feimi On Mon, Aug 10, 2020 at 10:41 AM Wolfgang Bangerth wrote: > 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. > > 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/e2611cf5-f3b2-b1c8-6f70-9930e2b99b73%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/CAMmJ624_rRV1XmQ2nPQezdLGQB02tbwfQzm8z9W6-wLeyGk6hQ%40mail.gmail.com.
Re: [deal.II] Hanging nodes of a read-in mesh
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. 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/e2611cf5-f3b2-b1c8-6f70-9930e2b99b73%40colostate.edu.
Re: [deal.II] Hanging nodes of a read-in mesh
Forgot to say, an FGMRES iterative solver On Monday, August 10, 2020 at 12:10:59 AM UTC-4, Feimi Yu wrote: > > I'm solving for a SUPG stabilized slightly compressible Navier-Stokes > equation, with a Schur complement type preconditioner. > > Feimi > > On Sun, Aug 9, 2020 at 11:16 PM Wolfgang Bangerth > wrote: > >> 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? >> >> Best >> W. >> -- >> >> Wolfgang Bangerth email: bang...@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 dea...@googlegroups.com . >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/dealii/8b2fa2ba-08a9-d5f2-fa65-54166a35ab9e%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/5c3a6421-0842-417f-bddb-4d223a53e598o%40googlegroups.com.
Re: [deal.II] Hanging nodes of a read-in mesh
I'm solving for a SUPG stabilized slightly compressible Navier-Stokes equation, with a Schur complement type preconditioner. Feimi On Sun, Aug 9, 2020 at 11:16 PM Wolfgang Bangerth wrote: > 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? > > 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/8b2fa2ba-08a9-d5f2-fa65-54166a35ab9e%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/CAMmJ624JjnfEq_%2B%2BZeNifB3CyN4vK1mi%3DPxmianJMg3Ax2Qb%2BQ%40mail.gmail.com.
Re: [deal.II] Hanging nodes of a read-in mesh
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? 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/8b2fa2ba-08a9-d5f2-fa65-54166a35ab9e%40colostate.edu.
Re: [deal.II] Hanging nodes of a read-in mesh
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 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.
Re: [deal.II] Hanging nodes of a read-in mesh
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.
[deal.II] Hanging nodes of a read-in mesh
Hi All, 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. 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. (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? 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/e5a13356-31da-45e5-97d5-4aebf058e9b9o%40googlegroups.com.
