[petsc-dev] post 3.1 reorganization of PETSc DMMG code

[Jed Brown]

On Fri, 19 Mar 2010 16:23:23 -0500, Barry Smith <bsmith at mcs.anl.gov> wrote:
> (3) introduce into DM the ability to "get subphysics" DM. Here the  
> conceptual question is how to indicate them. Do we introduce the idea  
> of having each DM as having N "fields" and then to be able to request  
> "field 1 and 2" etc? PCFIELDSPLIT has this concept with  
> PCFieldSplitSetFields(). This is easy enough to implement but I don't  
> like it. The reason I don't like it is that we already have the  
> concept of IS that is used to indicate subsets of things; I HATE to  
> have two different ways of doing something. We also have  
> PCFieldSplitSetIS() which is "generalization" of  
> PCFieldSplitSetFields(), if I wasn't so lazy when I added  
> PCFieldSplitSetIS() I would have immediately removed  
> PCFieldSplitSetFields(). So I would like to have  
> DMGetSubDM(DM,MPI_Comm,IS,DM*). For DA with suitable stride and block  
> stride IS this is easily done and makes sense, an arbitrary IS would,  
> of course, have to generate an error.  For DMCOMPOSITE providing sub  
> IS's would be cumbersome and not intuitive at all. So perhaps we do  
> need both types of getters. (Side note, if we introduce some builtins  
> like IS_FIELD_1, IS_FIELD_2 then perhaps we could have one interface  
> that was reasonably painless for the simple cases of fields but is  
> general? I'll think about this.)

The IS interface is absolutely required in order to support vector
elements and composite spaces where there just isn't any other way do
describe the field.  I'm not wild about referring to fields by number,
even in the cases where it is sufficient, because this makes other code
and the options database brittle (if you add one additional field, the
indexing may change).  I think I would prefer something like

  DMSetFieldNameIS(dm,name,is)

which let you associate names with portions of the vector.  Note that
these names need not be exclusive, you might have scalar fields
{u,v,w,p,T}, but want to address {u,v,w} as "velocity" because that's
what it is when you group it.  It's probably better to have a new
function for the grouping, something like

  DMGroupFieldsAs(dm,name,component1,...)

Exposing this hierarchy means that you could address {u,v,w} inside of
an existing split.  Here is an example of what you might do (suggesting
a possible syntax for building a grouping at runtime):

  -fieldsplit_velocity_type mg
  -fieldsplit_velocity_mg_levels_sub_pc_type fieldsplit
  -fieldsplit_velocity_mg_levels_sub_fieldsplit_fields 'uv=u,v;w'
  -fieldsplit_velocity_mg_levels_sub_fieldsplit_uv_type icc
  -fieldsplit_velocity_mg_levels_sub_fieldsplit_w_type sor

Along with the grouping API, we should be able to indicate pieces that
are "vectors" and "tensors", so that this semantic information is
available for visualization.


As a separate issue, when talking about bigger multiphysics problems, I
would really like namespaced options.  This could be as quick-and-dirty
as

  -prefix_push something_ -other -options -prefix_pop

which would mean

  -something_other -something_options

In particular, this would have to work with

  -prefix_push fieldsplit_physics1_ -options_file physics1-solver -prefix_pop

where everything in 'physics1-solver' would be under this prefix.
Alternatively (or additionally), a parser for yaml options would allow
this composition.

Jed