Adding PetscMap getters

[Dave May]

Hi Barry,
    Thanks for your detailed response. It's refreshing to hear that
code in PETSc is introduced for the right reasons. I think the reasons
why I like PETSc so much is the result of the two strict rules you
adhere to. In my experience, many developers don't have such a strong
set of guide lines (or any guide lines at all) in mind when they write
code, and hence often introduce things for all the wrong reasons.

The actual task I wished to perform was this;
Given a rectangular matrix and an (i,j) location, determine whether
(i,j) was in the matrix's diagonal block or off diagonal block.

For square matrices this is easy as I can call MatGetOwnershipRanges()
and use the array for the row and column layout. But for rectangular
matrices I needed the column map. I could call MatGetVecs(), generate
a consistent left and right vector but then I still need to figure out
the ownership ranges for the vectors. (Plus I don't think generating
vectors just to determine the parallel layout of the matrix is very
smart.)

One could say that I should just specify the parallel layout when I
built the matrix and vectors in the first place, then this problem
goes away.  But this defeats the purpose of letting PETSc decide it
for me. I should still be able to query the parallel layout of the
matrix independent of whether I asked PETSc to determine the layout or
I prescribed it myself.

I thought access to the maps would be the simplest approach, ie.
generate the least amount of  work for you, as only a very small
getter would need to be written. Given the guide lines you follow
(which I wasn't aware of) I see why this isn't the right thing to do.

So what about this.
Forget about accessing the PetscMap object directly (meeting the first
rule of PETSc programming) and instead add routines to fully determine
the parallel layout of the vectors and matrices.

For vectors this would mean introducing
    VecGetOwnershipRanges()

For matrices this would mean introducing
    MatGetRowOwnershipRange()      ( which is identical to
MatGetOwnershipRange() )
    MatGetRowOwnershipRanges()    ( which is identical to
MatGetOwnershipRanges() )

    MatGetColOwnershipRange()
    MatGetColOwnershipRanges()

Unless I'm mistaken (please correct me if I'm wrong), there is
currently no simple and direct way to determine the parallel layout of
a matrix in terms of both of row and column ranges. Hence adding these
interfaces for the matrices would not violate of the second rule of
PETSc programming.

Cheers,
    Dave



On Sat, Aug 23, 2008 at 1:14 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
>   Dave,
>
>     This has been a controversial issue over the years. We didn't have a map
> concept, it was introduced, it was then
> "hidden".  The fact that there exist public PetscMap functions at all is my
> compromise for a persistent user.
>
>     Two key "rules" I use in making decisions in PETSc code are:
>
> 1) try really really hard to minimize the number of abstract objects in the
> PETSc interface (this is because I believe
>     the difficulty of using a "class" library grows exponentially with the
> number of abstract objects in the interface)
>    (obviously not everyone believes this, it seems most class libraries add
> new classes at the drop of a hat)
> 2) there should be ONE way to do each operation in the package (this is
> because I believe having multiple ways to
>   do the same thing is confusing to most users). For example, to set the
> size of a vector you can only use VecSetSizes(),
>   to solve a nonlinear system you call SNESSolve()*.
>
>  If we bring PetscMap up as "first class user object" this violates both 1
> and 2. It is a new basic object and manipulating/accessing
> Vec/Mat size information would have TWO ways of doing everything:
> VecGetSizes(), VecGetPetscMap() -> PetscMapGetSizes() etc.
> I actually dream about the opposite; shrinking PetscMap down so it is so
> small it can be strangled in a bathtub. I tried once
> to remove the VecGetSizes() etc and have access only through PetscMap (to
> satisfy rule 2) but ended up removing the public
> PetscMap because I didn't see having PetscMap as the basic "layout definer"
> as a good PETSc interface.
>
>   So my answer is, I really do not want to add these getters.  you really
> have to convince me that the PetscMap object
> is so fundamentally powerful it is worth violating 1 and 2.
>
>  Barry
>
>
> Note that the PetscMap() methods are prototyped in vecimpl.h, indicating
> they are not public methods for PETSc.
>
>
>
>
>
> *sadly there is also DMMGSolve(), this I view as an interface bug and dream
> about someday merging this functionality
> back to the SNES.
>
>
> On Aug 21, 2008, at 5:52 PM, Dave May wrote:
>
>> Hello,
>>   Would it be possible to have the following small getters added to
>> petsc-dev?
>>        VecGetOwnershipRanges()
>> Since we are just manipulating the maps why not include the following as
>> well
>>       VecGetMap()
>>       MatGetRowMap()
>>       MatGetColumnMap()
>>
>> It seems reasonable to add these (to me at least) given there a few
>> interfaces for
>> PetscMap already made public.
>>
>> Cheers,
>>   Dave.
>>
>
>