changes for next PETSc release

[Lisandro Dalcin]

Yes, but you have to do the same for every Mat routine. That's the
hard part to maintaing when new functions are added.

Perhaps then a macro like the following would help to maintain the new
interface and the legacy one always up-to-date

#define PETSC_NS(DECL) \
     Petsc##DECL

and then

PetscErrorCode PETSC_NS(MatMult)(....)




On 3/17/08, Aron Ahmadia <aja2111 at columbia.edu> wrote:
> Can the namespace issue be fixed with some macro magic?
>
>  #ifdef UNIQUE_PETSC_NAMESPACE
>  #define Mat PetscMat
>  #endif
>
>  ...
>  ...
>
>  #undef Mat
>
>  This seems like it would satisfy both parties, and a compiler/build
>  flag could uniqueify the namespace if needed.
>
>
>  ~A
>
>
>  On Mon, Mar 17, 2008 at 11:23 AM, Matthew Knepley <knepley at gmail.com> wrote:
>  > On Sun, Mar 16, 2008 at 7:38 PM, 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
>  >
>  >  This seems not too hard. Just a layer on top to run the code a user must
>  >  run now.
>  >
>  >
>  >  >  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). 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.
>  >
>  >  I guess I still do not see the need for this. NIMROD is a not a sufficient
>  >  driver in my mind. If we really want namespaces, use a real language that
>  >  has namespaces. There are plenty. If we are still using C, I say we stick
>  >  with the old division. The imposition of this much pain on the overwhelming
>  >  majority of users seems unjustified.
>  >
>  >  Namespaces issues can be trivially fixed in say C++, which we should do.
>  >
>  >     Matt
>  >
>  >
>  >
>  >  >      Maybe we can do a release in around a couple of months, it would
>  >  >  be 2.4
>  >  >
>  >  >     Barry
>  >  >
>  >  >
>  >  >
>  >
>  >
>  >
>  >  --
>  >  What most experimenters take for granted before they begin their
>  >  experiments is infinitely more interesting than any results to which
>  >  their experiments lead.
>  >  -- Norbert Wiener
>  >
>  >
>
>


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