March 2008 - petsc-dev - mailman3.cels.anl.gov

Re: ML with OpenMPI
by Barry Smith 21 Mar '08

21 Mar '08

Jed, You can take a look at config/PETSc/packages/ml.py; essentially we call their configure with a given set of compilers (and MPI information). So I would say you have to report the bug to those folks; their configure should handle that issue, shouldn't it. Barry On Mar 21, 2008, at 5:09 PM, Jed Brown wrote: > The MPI standard does not specify that MPI_Comm = int and in fact > OpenMPI uses a pointer value which lets the compiler do slightly more > type checking. This type checking recently caused me trouble when > building with-download-ml. > > There is a line in ml_comm.h which defines their communicator to be an > int when ML_MPI is not defined. It was not immediately clear why this > is not defined, but result is that the compiler chokes when building > PETSc. This patch fixes the problem as long as sizeof(int) = > sizeof(MPI_Comm), but this is *not* the case on x86_64 with OpenMPI. > It's not clear to me how much of this is an upstream issue and how > much > is a configuration issue. > > Jed > > > diff -r c074838b79ed src/ksp/pc/impls/ml/ml.c > --- a/src/ksp/pc/impls/ml/ml.c Thu Mar 20 17:04:05 2008 -0500 > +++ b/src/ksp/pc/impls/ml/ml.c Fri Mar 21 22:50:32 2008 +0100 > @@ -815,7 +815,7 @@ PetscErrorCode MatWrapML_SHELL(ML_Operat > > MLcomm = mlmat->comm; > ierr = PetscNew(Mat_MLShell,&shellctx);CHKERRQ(ierr); > - ierr = > MatCreateShell(MLcomm- > > > USR_comm > ,m,n,PETSC_DETERMINE,PETSC_DETERMINE,shellctx,newmat);CHKERRQ(ierr); > + ierr = > MatCreateShell((MPI_Comm)MLcomm- > > > USR_comm > ,m,n,PETSC_DETERMINE,PETSC_DETERMINE,shellctx,newmat);CHKERRQ(ierr); > ierr = > MatShellSetOperation(*newmat,MATOP_MULT,(void(*) > (void))MatMult_ML);CHKERRQ(ierr); > ierr = > MatShellSetOperation(*newmat,MATOP_MULT_ADD,(void(*) > (void))MatMultAdd_ML);CHKERRQ(ierr); > shellctx->A = *newmat; > @@ -844,7 +844,7 @@ PetscErrorCode MatWrapML_MPIAIJ(ML_Opera > n = mlmat->invec_leng; > if (m != n) SETERRQ2(PETSC_ERR_ARG_OUTOFRANGE,"m %d must equal to n > %d",m,n); > > - ierr = MatCreate(mlmat->comm->USR_comm,&A);CHKERRQ(ierr); > + ierr = MatCreate((MPI_Comm)mlmat->comm->USR_comm,&A);CHKERRQ(ierr); > ierr = MatSetSizes(A,m,n,PETSC_DECIDE,PETSC_DECIDE);CHKERRQ(ierr); > ierr = MatSetType(A,MATMPIAIJ);CHKERRQ(ierr); > ierr = > PetscMalloc3 > (m,PetscInt,&nnzA,m,PetscInt,&nnzB,m,PetscInt,&nnz);CHKERRQ(ierr);

1 0

ML with OpenMPI
by Jed Brown 21 Mar '08

21 Mar '08

The MPI standard does not specify that MPI_Comm = int and in fact OpenMPI uses a pointer value which lets the compiler do slightly more type checking. This type checking recently caused me trouble when building with-download-ml. There is a line in ml_comm.h which defines their communicator to be an int when ML_MPI is not defined. It was not immediately clear why this is not defined, but result is that the compiler chokes when building PETSc. This patch fixes the problem as long as sizeof(int) = sizeof(MPI_Comm), but this is *not* the case on x86_64 with OpenMPI. It's not clear to me how much of this is an upstream issue and how much is a configuration issue. Jed diff -r c074838b79ed src/ksp/pc/impls/ml/ml.c --- a/src/ksp/pc/impls/ml/ml.c Thu Mar 20 17:04:05 2008 -0500 +++ b/src/ksp/pc/impls/ml/ml.c Fri Mar 21 22:50:32 2008 +0100 @@ -815,7 +815,7 @@ PetscErrorCode MatWrapML_SHELL(ML_Operat MLcomm = mlmat->comm; ierr = PetscNew(Mat_MLShell,&shellctx);CHKERRQ(ierr); - ierr = MatCreateShell(MLcomm->USR_comm,m,n,PETSC_DETERMINE,PETSC_DETERMINE,shellctx,newmat);CHKERRQ(ierr); + ierr = MatCreateShell((MPI_Comm)MLcomm->USR_comm,m,n,PETSC_DETERMINE,PETSC_DETERMINE,shellctx,newmat);CHKERRQ(ierr); ierr = MatShellSetOperation(*newmat,MATOP_MULT,(void(*)(void))MatMult_ML);CHKERRQ(ierr); ierr = MatShellSetOperation(*newmat,MATOP_MULT_ADD,(void(*)(void))MatMultAdd_ML);CHKERRQ(ierr); shellctx->A = *newmat; @@ -844,7 +844,7 @@ PetscErrorCode MatWrapML_MPIAIJ(ML_Opera n = mlmat->invec_leng; if (m != n) SETERRQ2(PETSC_ERR_ARG_OUTOFRANGE,"m %d must equal to n %d",m,n); - ierr = MatCreate(mlmat->comm->USR_comm,&A);CHKERRQ(ierr); + ierr = MatCreate((MPI_Comm)mlmat->comm->USR_comm,&A);CHKERRQ(ierr); ierr = MatSetSizes(A,m,n,PETSC_DECIDE,PETSC_DECIDE);CHKERRQ(ierr); ierr = MatSetType(A,MATMPIAIJ);CHKERRQ(ierr); ierr = PetscMalloc3(m,PetscInt,&nnzA,m,PetscInt,&nnzB,m,PetscInt,&nnz);CHKERRQ(ierr);

1 0

configuring with --prefix
by Lisandro Dalcin 21 Mar '08

21 Mar '08

I got this error at configuration time: You do not have write access to create install directory given with --prefix=/usr/local/petsc/dev/linux-gnu perhaps use --with-sudo=sudo also Then I've added, the sudo stuff and worked. However, after the configuation, the dir was not created. So the question is: in which scenario PETSc does need access to the install dir at configuration time? -- 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

1 0

Re: changes for next PETSc release
by Boyce Griffith 17 Mar '08

17 Mar '08

Matthew Knepley wrote: > On Mon, Mar 17, 2008 at 1:06 PM, Barry Smith <bsmith(a)mcs.anl.gov> 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

1 0

Re: changes for next PETSc release
by Satish Balay 17 Mar '08

17 Mar '08

On Mon, 17 Mar 2008, Matthew Knepley wrote: > On Mon, Mar 17, 2008 at 1:06 PM, Barry Smith <bsmith(a)mcs.anl.gov> 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

1 0

Re: changes for next PETSc release
by Matthew Knepley 17 Mar '08

17 Mar '08

On Mon, Mar 17, 2008 at 1:06 PM, Barry Smith <bsmith(a)mcs.anl.gov> 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 <bsmith(a)mcs.anl.gov> > > 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

1 0

Re: changes for next PETSc release
by Lisandro Dalcin 17 Mar '08

17 Mar '08

Well, Fortran 90 modules provide a sort of namespace support, I think. On 3/17/08, Barry Smith <bsmith(a)mcs.anl.gov> 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 <bsmith(a)mcs.anl.gov> > > 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

1 0

Re: changes for next PETSc release
by Barry Smith 17 Mar '08

17 Mar '08

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 <bsmith(a)mcs.anl.gov> > 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 >

1 0

Re: changes for next PETSc release
by Matthew Knepley 17 Mar '08

17 Mar '08

On Mon, Mar 17, 2008 at 12:27 PM, Barry Smith <bsmith(a)mcs.anl.gov> 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

1 0

Re: changes for next PETSc release
by Barry Smith 17 Mar '08

17 Mar '08

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 >

1 0