[petsc-dev] Add natural-to-global and global-to-natural operations for DM?

Richard Tran Mills rtm at eecs.utk.edu
Wed Mar 20 09:32:39 CDT 2013

On 3/19/13 11:38 PM, Jed Brown wrote:
> On Tue, Mar 19, 2013 at 9:54 PM, Richard Tran Mills <rtm at eecs.utk.edu 
> <mailto:rtm at eecs.utk.edu>> wrote:
>     [...]
>     Obviously, there may be subtypes of DM for which no "natural to
>     global" operation makes sense. 
> At the type level, adding something to base DM is an assertion that it 
> makes sense with all DMs. Even a local space does not strictly make 
> sense in DM (some problems are dense, in which case the "local" space 
> would be everything, which is likely a poor representation for the 
> operator).
Yes, there is that implicit assumption when adding something to the base 
functionality; that said, there are cases scattered throughout PETSc where 
there are "base" operations that are not supported by all of the 
subclasses, so I'm not sure how this judgement call is made.

I also agree that working in the "local" neighborhood is not a sensible 
thing to do for all DMs, but there still is some notion of "local", even 
if you wouldn't want to use it.  I certainly think that since there is 
support for GlobalToLocal and LocalToGlobal operations at the DM base 
level, that for consistency there should also be LocalToLocal support, 
rather than embedding that functionality at the sub-class level.
> So I would be reluctant to add the Natural concept since it does not 
> make sense with all DMs. What do you do with the natural vector coming 
> out of here? Why is it easier to implement dispatch in DM rather than in 
> your code?
We only use the natural ordering for things like doing I/O and for setting 
up source/sink terms or boundary conditions on nodesets/sidesets.  I have 
no actual need to do this at the DM level--I just like the idea of doing 
it this way for any DM type since we use DMDA routines in the structured 
case.  We can certainly continue to do it in the PFLOTRAN code without a 
need for DM routine for it.

I *do* have a "need" to do LocalToLocal operations on any DM type, 
however, as this isn't something that just happens during initialization 
and output.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130320/0993821f/attachment.html>

More information about the petsc-dev mailing list