[petsc-dev] Grouping vector dofs in multi-component problems

Jed Brown jed at 59A2.org
Tue Jan 26 09:23:04 CST 2010


I have run into at least three contexts where it would be useful for
library code to be able to identify which components of a problem "go
together" in the sense that they are part of a vector field.  For
example, consider compressible flow with a natural block size of 5.  3
of the fields are components of a vector (momentum) and the other two
are not vectors (density, energy).

1. Upwind schemes: we can write generic finite volume infrastructure if
   the vector parts can be identified.  The library would be able to
   rotate the system into reference coordinates at each quadrature point
   on the faces, and only call user code for an x-split Riemann solver.
   This would make it straightforward to offer generic TVD and ENO/WENO
   support on DAs.

2. File output: it would be very handy to have a generic viewer that
   produced files with sufficient metadata for visualization (VTK
   formats are a simple example of this).  This can be done by providing
   all the components separately, but then the vectors need to be
   reconstructed, so it would be better to write the vectors as vectors.

3. Constructing coarse spaces for domain decomposition schemes:
   low-energy modes, such as rigid body modes of a subdomain, need to be
   in the coarse space in order to have a scalable algorithm.  While not
   perfect, knowing which fields corresponded to vector quantities would
   allow the library to determine such modes (perhaps with lightweight
   user assistance).  ML has an API for setting these modes, and
   FETI-DP/BDDC/PCEXOTIC would all need them to be provided.  If the
   vector parts of each block were provided, then these modes could be
   provided by the DM.

I'm imagining either additional arguments to DASetFieldNames, or a
similar API that would be called at the same time.  Any comments?

Jed



More information about the petsc-dev mailing list