[petsc-dev] I question the existence of PetscErrorCode (*createlocaltoglobalmapping)(DM); PetscErrorCode (*createlocaltoglobalmappingblock)(DM);

[Barry Smith]

On Mar 20, 2013, at 8:45 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> On Wed, Mar 20, 2013 at 8:32 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> I question the existence of   PetscErrorCode (*createlocaltoglobalmapping)(DM);   PetscErrorCode (*createlocaltoglobalmappingblock)(DM);
> 
> 1) They have no public interface function
> 
> The local-to-global mapping is a significant amount of memory when using explicit methods or matrix-free multigrid, so these ops allow the mapping to be constructed lazily. Some DMs build the mapping eagerly and thus don't implement the callback. The public API is DMGetLocalToGlobalMapping().

   This is wrong and needs fixing, having one name for the public interface and a different name in the function table. You need to change the name in the function table to get() and DMCreateLocalToGlobalMapping_Composite() and friends to use the name DMGet…

   Having this inconsistent naming already wasted my time, and your time responding to the email and everyone else's time in having to delete the email. I'd fix it but git workflow is too hard so you need to fix it. Consistency reduces complexity.

   Barry

>  
> 2) They only exist for a couple of DM types
> 
> Shouldn't they just be private functions for those types? Why do they go in the function table?
> 
> DMGetLocalToGlobalMapping() is called generically by DMCreateMatrix_Composite and perhaps by users rolling their own composite spaces.