Am 07.07.22 um 15:05 schrieb Mark Adams:
On Thu, Jul 7, 2022 at 7:03 AM Karabelas, Elias ([email protected]<mailto:[email protected]>) <[email protected]<mailto:[email protected]>> wrote: OK got it, well the "classical" option of GAMG removes this issue, and also HYPRE does that out-of-the box. Humm, so you are using hypre in PETSc with a Krylov KSP or using hypre directly. GAMG uses a polynomial smoother by default and hypre does not, I believe. That could be the difference, but I would think the outer Krylov in PETSc would still pollute this. So the outer Krylov doesn't seem to pollute either for hypre or using gamg classical this is an example output from those two (vtu file) (gmres as krylov and either hypre or gamg classical as pctype) <DataArray type="Float32" format="ascii" NumberOfComponents="3" Name="displacement"> 0 0 0 0.182029 0 0 0.223618 0 0 0.250511 0 0 0.209325 0 0 0 0.182029 0 0.1305 0.1305 0 and this for gamg with smoothed aggregation (gmres as krylov and gamg agg) <DataArray type="Float32" format="ascii" NumberOfComponents="3" Name="displacement"> 0 0 0 0.0905508 -5.2019e-05 6.4198e-05 0.173765 -4.34019e-05 5.86626e-05 0.256981 -4.14403e-05 2.78863e-05 0.233807 -3.94787e-05 -2.88998e-06 -4.78464e-05 0.0905198 6.21817e-05 0.0819423 0.0820083 4.89063e-05 So the difference is noticeable. If you are using hypre directly, I could imagine that they take the residual that they compute to check convergence and do a quick update of the solution, with the diagonal that they have access to, with u = u + D^-1 r (this is the sort of clever thing they would do) I would slightly disagree with non-exact DirichletBCs, especially in mechanics where I really assume a clamped node is clamped. I'm not saying exactness is not important (to you), I'm just saying many people seem to live with it. Best Elias Am 07.07.22 um 13:00 schrieb Mark Adams: I think PCCOMPOSITE is overkill here. First, I would only bother with this if this error is a problem. People use your method all the time and accept error at the scale of the solver tolerance. But if you want the exact solution, well, you could just clobber the solution values after the solve if you have access to the Diri BC data on hand. I was suggesting just creating a "Richardson/jacobi" solver, hardwire one iteration, use an initial guess and solve it. Not great, because this would have to grab the diagonal. If you had the diagonal (eg, from the AMG smoother that does exist) then this would be pretty cheap (a residual calculation mostly). Mark On Thu, Jul 7, 2022 at 3:14 AM Karabelas, Elias ([email protected]<mailto:[email protected]>) <[email protected]<mailto:[email protected]>> wrote: Hi Mark, thanks for the answer, but I'm struggling to translate your suggestion into solver options. From scrolling through the user manual I think this points towards PCCOMPOSITE. However, the User Manual is not very precise with composite PCs, so how would I achieve this on top of my existing solver options? Best regards Elias Am 06.07.22 um 16:41 schrieb Mark Adams: And one iteration of undamped Jacobi after the solve should fix this. On Wed, Jul 6, 2022 at 8:42 AM Karabelas, Elias ([email protected]<mailto:[email protected]>) <[email protected]<mailto:[email protected]>> wrote: Dear Matt, thanks for the fast response. That makes perfect sense to me. Best regards Elias Am 06.07.22 um 14:35 schrieb Matthew Knepley: On Wed, Jul 6, 2022 at 7:46 AM Karabelas, Elias ([email protected]<mailto:[email protected]>) <[email protected]<mailto:[email protected]>> wrote: Dear all, I don't know if this is a bug, but I observed that when using GMRES with AGG-PCGAMG as preconditioner Dirichlet boundary conditions don't seem to be exactly fulfilled. My Matrix has zero rows and cols with 1 on the diagonal where I have dirichlet-bcs in my FE-mesh and I would expect that the eqs in this rows can be exactly fulfilled (as u_i = g_i) there. I would not expect aggregation to be exact here, but only within the iteration tolerance. If instead you eliminate those variables, you can maintain algebraic exactness. This is what we do in examples, like SNES ex56. Thanks, Matt However, when I solve A*x = b with the above solver I only get u_i = g_i + error in that part of the vector. Switching from pc_gamg_type agg to pc_gamg_type classical cures this problem, but the classical is not advertised in the user manual. These are the options I'm currently using: -ksp_type gmres -ksp_pc_side right -pc_type gamg -pc_gamg_type agg [or classical] -pc_gamg_sym_graph 1 -pc_gamg_square_graph 1 -pc_gamg_agg_nsmooths 1 -pc_gamg_threshold 0.01 -pc_mg_cycles v Iteration counts are basically the same. Best regards Elias -- Dr. Elias Karabelas Research Associate University of Graz Institute of Mathematics and Scientific Computing Heinrichstraße 36 A-8010 Graz Austria Phone: +43 316 380 8546 Email: [email protected]<mailto:[email protected]> Web: https://ccl.medunigraz.at/ -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener https://www.cse.buffalo.edu/~knepley/<http://www.cse.buffalo.edu/~knepley/> -- Dr. Elias Karabelas Research Associate University of Graz Institute of Mathematics and Scientific Computing Heinrichstraße 36 A-8010 Graz Austria Phone: +43 316 380 8546 Email: [email protected]<mailto:[email protected]> Web: https://ccl.medunigraz.at/ -- Dr. Elias Karabelas Research Associate University of Graz Institute of Mathematics and Scientific Computing Heinrichstraße 36 A-8010 Graz Austria Phone: +43 316 380 8546 Email: [email protected]<mailto:[email protected]> Web: https://ccl.medunigraz.at/ -- Dr. Elias Karabelas Research Associate University of Graz Institute of Mathematics and Scientific Computing Heinrichstraße 36 A-8010 Graz Austria Phone: +43 316 380 8546 Email: [email protected]<mailto:[email protected]> Web: https://ccl.medunigraz.at/ -- Dr. Elias Karabelas Research Associate University of Graz Institute of Mathematics and Scientific Computing Heinrichstraße 36 A-8010 Graz Austria Phone: +43 316 380 8546 Email: [email protected]<mailto:[email protected]> Web: https://ccl.medunigraz.at/
