[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