Travis : "SAME_NONZERO_PATTERN" should be used in your case. It is likely a bug that causes the segmentation violation.
Which packages do you use, superlu (sequential) or superlu_dist (parallel)? superlu_dist does not support ilu. Are you using latest petsc-dev? We fixed bugs in petsc-dev and reset default superlu_dist options. Please try 1) use petsc-dev 2) turn off superlu_dist options with runtime options '-mat_superlu_dist_equil NO -mat_superlu_dist_rowperm NATURAL -mat_superlu_dist_colperm NATURAL ' 3) try parallel direct solver mumps Let us know what you get. Hong > I ran into the following problem when trying to use superlu_dist as a > preconditioner for matrix free SNES with GMRES in my high order Navier > Stokes solver: > > I set the nonzero pattern of my preconditioner matrix at the begging of a > simulation (t=0). The overall stencil of the numerical method never changes, > so the nonzero pattern should never change. I use an implicit Runge Kutta > scheme to advance the solution in time. The preconditioning matrix is the > frozen jacobian at the start of a time step. The same preconditioner is used > for every stage of the RK scheme. After one time step is complete, the > preconditioner matrix is calculated for the new time step. > > The problem I am having with superlu_dist is that if I use > SAME_NONZERO_PATTERN, I get a segmentation violation. However, if I use > DIFFERENT_NONZERO_PATTERN, everything works fine. If I am conservative about > how I initialize the nonzero pattern and desire it to never to change, why > do I need to use DIFFERENT_NONZERO_PATTERN? Individual components in the > nonzero structure will be zero for some steps and not others, but the > overall nonzero structure is fixed. I don't get errors when using Additive > Schwarz with ILU, but I am wondering if convergence problems occur because > of how the nonzero patterns are handled. Any ideas of what I am doing > incorrectly? What is SAME_NONZERO_PATTERN really telling the nonlinear > solver over multiple calls? Most of the examples only have one call to > SNESSolve, so I feel that this is not well covered elsewhere. > > Thanks in advance. > > Travis Fisher > >
