changes for next PETSc release
On 3/16/08, Barry Smith 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 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. > 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. 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. > . > > 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
changes for next PETSc release
On Mar 17, 2008, at 9:43 AM, Lisandro Dalcin wrote: > On 3/16/08, Barry Smith 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 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 >
changes for next PETSc release
On Sun, Mar 16, 2008 at 7:38 PM, Barry Smith 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 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
changes for next PETSc release
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 wrote: > On Sun, Mar 16, 2008 at 7:38 PM, Barry Smith 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 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 > >
changes for next PETSc release
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 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 > wrote: > > On Sun, Mar 16, 2008 at 7:38 PM, Barry Smith 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 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
changes for next PETSc release
> > > 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 Perhaps it would be helpful to some people if you distribute a script that can be run in an application src/ directory to find/replace all affected function names. Rich
changes for next PETSc release
On Mar 17, 2008, at 10:23 AM, Matthew Knepley wrote: > On Sun, Mar 16, 2008 at 7:38 PM, Barry Smith > 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 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. It is not very hard, but piling shit on top of shit is not the best way to write software. I have a method to reorganize that removes the old shit thus both simplifying the model and making it more user friendly. > > >> 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. You are an elitist who thinks that important ideas can only come from important/smart people. This I disagree strongly with, one should look everywhere, even at the local dump, for good ideas. NIMROD is not the driver, it is merely the spark. > 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. You seem to be saying we should stick with a bad decision I made many years ago, just because it is painful to change. When did you suddenly become conservative? > > > 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 >
changes for next PETSc release
This would be nice. Maybe we could do this with appropriate regular expressions. Sed and awk :-) Barry On Mar 17, 2008, at 10:04 AM, Richard Katz wrote: >> >> >> 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 > > Perhaps it would be helpful to some people if you distribute a > script that can be run in an application src/ directory to find/ > replace all affected function names. > > Rich >
changes for next PETSc release
On Mon, Mar 17, 2008 at 12:27 PM, Barry Smith wrote: > >> 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. > > You are an elitist who thinks that important ideas can only come > from important/smart people. This I disagree strongly with, one should > look everywhere, even at the local dump, for good ideas. NIMROD is > not the driver, it is merely the spark. I will be more specific. I think there is no good idea connected with this requirement of NIMROD. In fact, I think it is a very very bad idea. They are using a language with namespaces (F90) but they ignore them. Then they wonder why uses a product from a language without namespaces (C) they have a problem. The wrong strategy is to do something complicated in the deficient language. The right thing to do is something easy in the language with support. Why can't we just do an F90 binding with namespaces? That would fix NIMROD and not disrupt the community who has not complained (and who is much much bigger). > > 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. > > You seem to be saying we should stick with a bad decision I made > many years ago, just because it is painful to change. When did you > suddenly become conservative? No, I am saying that the fix is crap because it is complicated, entails enormous changes to the code, and is ugly. I think the correct fix is to use nice mechanisms in languages that support them, like C++. I am completely against forcing weak language mechanisms to do complicated things, which is why I hate all those template tricks. Also, we should look at history. We have made mistakes in the past when changing the interface (KSPSolve() with no arguments) which were painful. I want to make sure what we choose to do is as simple and non-painful as possible. Matt -- 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
changes for next PETSc release
Fortran90 has namespaces?? On Mar 17, 2008, at 12:59 PM, Matthew Knepley wrote: > On Mon, Mar 17, 2008 at 12:27 PM, Barry Smith > wrote: 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. >> >>You are an elitist who thinks that important ideas can only come >> from important/smart people. This I disagree strongly with, one >> should >> look everywhere, even at the local dump, for good ideas. NIMROD is >> not the driver, it is merely the spark. > > I will be more specific. I think there is no good idea connected > with this > requirement of NIMROD. In fact, I think it is a very very bad idea. > They are > using a language with namespaces (F90) but they ignore them. Then they > wonder why uses a product from a language without namespaces (C) they > have a problem. The wrong strategy is to do something complicated in > the > deficient language. The right thing to do is something easy in the > language > with support. > > Why can't we just do an F90 binding with namespaces? That would fix > NIMROD > and not disrupt the community who has not complained (and who is much > much bigger). > >>> 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. >> >>You seem to be saying we should stick with a bad decision I made >> many years ago, just because it is painful to change. When did you >> suddenly become conservative? > > No, I am saying that the fix is crap because it is complicated, > entails > enormous changes to the code, and is ugly. I think the correct fix is > to use nice mechanisms in languages that support them, like C++. > I am completely against forcing weak language mechanisms to do > complicated things, which is why I hate all those template tricks. > > Also, we should look at history. We have made mistakes in the past > when changing the interface (KSPSolve() with no arguments) which > were painful. I want to make sure what we choose to do is as simple > and non-painful as possible. > > Matt > > -- > 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 >
changes for next PETSc release
Well, Fortran 90 modules provide a sort of namespace support, I think. On 3/17/08, Barry Smith wrote: > > Fortran90 has namespaces?? > > > On Mar 17, 2008, at 12:59 PM, Matthew Knepley wrote: > > > On Mon, Mar 17, 2008 at 12:27 PM, Barry Smith > > wrote: > 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. > >> > >>You are an elitist who thinks that important ideas can only come > >> from important/smart people. This I disagree strongly with, one > >> should > >> look everywhere, even at the local dump, for good ideas. NIMROD is > >> not the driver, it is merely the spark. > > > > I will be more specific. I think there is no good idea connected > > with this > > requirement of NIMROD. In fact, I think it is a very very bad idea. > > They are > > using a language with namespaces (F90) but they ignore them. Then they > > wonder why uses a product from a language without namespaces (C) they > > have a problem. The wrong strategy is to do something complicated in > > the > > deficient language. The right thing to do is something easy in the > > language > > with support. > > > > Why can't we just do an F90 binding with namespaces? That would fix > > NIMROD > > and not disrupt the community who has not complained (and who is much > > much bigger). > > > >>> 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. > >> > >>You seem to be saying we should stick with a bad decision I made > >> many years ago, just because it is painful to change. When did you > >> suddenly become conservative? > > > > No, I am saying that the fix is crap because it is complicated, > > entails > > enormous changes to the code, and is ugly. I think the correct fix is > > to use nice mechanisms in languages that support them, like C++. > > I am completely against forcing weak language mechanisms to do > > complicated things, which is why I hate all those template tricks. > > > > Also, we should look at history. We have made mistakes in the past > > when changing the interface (KSPSolve() with no arguments) which > > were painful. I want to make sure what we choose to do is as simple > > and non-painful as possible. > > > > Matt > > > > -- > > 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
changes for next PETSc release
On Mon, Mar 17, 2008 at 1:06 PM, Barry Smith wrote: > > Fortran90 has namespaces?? Not in the way I was thinking. Damn F90. Anyway, it looks like you can selectively use interface modules, so we might be able to get away with redundant names by just not using them together. I jsut really hate the idea of putting "PETSc" in front of every word in the package. It is really the ugliest thing I can imagine and will make programming that much more of a slog. Matt > On Mar 17, 2008, at 12:59 PM, Matthew Knepley wrote: > > > On Mon, Mar 17, 2008 at 12:27 PM, Barry Smith > > wrote: > 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. > >> > >>You are an elitist who thinks that important ideas can only come > >> from important/smart people. This I disagree strongly with, one > >> should > >> look everywhere, even at the local dump, for good ideas. NIMROD is > >> not the driver, it is merely the spark. > > > > I will be more specific. I think there is no good idea connected > > with this > > requirement of NIMROD. In fact, I think it is a very very bad idea. > > They are > > using a language with namespaces (F90) but they ignore them. Then they > > wonder why uses a product from a language without namespaces (C) they > > have a problem. The wrong strategy is to do something complicated in > > the > > deficient language. The right thing to do is something easy in the > > language > > with support. > > > > Why can't we just do an F90 binding with namespaces? That would fix > > NIMROD > > and not disrupt the community who has not complained (and who is much > > much bigger). > > > >>> 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. > >> > >>You seem to be saying we should stick with a bad decision I made > >> many years ago, just because it is painful to change. When did you > >> suddenly become conservative? > > > > No, I am saying that the fix is crap because it is complicated, > > entails > > enormous changes to the code, and is ugly. I think the correct fix is > > to use nice mechanisms in languages that support them, like C++. > > I am completely against forcing weak language mechanisms to do > > complicated things, which is why I hate all those template tricks. > > > > Also, we should look at history. We have made mistakes in the past > > when changing the interface (KSPSolve() with no arguments) which > > were painful. I want to make sure what we choose to do is as simple > > and non-painful as possible. > > > > Matt > > > > -- > > 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 > > > > -- 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
changes for next PETSc release
On Mon, 17 Mar 2008, Matthew Knepley wrote: > On Mon, Mar 17, 2008 at 1:06 PM, Barry Smith wrote: > > > > Fortran90 has namespaces?? > > Not in the way I was thinking. Damn F90. Anyway, it looks like you > can selectively use interface modules, so we might be able to get > away with redundant names by just not using them together. > I jsut really hate the idea of putting "PETSc" in front of every > word in the package. It is really the ugliest thing I can imagine > and will make programming that much more of a slog. We already do this for lot of things. [this wasn't the case when we started] - all petsc libraries now have a 'petsc' prefix. - all configure flags have petsc prefix [this wasn't the case - when we started]. - all petsc datatypes now have petsc prefix. And wrt namesapcing, the correct thing to do is expand the namespace to languages without it. [not ingore it]. For eg: All MPI rutines have 'MPI' name space. The way its implemented is: MPI::Comm_rank() - c++ MPI_Comm_rank() - C,F77 [but just because c doesn't have namespace -they didn't decide to use just Comm_rank() for c] The biggest issue is: PETSc tries to use full names for functions, and we usually exceed 32char limit on some machines. And additional 5 chars to each function name might tip us over this limit. Satish
changes for next PETSc release
Matthew Knepley wrote: > On Mon, Mar 17, 2008 at 1:06 PM, Barry Smith wrote: >> Fortran90 has namespaces?? > > Not in the way I was thinking. Damn F90. Anyway, it looks like you can > selectively > use interface modules, so we might be able to get away with redundant names > by just not using them together. > > I jsut really hate the idea of putting "PETSc" in front of every word > in the package. > It is really the ugliest thing I can imagine and will make programming that > much > more of a slog. I'm not confident that what I'm about to suggest is actually a good idea, but perhaps there could be two interfaces: one for C and one for C++. The C interface could use something like "petsc_" as a prefix for all PETSc functions and structs (e.g., petsc_Mat and petsc_KSPSolve()), and the C++ interface could define everything in the petsc namespace (e.g., petsc::Mat and petsc::KSPSolve()). I think that it should be straightforward to make a script to automate the generation of the C++ interface from the C interface, e.g. using typedefs for the various structs and inline functions that simply call the appropriate C function. Folks who really want to avoid re-writing large amounts of code could switch to using a C++ compiler instead of a C compiler and use "using namespace petsc". Possibly the "using namespace" declaration could be done automatically in the PETSc headers when an appropraite variable is #define'd (e.g., whenever PETSC_COMPATIBILITY_MODE is #define'd). -- Boyce
