This still only applies to the very simple schemes which have the same # dofs<br>at each site. I have a more complicated thing for unstructured FEM. It would<br>be nice if both had the same interface.<br><br>  Matt<br><br>
<div class="gmail_quote">On Tue, Jan 26, 2010 at 9:23 AM, Jed Brown <span dir="ltr"><<a href="mailto:jed@59a2.org">jed@59a2.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I have run into at least three contexts where it would be useful for<br>
library code to be able to identify which components of a problem "go<br>
together" in the sense that they are part of a vector field.  For<br>
example, consider compressible flow with a natural block size of 5.  3<br>
of the fields are components of a vector (momentum) and the other two<br>
are not vectors (density, energy).<br>
<br>
1. Upwind schemes: we can write generic finite volume infrastructure if<br>
   the vector parts can be identified.  The library would be able to<br>
   rotate the system into reference coordinates at each quadrature point<br>
   on the faces, and only call user code for an x-split Riemann solver.<br>
   This would make it straightforward to offer generic TVD and ENO/WENO<br>
   support on DAs.<br>
<br>
2. File output: it would be very handy to have a generic viewer that<br>
   produced files with sufficient metadata for visualization (VTK<br>
   formats are a simple example of this).  This can be done by providing<br>
   all the components separately, but then the vectors need to be<br>
   reconstructed, so it would be better to write the vectors as vectors.<br>
<br>
3. Constructing coarse spaces for domain decomposition schemes:<br>
   low-energy modes, such as rigid body modes of a subdomain, need to be<br>
   in the coarse space in order to have a scalable algorithm.  While not<br>
   perfect, knowing which fields corresponded to vector quantities would<br>
   allow the library to determine such modes (perhaps with lightweight<br>
   user assistance).  ML has an API for setting these modes, and<br>
   FETI-DP/BDDC/PCEXOTIC would all need them to be provided.  If the<br>
   vector parts of each block were provided, then these modes could be<br>
   provided by the DM.<br>
<br>
I'm imagining either additional arguments to DASetFieldNames, or a<br>
similar API that would be called at the same time.  Any comments?<br>
<font color="#888888"><br>
Jed<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener<br>