Usando multigrid algébrico para pré-condicionar operadores de difusão por convecção

Implementei um Navier Stokes baseado na discretização FEM e PETSc para resolver o sistema linear de equações. Para criar um procedimento de solução eficiente, sigo o artigo "Pré-condicionamento eficiente das equações de Navier-Stokes linearizadas para fluxo incompressível" (Silvester et al.), Que propõe uma abordagem de complemento de Schur. Funciona bastante bem no sentido de que eu tenho um número quase constante de iterações, independentemente do tamanho da malha e do tempo para os benchmarks simples que também são apresentados neste documento (fluxo de cavidade acionado por 2D e passo voltado para trás). Mas, no momento, resolvo o bloco de velocidade superior com um solucionador direto paralelo (MUMPS). O bloco Schur de pressão é resolvido com solucionadores inexatos, conforme proposto no artigo.

No artigo, os autores propõem executar em cada iteração externa um único ciclo V multigrid e usar um ponto Gauss-Seidel mais suave para aproximar o inverso desse operador discreto de difusão por convecção. Como não posso usar facilmente um método geométrico multigrid, pensei em substituir o solucionador direto por um ciclo V multigrid algébrico (boomeramg do pacote hypre). Porém, perdi o número constante de iterações ao tornar a malha mais fina.

Algum de vocês tem alguma idéia de como criar um pré-condicionador espectralmente equivalente e eficiente para o inverso das matrizes de velocidade com base no multigrid algébrico? Existe algo inerente que não permita fazer uso de multigrid algébrico neste caso? Caso contrário, qual poderia ser a fonte para perder o escalonamento constante da iteração?

Editar:

Eu adicionei alguns benchmarks para diferentes solucionadores do bloco de velocidade. O problema está resolvido é o fluxo de cavidade 2D padrão acionado, discretização com Taylor-Hood e um refinamento uniforme da caixa da unidade

Solucionador de problemas (MUMPS)

: 25 iter h=$h = \frac{1}{32}$ : 25 iter h=$h = \frac{1}{64}$ : 25 iter h=$h = \frac{1}{128}$ : 22 iter$h = \frac{1}{256}$

um V-AMG (algébrico, boomeramg)

: 30 iter h=$h = \frac{1}{32}$ : 30 iter h=$h = \frac{1}{64}$ : 39 iter h=$h = \frac{1}{128}$ : 48 iter$h = \frac{1}{256}$

FGMRES com pré-condicionador V-AMG (algébrico, boomeramg), rtol: $10^{-6}$

: 30 iter h=$h = \frac{1}{32}$ : 29 iter h=$h = \frac{1}{64}$ : 30 iter h=$h = \frac{1}{128}$ : 47 iter$h = \frac{1}{256}$

FGMRES com pré-condicionador V-AMG (algébrico, boomeramg), atol: $10^{-8}$

: 27 iter h=$h = \frac{1}{32}$ : 27 iter h=$h = \frac{1}{64}$ : 28 iter h=$h = \frac{1}{128}$ : 26 iter$h = \frac{1}{256}$

O que você fez foi substituir o solucionador exato (direto) no canto superior esquerdo por um em que você faz apenas um único ciclo V. O caminho a seguir é resolver o bloco superior esquerdo em seu pré-condicionador usando um solucionador iterativo (por exemplo, GMRES) usando o AMG de ciclo V como pré-condicionador para esse solucionador interno. A experiência mostra que, se você usar o F-GMRES como solucionador externo, o solucionador interno do GMRES não precisará ser terrivelmente preciso. Apenas preciso o suficiente para permitir que ele produza um número quase constante de iterações externas.