Adding PetscMap getters

[Barry Smith]

   Dave,

     There is a MatGetOwnershipRangeColumn() that might suit your needs.
I have also just pushed the missing MatGetOwnershipRangesColumn()

    Barry

On Aug 22, 2008, at 9:04 PM, Dave May wrote:

> 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.
>>>
>>
>>
>