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 <[email protected]> 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.