JST Residual stalling

[jayantmukho]

Describe the bug
This is something I have noticed multiple times when running with JST on RANS cases: If the CFL number is increased (>5) the density residual stops changing and the solution essentially stalls:

I am digging into the JST implementation to see what is going on but haven't had any luck so far. Is this something that other people have experienced and have an explanation for?

Changing the LINEAR_SOLVER_PREC sometimes helps. In this flatplate case ILU does better but for other simulations this stalling will persist. Adaptive CFL will almost certainly mess things up (even #790). Sidenote, is there a rule of thumb for which LINEAR_SOLVER_PREC and LINEAR_SOLVER to use?

To Reproduce
This was on the basic flatplate test case that is available with the repo. Including files here for completeness
flatplate_jst_Sa.tar.gz

If the CFL is set to 5, the solution converges as expected. But if it is increased to 8, it stops moving.

Desktop (please complete the following information):

• OS: Linux (Ubuntu 16.04.11)
• C++ compiler and version: g++ (GCC) 5.4.0
• MPI implementation and version: openmpi 1.10.2
• SU2 Version: v6.2.0 develop

This has been replicated on a variety of systems

[WallyMaier]

This also occurs when using Lax and JST_KE. I was able to reproduce similar results as @jayantmukho with a 1,000,000,000 CFL

[pcarruscag]

Have you tried the CENTRAL_JACOBIAN_FIX_FACTOR option introduced in #691?
I recommend setting that to 3 or 4, the Lax coefficient to 0.1 (default is 0.15) the JST 4th order coeff to 0.01 and max CFL of 100 - 400 when using the ILU0 preconditioner, depending on how stretched the mesh is.
The justification for those settings is in the aforementioned PR.
Cheers,
Pedro

[economon]

The conclusion from #691, which works, makes me think we could be missing something still in the Jacobians for the centered schemes. If we gain stability by improving diagonal dominance, then perhaps we are either adding negative terms to the diagonal, reducing it in the first place, or we could be missing positive terms that should be added to the diagonal.

@pcarruscag : when you were working through that, did you see anything that might be amiss?

One strategy I have seen folks use is to check the sign of the terms that are added to the diagonal, and if they are negative, either do not add them, or add the fabs() of it instead. We could do checks like this for schemes throughout the code. I know this can have a particular impact for source terms in turbulence models, for instance.

[pcarruscag]

I derived the Jacobians from scratch and checked against literature, they are correct (apart from Laplacians).
It is just a quirk of central schemes to result in non diagonal dominant matrices.
I experimented with biasing the Jacobians upwind (which is similar to the fabs strategy) and I got worse results than with artificially increasing the diffusion contribution (which I think is also done in the modified SUmb that Martins uses).
I also saw that adding diffusion to the Jacobians of upwind schemes has a negative impact since elliptic equations are stiffer than pure upwind convection.

[pcarruscag]

Oh and for the number of linear solver iterations you need at those values of CFL, BiCGSTAB may be a better choice.

[pcarruscag]

@jayantmukho did our suggestions help with the issue?

[pcarruscag]

I think this has been explained.
(ill-conditioned matrix -> FGMRES cannot lower the linear residual -> solver stalls)

[jayantmukho]

Oh yes! I am sorry, forgot to close the issue. Thanks for the help.