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.
-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 >> >
