since developing object oriented software is so cumbersome in C and we are all resistent to doing it in C++

[Barry Smith]

On Dec 7, 2009, at 9:53 AM, Alex Peyser wrote:

> Have y'all considered a different approach?
>
> I've had endless trouble integrating petsc into my system because  
> the "object-
> oriented" C is both only partially "object oriented" while  
> simultaneously
> making access to the underlying functionality obscure.

    Could you please give us cases where access to the underlying  
functionality is obscure? Everything is suppose to be accessable  
through an "object oriented" approach.  (Sorry about being defensive)  
We'd like to fix this.

> Some "objects" have
> some methods, and others are missing;

     This is intentional. To require each object to fully support all  
its interface methods would require having many different classes (for  
example matrix-free methods cannot support the factorization and  
setting/getting values interfaces so they would have to be seperated  
into subclasses). I (and this is me, perhaps most others don't have  
this difficulty) find that complexity of using a class library grows  
RAPIDLY with the number of classes and complexity of class  
hierarchies. Thus we kept a very small number of classes in PETSc, we  
could only do this by "cheating" and not requiring all objects to  
support all methods.

> some have the same functionality through
> higher level interfaces or lower level interfaces..

     I've tried very hard to prevent having the same functionality at  
two levels; the one place where we do have it is in the matrix  
factorizations and triangular solves where you can do it directly on  
matrix objects or through KSP and PC, but we do note in the matrix  
documentation the prefered approach is with KSP/PC and list them as  
"developer" level usage. We could "hide" the direct matrix solver  
methods even more by not providing public interfaces for them  
completely; perhaps we should have done that. Could you please list  
other things that have same functionality at a higher level interface  
and lower level so we can perhaps improve that experience. It is our  
intention (except with the factorization and solves) to NOT have the  
same functionality accessable from two levels.

> . and so on.
>
> Maybe you need to split this into two projects -- one a set of  
> normal C
> interfaces to the kernels, communications, etc -- the underlying  
> functionality

    We ended up with the "hybrid model" because we could not see or  
even conceive of how to write a "normal C interfaces" for sparse  
matrices and preconditioners. The closest  numerical package to PETSc  
that I see that uses a "normal C interface" and is widely used is  
LAPACK and it only supports dense and banded martrices sequentially;  
its interface is already overwhelming, diffcult and not extensible.  
Bill and I selected an objected oriented approach in 1995 not because  
we thought it was cool or modern but because we viewed making a usable  
general purpose package for sparse solvers with a "normal c interface"  
as impossible. We could have been wrong, and could still be wrong  
about this, but I've yet to see any usable general purpose sparse  
solver package that works with a "normal c interface". I think it is  
impossible. ScaLAPACK tries to use a "normal C interface" (but it  
still has somethings resembling objects) and is a totally unusable  
piece of garbage and again is only for dense matrices.

   I appreciate your comments, again sorry for coming across as  
defensive.

    Barry


> -- and a separate "object oriented" layer on top of it written in  
> whatever 
> language you prefer (I find python to be a very, very evil language,  
> but y'all
> seem to have a taste for it).
>
> This would both allow the functionality to be adapted to multiple  
> overlaying
> interfaces, and keep the low overhead to initial adoption. It seems  
> that the
> current approach is a shoe horn of both very low level and high  
> level behavior
> into the same programming paradigm -- which always leads to a coding  
> mess.
>
> It seems particularly ugly to bind low level languages such as C++  
> and Fortran
> onto a higher level, interpreted language like Python -- binding C  
> onto python
> which then binds onto C! And then binding any other language would  
> be a
> sequence of binding X onto C++ to bind onto python to bind onto C!
>
> Alex Peyser
>
> On Friday 04 December 2009 11:42:35 pm Barry Smith wrote:
>>    Suggestion:
>>
>> 1) Discard PETSc
>> 2) Develop a general Py{CL, CUDA, OpenMP-C} system that dispatches
>> "tasks" onto GPUs and multi-core systems (generally we would have one
>> python process per compute node and local parallelism would be done
>> via the low-level kernels to the cores and/or GPUs.)
>> 3) Write a new PETSc using MPI4py and 2) written purely in Python  
>> 3000
>> using all its cool class etc features
>> 4) Use other packages (like f2py) to generate bindings so that 3)
>> maybe called from Fortran90/2003 and C++ (these probably suck since
>> people usually think the other way around; calling Fortran/C++ from
>> Python, but maybe we shouldn't care; we and our friends can just be  
>> 10
>> times more efficient developing apps in Python).
>>
>>    enjoy coding much better than today.
>>
>>  What is wrong with Python 3000 that would make this approach not be
>> great?
>>
>>
>>    Barry
>>
>> When coding a new numerical algorithm for PETSc we would just code in
>> Python, then when tested and happy with reimplement in Py{{CL, CUDA,
>> OpenMP-C}
>>
>> The other choice is designing and implementing our own cool/great OO
>> language with the flexibilty and power we want, but I fear that is  
>> way
>> to hard  and why not instead leverage Python.
>>