Monolithic Jacobian assembly for nonlinear coupled multiphysics

[lindsayad]

Is there a good way to form a monolithic Jacobian for generally nonlinear coupled physics? I have looked at BlockNonlinearForm. This seems like a good option if you want to perform block preconditioning strategies. However, I am interested in a problem setup in which different preconditioning strategies can be selected from the command line. For instance, ideally I could perform a monolithic LU on this coupled system or I could leverage block preconditioning strategies using -pc_type fieldsplit (using a PETSc solver backend).

There is obviously NonlinearForm as well but that only supports a single finite element space while each physics may leverage a different space

[tzanio]

There have been several requests for this in the past, but it hasn't been a very high priority for us because typically the problem our users target are large, and we don't have scalable monolithic preconditioners.

Maybe we should change that... Besides LU have you had good success with scalable solvers for the monolithic system?

[lindsayad]

No. The most scalable solvers we have for multiphysics are indeed block, fields-split based. But it would be nice for MOOSE to continue to have a workflow in which these block solvers are easily configurable from an input file or command line, e.g. PETSc options, and to also have the option to leverage LU when troubleshootingn solves. All the MFEM examples leverage command line arguments so I'm sure this is still achievable, it's just a question of how user-friendly it would be.

@alexanderianblair was telling me that they have created monolithic matrices from MFEM block matrices in https://mfem.org/pdf/workshop23/10_Ellis_MOOSE_MFEM.pdf for example, so maybe that's something I can look at. It would be nice to avoid a conversion step though

[lindsayad]

We also have quite a few 1D and 2D users whose simulations never exceed much more than thousands or tens of thousands dofs for whom LU is a great option for their multiphysics

[tzanio]

Understood, thanks for the details. We can make this a priority and/or upstream @alexanderianblair's work if this is important for you.