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

[Matthew Knepley]

This still only applies to the very simple schemes which have the same #
dofs
at each site. I have a more complicated thing for unstructured FEM. It would
be nice if both had the same interface.

  Matt

On Tue, Jan 26, 2010 at 9:23 AM, Jed Brown <jed at 59a2.org> wrote:

> 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
>



-- 
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100126/951247ad/attachment.html>