[petsc-dev] Grouping vector dofs in multi-component problems
Matthew Knepley
knepley at gmail.com
Tue Jan 26 11:05:27 CST 2010
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>
More information about the petsc-dev
mailing list