Re: [petsc-users] Problems about GMRES restart and Scaling

[Smith, Barry F. via petsc-users]

> On Mar 20, 2019, at 5:52 AM, Yingjie Wu via petsc-users 
> <petsc-users@mcs.anl.gov> wrote:
> 
> Dear PETSc developers:
> Hi,
> Recently, I used PETSc to solve a non-linear PDEs for thermodynamic problems. 
> In the process of solving, I found the following two phenomena, hoping to get 
> some help and suggestions.            
> 
> 1. Because my problem involves a lot of physical parameters, it needs to call 
> a series of functions, and can not analytically construct Jacobian matrix, so 
> I use - snes_mf_operator to solve it, and give an approximate Jacobian matrix 
> as a preconditioner. Because of the large dimension of the problem and the 
> magnitude difference of the physical variables involved, it is found that the 
> linear step residuals will increase at each restart (default 30th linear 
> step) . This problem can be solved by setting a large number of restart 
> steps. I would like to ask the reasons for this phenomenon? What knowledge or 
> articles should I learn if I want to find out this problem? 

   I've seen this behavior. I think in your case it is likely the 
-snes_mf_operator is not really producing an "accurate enough" Jacobian-Vector 
product (and the "solution" being generated by GMRES may be garbage). Run with 
-ksp_monitor_true_residual

   If your residual function has if () statements in it or other very sharp 
changes (discontinuities) then it may not even have a true Jacobian at the 
locations it is being evaluated at.  In the sense that the "Jacobian" you are 
applying via finite differences is not a linear operator and hence GMRES will 
fail on it.

    What are you using for a preconditioner? And roughly how many KSP 
iterations are being used.

   Barry

>           
> 
> 2. In my problem model, there are many physical fields (variables are 
> realized by finite difference method), and the magnitude of variables varies 
> greatly. Is there any Scaling interface or function in Petsc? 
> 
> Thanks,
> Yingjie