Solver for the compressible Euler equations

[jshipton]

@JHopeCollins's excellent summary of today's discussion

Current compressible euler solver does two things:

1. eliminate theta
2. hybridise u

There are two details about the compressible euler hybridisation that make it trickier than the other equations

1. The extra off-diagonal blocks for the trace variable are not the transpose of each other, so firedrake.HybridisationPC is a no-go.
2. The hybridised form requires the current state, including theta.

In the ideal world of infinite composability, there would be separate solver steps for the elimination and the hybridisation, that could be done in either order. However, each ordering poses problems.

Option 1:

1. first use PCFieldsplit to eliminate theta (Vu, Vrho, Vtheta)->(Vu, Vrho)
2. then use a gusto.hybridisationPC to create the broken space/form (Vu, Vrho)->(Vub, Vrho, Vtr)
3. then set some options to solve the broken form (Vub, Vrho, Vtr)

Option 1 feasibility:

1. This step is fine.
2. This step is a problem.
   • Creating the hybridised form manually at this stage relies on the variable we just eliminated so accessing it it hard. It would either need to be passed via the appctx or have the required state stashed on the Equation.
   • Asking the CompressibleEquations to specify the original linearisation_map such that SlateSchurPC gives the Right Thing may be tricky/impossible. Even if this works it, it may make solving the form on (Vub, Vrho, Vtr) difficult (see below).

Option 2:

1. First hybridise the full space/form (Vu, Vrho, Vtheta) -> (Vub, Vrho, Vtheta, Vtr)
2. Use PCFieldsplit to eliminate theta (Vub, Vrho, Vtheta, Vtr)->(Vub, Vrho, Vtr)
3. Set the broken form on (Vub, Vrho, Vtr) and specify some options.

Option 2 feasibility:

1. This step is ok if the form on (Vub, Vrho, Vtheta, Vtr) that exactly matches the current form on (Vub, Vrho, Vtr) is known.
2. This step is fine.
3. This step requires somehow "knowing" the current form on (Vub, Vrho, Vtr), which is the schur complement of the form on (Vub, Vrho, Vtheta, Vtr) after reordering to put Vtheta first.
   • If the form is generated symbolically using SlateSchurPC that again might cause problems (see thread).
   • If its specified manually that is more code to maintain and specialise.

Alex's suggestion is to first simply turn the current CompressibleEulerSolver into a CompressibleEulerPC.

1. That would immediately allow him to use it for non-SIQN solver.
2. The PC could then be refined/refactored incrementally later.
3. The code in asQ.HybridisationSCPC might be useful for what to put in each method of a firedrake.PCBase subclass - particularly updating the state used in the hybridised form in the update method.

Why might solving the hybridised & theta-eliminated form on (Vub, Vrho, Vtr) be tricky if the form was generated by SlateSchurPC? There are two possible solver options, both of which may be (currently) impossible.

1. SCPC might not accept slate forms (unknown - HybridisationPC currently doesn't at least)
2. We could use another fieldsplit to eliminate (Vub, Vrho) which is fine, but then we'd need SlateSchurPC to define the problem on (Vtr), which again might be a problem if the slate code in SlateSchurPC doesn't work with slate forms!