changes for next PETSc release

[Barry Smith]

On Mar 17, 2008, at 9:43 AM, Lisandro Dalcin wrote:

> On 3/16/08, Barry Smith <bsmith at mcs.anl.gov> wrote:
>>     There are two significant  changes I'd like to see before the
>> next PETSc release:
>>
>> 1) remove the overly complicated (from a user perspective) matrix
>> subclassing for the various external
>>      matrix solver packages and replace with MatSolverSetType() -
>> mat_solver_type <type> that simply
>>      flips the various factorization/solver functions with those
>> requested and
>
> I'm definitely +1 on this. Switching to different LU solvers is a
> mayor pain, at least compared to KSP's or PC's.
>
>> 2) properly name-space PETSc by putting a Petsc in front of all PETSc
>> objects, function names etc
>>      (this will require changing a few names also to keep them below
>> the 32 character limit).
>
> Do you mean all the IS,Vec,Mat,KSP,PC,SNES,TS interfaces? Such a
> change would affect almost everything.

    Well yes, essentially everything :-(.
>
>
>> This will
>>      be very painful change for some users who are not comfortable
>> ever changing code, hence I hesitate
>>      to do it, but it is the right thing to do and should have been
>> done originally.
>
> Yes, end users will definitely cry. However, you can still do that
> with some backward compatibility mechanism. Basically, PETSc could
> provide some compatibility headers plenty of typedef's and #defines's
> providing access to the old naming convention.

    This is a major project, especially as the main-line evolves  
usually the
compatibility modes get out of date.

> We can even maintain
> that compatibility headers for a few releases. How many releases?
> Perhaps forever. I'm afraid that this approach would just delay the
> conversion process of all code out there. If at some time we stop
> maintaining the compatibily macros, then the real problem (users not
> updating code) will definitely appear, but now in the future.
>
> In short, I'm +1 in properly name-space all stuff. But such a change
> should be paired to a backward compatibility mechanism.
>
>
     We've never done this and I've always been strongly opposed to
it for the two reasons you listed above.

There is a certain class of people who think it is very important to  
keep backward compatibility,
but I've never seen any evidence as to why it is such a great idea. Look
at LAPACK, crappy interface in 1990, crappy interface in 2008. Python,
crappy interface in 1994, very nice (and even getting better) in 2008.
(Yes python does have some modes for having forward portability but they
are pretty sucky and not many people use them).

   Barry



>
>
>
>> .
>>
>>     Maybe we can do a release in around a couple of months, it would
>> be 2.4
>>
>>
>>    Barry
>>
>>
>>
>
>
> -- 
> Lisandro Dalcín
> ---------------
> Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
> Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
> PTLC - Güemes 3450, (3000) Santa Fe, Argentina
> Tel/Fax: +54-(0)342-451.1594
>