Providing both nullspace and nearnullspace in KSPSolve does not work

[echarala]

In my PDE problem, I do know both nullspaces, one is associated with the U(1) invariance and the other with spatial rotational invariance O(2). At the numerical level, the former is always the case, but the latter depends on the mesh. Ideally, I would like to pass the former in nullspace and the latter in nearnullspace in KSPSolve.

For your convenience, I am attaching a MWE (with input data):

MWE.tar.gz

Upon running the code with -ksp_view -ksp_log options, it prints "has attached near null space", and thus it does not recognize the nullspace input. If I delete the "nearnullspace=Rot" option in the KSPSolve, it prints "has attached null space". If now I add "-ksp_constant_null_space", then it recognizes them both, but in my case I don't have a constant nullspace since it is provided explicitly.

I believe the FreeFEM wrapper in PETSc-code.hpp does not allow to use them both although on the PETSc side this seems to be not prohibitive. Looking at the old post "MatNullSpace -> nullspace #276 " by @cmdoug and @prj- , maybe the issue is there and is a very simple fix?

Many thanks for the help in advance!

[cmdoug]

Hi @echarala! You are correct that they cannot be used simultaneously in the current implementation. Are you using multigrid methods? I believe nearnullspace would only ever be used if you are using gamg/amg or maybe hypre. If not using multigrid, you would only set the exact nullspace, I believe.
EDIT: Also, just to check, the O(2) group encompasses reflections in addition to rotation. Is that correct? If you exclude reflections, then you have SO(2) which is isomorphic to U(1).

[echarala]

Hi @cmdoug, many thanks for your input! Yes, I do use multigrid methods. In the MWE, gamg is used. So, using just the exact nullspace with a direct method will do the trick by factoring it out?

Yes, you are right but I believe reflections is a discrete symmetry. The interesting thing is that the penalization of U(1) only is not enough as solutions still rotate.

[cmdoug]

Ah, good. Sorry, I have not looked at your files yet. If you indeed need both, then that will require some extension.

Well, once discretized onto your mesh, even the SO(2) symmetry is broken. Either O(2) or SO(2) will only be approximate and may--at best--be discrete symmetries that scale with the spatial order of accuracy of your discretization. Conversely, the U(1) symmetry will remain intact (up to floating point precision). A symmetry-preserving discretization would help you a lot here, though it should be possible (if ugly and error-prone) to work around that.

[echarala]

I believe it would be great having them both available. Thank you @cmdoug for the explanation. However, when mesh adaptivity is used, then the mesh restores these symmetries and causes all the issues with convergence.

[cmdoug]

@echarala, let me know if this patch #372 solves your issue.

Maybe I'm missing something, but I don't think that mesh adaptivity would restore any rotational symmetry. I think it would just break it in a different way.

[echarala]

In my problem, with a very fine mesh+mesh adaptivity, unfortunately it does cause such an issue. I will take a look at the patch!

[prj-]

I will close the issue, but if it is in practice not fixed, please re-open it.