[petsc-dev] DM field interfaces

[Jed Brown]

On Sat, Feb 25, 2012 at 15:27, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
>   Let's back up a step before everyone gets totally confused (and worry
> less about exact syntax to use instead focus on concepts)
>
> Proposal 1: Jed
>
>    // Conservative gas dynamics with fields ordered as [rho, rho*u, rho*v,
> rho*w, E]
>   DMGetFieldSplitting(dm,"conservative-vector",&fscons); // creates if it
> doesn't exist
>   DMFieldSplittingAddField(dm,fscons,"rho",{0});
>   DMFieldSplittingAddField(dm,fscons,"momentum",{1,2,3});
>
>     This seems to be premised on having an underlying "canonical" set of
> fields that one can define unions of to make new fields. For example with
> DMDA the underlying
>    fields are simply the 0th, 1st, 2nd etc DOF at each node. For a simple
> staggered grid 0 canonical may be the pressure centers, 1 the x velocities,
> 2 the y velocities
>

Alright, lets abandon this "canonical field" idea, it was broken to begin
with and less flexible, as you say.


>
> Proposal 2: Barry
>
>     Use IS's to define the fields, not unions of canonical fields. Reason:
> more general than proposal 1
>

Great, my concern is that we would like DM to be able to declare multiple
named partitions. For example, so that we can have a conservative-scalar
splitting, a conservative vector splitting (keeps vector components
together), primitive variable splittings, local-characteristic splittings
(analytically diagonalize the flux Jacobian for hyperbolic problems), etc.

We can think of these transformations as symmetric preconditioning. Suppose
that we want to solve with J, operating on conservative variables. Suppose
P converts conservative to primitive variables and C = P^{-1} converts
primitive to conservative. I'm using matrix notation for because this would
often be applied to perturbations. We need to solve a linear system with
J_c, the Jacobian acting on conservative variables, but the preconditioner
wants to operate in primitive variables, so the user assembles

J_p = P J_c C.

(Usually they do this only approximately and it's done without looking at
J_c.) The conservative system is

J_c = C J_p P

At the algebraic level, I think this logic belongs in a new preconditioner
that applies a user-defined pre- and post-transformation, the concern is
how to forward DM-based information into PCFieldSplit and PCMG operating on
J_p.



>  Because Jed's proposal 1 violates the use of IS for indexing paradigm and
> is less general than Proposal 2 I'd like to drop that Proposal 1; but it
> does bring up an issue. I think we need another IS implementation that is
> more "general" than stride for handling sets of DOFs of freedom associated
> with those canonical sets of fields. So it is easy to access canonical
> fields that are not simply stride. For example
> ISCreateCanonical(MPI_Comm,PetscInt ncanonical,PetscInt *fields), we can
> even have "predefined" ones available for use such as
> IS_CANONICAL_(MPI_Comm,3,{1,2,3}) Thus we can preserve some of the
> simplicity of proposal 1.  Jed's (again not worrying about syntax)
>
> DMFieldSplittingAddField(dm,fscons,"momentum",{1,2,3});  becomes
>
> DMFieldSplittingAddField(dm,fscons,"momentum",IS_CANONICAL_(comm,3,{1,2,3})
>
> Note that for a Vec with a given block size the canonical fields are
> simply the stride fields so IS_CANONICAL_(comm,1,{start}) is pretty much
> ISStride().
>

Ignoring syntax, I think this is fine.

Proposal 3: Jed
>
>    Observation: Using IS does not give all desired generality since the
> new field may be a linear combination of DOFs. Or, yikes, a nonlinear
> transformation of DOF.
>    Thus we may need something like DMTransformVec() to do these
> transformations.
>
>
> So this moves us beyond the traditional block linear algebra methods but
> if we could solve it we'd have some very nice new powerful capabilities on
> our hands.
>
> Question 1:  Do we need to solve this for the current generation of
> PCFieldsplit?
> Question 2:  Do we want to solve it in PCFieldSplit or should that come
> later in a different PC, PCBasisChangeThingy or something?
>

Yes, but what DM should PCBasisChangeThingy forward to the inner PC?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120226/a3f348e9/attachment.html>