On Feb 25, 2012, at 12:13 PM, Jed Brown wrote:
> [migrating from petsc-maint]
>
> > What interface are we going to use for splitting out a DM for a vector
> > field in a larger system? How do we get the bs=2 velocity DM out of the
> > lid-driven cavity's bs=4 velocity, vorticity, and temperature DM?
> >
>
> again this is irrelevent here because the same issue is true for the ISs.
>
> But
>
> I explained this in my previous email: DMPushSubDMType(DM,"name of a type
> of splitting like u,v,p or velocity,p"); DMPopSubDMType(); it is not perfect
> but a start. See that email for more details.
>
> // 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});
> DMFieldSplittingAddField(dm,fscons,"Energy",{4});
>
> DMGetFieldSplitting(dm,"primitive-vector",&fsprim);
> DMFieldSplittingSetPF(dm,fsprim,UserEquationOfStatePF,UserEquationOfStateInversePF);
> DMFieldSplittingAddField(dm,fsprim,"velocity",{0,1,2});
> DMFieldSplittingAddField(dm,fsprim,"pressure",{3});
> DMFieldSplittingAddField(dm,fsprim,"Temperature",{4});
>
> If a transform is not specified, the indices would address the original state
> variables.
Jed, It also makes it impossible to handle bizare things where for one
spitting you want a subset of one thing actually in another thing. So why not
use IS to define the names, this gives complete flexibility. Also this above is
not adding fields: you are just giving names to subsets of fields indicated by
the original numbering of fields. Which is fine, but has confusing names (you
are not AddField just naming it). My suggestion is just a more or less a
concise way of doing what you are doing without the need for YET ANOTHER CLASS
(fcons).
>
> Then PCFieldSplit and eventual nonlinear and time-stepping splitting methods
> would call
>
> DMGetFieldSplitting(dm,&nsplits,&splits);
> // choose split number to use
> split = splits[splitidx];
> DMFieldSplittingGetName(dm,split,&splitname);
> DMFieldSplittingGetFields(dm,split,&pf,&pfinv,&nfields,&isfields,&dmfields);
I do not like this approach based on requesting by name, just push your name
and then pop it. This way something "above" in the call stack can push to the
right one then something further down can use it without having to know its
name (sort of like your "default" split) but the push allows changing the
default. You kind of assume that the guts is suppose to know what name to use?
// choose split number to use how is some PC deep inside suppose to know this?
I realize my proposal was not complete on detail. I'm suggesting changes to
your detail.
Barry
>
> If pf is not NULL, apply PF to the state variables, then isfields[i] denotes
> what to extract in order to live in dmfields[i], pfinv is needed to put a
> contribution back into the coupled dm.
