On Mar 20, 2013, at 9:32 AM, Richard Tran Mills <rtm at eecs.utk.edu> wrote:
> 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> >> 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 Ok, then embed the transformation into the VecView and VecLoad for the Vecs associated with the DM (as they are automatically for DMDA.) Note you should NOT be calling DMDAGlobalToNatural() in your IO for DMDA, it should be done automatically and can be set up similarly for your new DM (just add DMCreateGlobalVector_MyGlobal) for your DM and have it switch the View and Load methods for the vectors. > and for setting up source/sink terms or boundary conditions on > nodesets/sidesets. You should be transferring any information about source/sink or boundary conditions on the "natural" mesh to the new mesh when the new mesh is created and not needing to do these operations in the original "natural" mesh. It is odd and adds unneeded complexity to your numerics to do some portions of the function evaluation on the final mesh organization and some on the "natural" plus not scalable because presumably your "natural" mesh is not good for parallelism or you would just always use it. > 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. As I said, it is fine to move this down to DM. Barry > > --Richard
