[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