[petsc-dev] Grouping vector dofs in multi-component problems
Barry Smith
bsmith at mcs.anl.gov
Tue Jan 26 11:28:07 CST 2010
Yes, we need a good systematic way to label this. Should it go in
the DM?
Barry
On Jan 26, 2010, at 11:05 AM, Matthew Knepley wrote:
> 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
More information about the petsc-dev
mailing list