Solve type LINEAR is not doing matrix-free calculations

[YaqiWang]

In PetscSupport.C:setSolverOptions(SolverParams & solver_params), when solver type is linear, SNES type ksponly is used, but no -snes_mf or -snes_mf_operator is set. MOOSE's way of setting up a system is that the residual evaluation is assumed to be correct, while Jacobian could be just an approximation. If Jacobian is indeed an approximation and the problem is linear, setting solver type to LINEAR will not give us correct answer. So I propose to add

PetscOptionsSetValue("-snes_mf_operator", PETSC_NULL);

under ST_LINEAR case.

[YaqiWang]

I think we should change the name to JFK (Jacobian-free Krylov). Similarly NEWTON type is a little misleading, it is better to name it to NK (Newton Krylov), FD to FDNK (finite difference Newton Krylov). It is up to you.

[andrsd]

ST_LINEAR is for solving A * x = b in a non-linear solver setup.

[YaqiWang]

I know, but users could provided A*x-b but did not provide Jacobian A accurately. Especially a complicated problem is set up with MOOSE. Some kernels may miss Jacobian evaluation or simply off-diag part of the Jacobian is missing.

[andrsd]

That would be a different solver setup, thus it should have a different name. Correct me if I am wrong, but in ST_LINEAR we compute Jacobian and residual once and then PETSc takes over and solves the system. With your modification, we would be evaluating the residual in each linear iteration, thus killing the efficiency of ST_LINEAR.

Now, since linear problems are subset of non-linear, why cannot you prescribe large tolerance for the linear solve and let your problem converge in 1 NL-iteration using PJFNK?

[permcody]

Yaqi, David is correct. We let PETSc solve the system without making callbacks with ST_LINEAR. You can put print statements in your callbacks to confirm. That doesn't mean that we should also support some other scheme, just telling you what we have now.

On Wed, Oct 14, 2015 at 9:51 AM David Andrs notifications@github.com wrote:

That would be a different solver setup, thus it should have a different name. Correct me if I am wrong, but in ST_LINEAR we compute Jacobian and residual once and then PETSc takes over and solves the system. With your modification, we would be evaluating the residual in each linear iteration, thus killing the efficiency of `ST_LINEAR'.

Now, since linear problems are subset of non-linear, why cannot you prescribe large tolerance for the linear solve and let your problem converge in 1 NL-iteration using PJFNK?

— Reply to this email directly or view it on GitHub https://github.com/idaholab/moose/issues/5820#issuecomment-148093815.

[YaqiWang]

Maybe we should name it as JK (Jacobian Krylov) then. LINEAR does not necessarily mean the Jacobian is exactly assembled. I think the names are confusing.

[jwpeterson]

On Wed, Oct 14, 2015 at 10:15 AM, Yaqi notifications@github.com wrote:

Maybe we should name it as JK (Jacobian Krylov) then. LINEAR does not necessarily mean the Jacobian is exactly assembled. I think the names are confusing.

May be, but they are documented (I think?) and already used in lots of input files. Plus I would argue your proposed names are not that much more enlightening...

John

[friedmud]

I like LINEAR the way it is. Note that with LINEAR you can use lots of different solvers... So "Krylov" doesn't make sense.

As for what you're after Yaqi... I don't understand how it's any different from JFNK or PJFNK... is it just because you expect the thing to be linear? I don't think that PETSc has a mode where you do matrix-free mat-vecs in a linear solver...

Derek On Wed, Oct 14, 2015 at 12:29 PM John W. Peterson notifications@github.com wrote:

On Wed, Oct 14, 2015 at 10:15 AM, Yaqi notifications@github.com wrote:

Maybe we should name it as JK (Jacobian Krylov) then. LINEAR does not necessarily mean the Jacobian is exactly assembled. I think the names are confusing.

May be, but they are documented (I think?) and already used in lots of input files. Plus I would argue your proposed names are not that much more enlightening...

John

— Reply to this email directly or view it on GitHub https://github.com/idaholab/moose/issues/5820#issuecomment-148106970.

[permcody]

Discussion - Not an issue or an enhancement request - closing...