This is fine. PCGAMG does algebraic multigrid so the mesh doesn't matter in its use.
Barry > On Mar 26, 2015, at 11:20 AM, Manav Bhatia <[email protected]> wrote: > > Thanks. > Quick question (out of ignorance): does it matter that the HEX8 may still be > arranged in an unstructured fashion? Meaning, that although I use brick > elements, my grid does not have a structured grid appearance. > > -Manav > > >> On Mar 26, 2015, at 11:14 AM, Barry Smith <[email protected]> wrote: >> >> >>> On Mar 26, 2015, at 10:51 AM, Manav Bhatia <[email protected]> wrote: >>> >>> Barry, >>> >>> On a related note, I have another elasticity problem that I am trying to >>> solver with HEX8 elements. It is an isotropic solid structure. Do you have >>> a recommended preconditioned for this problem? >> >> Yes, this one clearly requires PCGAMG. Make sure you read all the docs on >> PCGMAG, you will need to supply either the coordinates with >> PCSetCoordiantes() or the near null space of the operator. Unfortunately our >> documentation for this sucks and everyone refuses to improve it. >> >> Barry >> >> >> >>> >>> The problem has about 770K dofs and the default ILU(0) has not done well. >>> I have also tried ILU(1), and that too has been unhelpful. I am observing >>> stagnation of residuals after a drop of couple of magnitudes. >>> >>> Any recommendations would be greatly appreciated. >>> >>> Thanks, >>> Manav >>> >>> >>> >>> >>> >>> >>>> On Mar 26, 2015, at 10:35 AM, Barry Smith <[email protected]> wrote: >>>> >>>> >>>>> On Mar 26, 2015, at 10:19 AM, Manav Bhatia <[email protected]> wrote: >>>>> >>>>> Thanks, Barry. I will try that. >>>>> >>>>> This is Euler flow equations discretized with SUPG. The mesh is made of >>>>> 4-noded tetrahedra. The flow parameters correspond to transonic flow. >>>> >>>> Yes, ILU could easily fail on this and really isn't appropriate. Likely >>>> you should be using PCFIELDSPLIT for preconditioning. >>>> >>>> Barry >>>> >>>>> >>>>> -Manav >>>>> >>>>> >>>>>> On Mar 26, 2015, at 10:17 AM, Barry Smith <[email protected]> wrote: >>>>>> >>>>>> >>>>>> The default preconditioner with ILU(0) on each process is not >>>>>> appropriate for your problem and is producing overflow. Try -sub_pc_type >>>>>> lu and see if that produces a different result. >>>>>> >>>>>> Is this a Stokes-like problem? >>>>>> >>>>>> Barry >>>>>> >>>>>>> On Mar 26, 2015, at 10:10 AM, Manav Bhatia <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>> Thanks, Matt. >>>>>>> >>>>>>> Following is the output with: -ksp_monitor_lg_residualnorm -ksp_log >>>>>>> -ksp_view -ksp_monitor_true_residual -ksp_converged_reason >>>>>>> >>>>>>> 0 KSP preconditioned resid norm inf true resid norm >>>>>>> 2.709083260443e+06 ||r(i)||/||b|| 1.000000000000e+00 >>>>>>> Linear solve did not converge due to DIVERGED_NANORINF iterations 0 >>>>>>> KSP Object: 12 MPI processes >>>>>>> type: gmres >>>>>>> GMRES: restart=30, using Classical (unmodified) Gram-Schmidt >>>>>>> Orthogonalization with no iterative refinement >>>>>>> GMRES: happy breakdown tolerance 1e-30 >>>>>>> maximum iterations=1000 >>>>>>> tolerances: relative=1e-10, absolute=1e-50, divergence=10000 >>>>>>> left preconditioning >>>>>>> using nonzero initial guess >>>>>>> using PRECONDITIONED norm type for convergence test >>>>>>> PC Object: 12 MPI processes >>>>>>> type: bjacobi >>>>>>> block Jacobi: number of blocks = 12 >>>>>>> Local solve is same for all blocks, in the following KSP and PC objects: >>>>>>> KSP Object: (sub_) 1 MPI processes >>>>>>> type: preonly >>>>>>> maximum iterations=10000, initial guess is zero >>>>>>> tolerances: relative=1e-05, absolute=1e-50, divergence=10000 >>>>>>> left preconditioning >>>>>>> using NONE norm type for convergence test >>>>>>> PC Object: (sub_) 1 MPI processes >>>>>>> type: ilu >>>>>>> ILU: out-of-place factorization >>>>>>> 0 levels of fill >>>>>>> tolerance for zero pivot 2.22045e-14 >>>>>>> using diagonal shift on blocks to prevent zero pivot [INBLOCKS] >>>>>>> matrix ordering: natural >>>>>>> factor fill ratio given 1, needed 1 >>>>>>> Factored matrix follows: >>>>>>> Mat Object: 1 MPI processes >>>>>>> type: seqaij >>>>>>> rows=667070, cols=667070 >>>>>>> package used to perform factorization: petsc >>>>>>> total: nonzeros=4.6765e+07, allocated nonzeros=4.6765e+07 >>>>>>> total number of mallocs used during MatSetValues calls =0 >>>>>>> using I-node routines: found 133414 nodes, limit used is 5 >>>>>>> linear system matrix = precond matrix: >>>>>>> Mat Object: () 1 MPI processes >>>>>>> type: seqaij >>>>>>> rows=667070, cols=667070 >>>>>>> total: nonzeros=4.6765e+07, allocated nonzeros=5.473e+07 >>>>>>> total number of mallocs used during MatSetValues calls =0 >>>>>>> using I-node routines: found 133414 nodes, limit used is 5 >>>>>>> linear system matrix = precond matrix: >>>>>>> Mat Object: () 12 MPI processes >>>>>>> type: mpiaij >>>>>>> rows=6723030, cols=6723030 >>>>>>> total: nonzeros=4.98852e+08, allocated nonzeros=5.38983e+08 >>>>>>> total number of mallocs used during MatSetValues calls =0 >>>>>>> using I-node (on process 0) routines: found 133414 nodes, limit used is >>>>>>> 5 >>>>>>> >>>>>>> >>>>>>> Anything jumps out at you as odd? >>>>>>> >>>>>>> -Manav >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Mar 26, 2015, at 9:34 AM, Matthew Knepley <[email protected]> wrote: >>>>>>>> >>>>>>>> On Thu, Mar 26, 2015 at 9:21 AM, Manav Bhatia <[email protected]> >>>>>>>> wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I am using the KSP linear solver for my system of equations, without >>>>>>>> any command line options at this point. I have checked that the L1 >>>>>>>> norms of my system matrix and the force vector are finite values, but >>>>>>>> the KSP solver is returning with an “inf” residual in the very first >>>>>>>> iteration. >>>>>>>> >>>>>>>> The problem has 6.7M dofs and I have tried this on multiple machines >>>>>>>> with different number of nodes with the same result. >>>>>>>> >>>>>>>> Is there a reason why the solver would return after the first >>>>>>>> iteration with an inf? >>>>>>>> >>>>>>>> I am not sure on where to start debugging this case, so I would >>>>>>>> appreciate any pointers. >>>>>>>> >>>>>>>> For all solver questions, we want to see the output of >>>>>>>> >>>>>>>> -ksp_view -ksp_monitor_true_residual -ksp_converged_reason >>>>>>>> >>>>>>>> The problem here would be that there is an error, so we would never >>>>>>>> see the output >>>>>>>> of -ksp_view and know what solver you are using. If you are using >>>>>>>> something complex, >>>>>>>> can you try using >>>>>>>> >>>>>>>> -pc_type jacobi >>>>>>>> >>>>>>>> and send the output from the options above? Then we can figure out why >>>>>>>> the other solver >>>>>>>> gets an inf. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Matt >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Manav >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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 >>>>>>> >>>>>> >>>>> >>>> >>> >> >
