February 2012 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Examples broken
by Satish Balay 15 Feb '12

15 Feb '12

On Wed, 15 Feb 2012, Barry Smith wrote: > > On Feb 15, 2012, at 9:28 AM, Jose E. Roman wrote: > > > With the latest petsc-dev I get the following error in many examples (e.g. src/ksp/ksp/examples/tutorials/ex12.c ): > > > > [0]PETSC ERROR: Object is in wrong state! > > [0]PETSC ERROR: Must call MatXXXSetPreallocation() or MatSetUp() on argument 1 "mat" before MatGetOwnershipRange()! > > > > I guess the idea is to add MatSetUp() in all examples? Or will this error be removed eventually? > > It looks like you need to as the message says either do the preallocation or call MatSetUp(). The problem is that delaying the setup may mean that it tries to do it in MatSetValues() which is not collective so one may get a hang. Previously MatGetOwnershipRange() was sometimes a collective on the first call (if no preallocation or setup was done), now it is never a collective. > The breakage is in petsc examples. I fixed some [haven't pushed yet]. Will try to fix as many as I can find - and push today.. Satish

1 0

Re: [petsc-dev] Examples broken
by Barry Smith 15 Feb '12

15 Feb '12

On Feb 15, 2012, at 9:28 AM, Jose E. Roman wrote: > With the latest petsc-dev I get the following error in many examples (e.g. src/ksp/ksp/examples/tutorials/ex12.c ): > > [0]PETSC ERROR: Object is in wrong state! > [0]PETSC ERROR: Must call MatXXXSetPreallocation() or MatSetUp() on argument 1 "mat" before MatGetOwnershipRange()! > > I guess the idea is to add MatSetUp() in all examples? Or will this error be removed eventually? It looks like you need to as the message says either do the preallocation or call MatSetUp(). The problem is that delaying the setup may mean that it tries to do it in MatSetValues() which is not collective so one may get a hang. Previously MatGetOwnershipRange() was sometimes a collective on the first call (if no preallocation or setup was done), now it is never a collective. Barry > > Jose > >

1 0

Examples broken
by Jose E. Roman 15 Feb '12

15 Feb '12

With the latest petsc-dev I get the following error in many examples (e.g. src/ksp/ksp/examples/tutorials/ex12.c ): [0]PETSC ERROR: Object is in wrong state! [0]PETSC ERROR: Must call MatXXXSetPreallocation() or MatSetUp() on argument 1 "mat" before MatGetOwnershipRange()! I guess the idea is to add MatSetUp() in all examples? Or will this error be removed eventually? Jose

1 0

Re: [petsc-dev] http://mercurial.selenic.com/wiki/MercurialHosting
by Sean Farley 14 Feb '12

14 Feb '12

> > http://mercurial.selenic.com/wiki/MercurialHosting lists many mercurial > hosting sites. Given bitbuckets weak features in access control and no > hierarchical storage of repositories; are any of these better? No.

1 0

http://mercurial.selenic.com/wiki/MercurialHosting
by Barry Smith 14 Feb '12

14 Feb '12

http://mercurial.selenic.com/wiki/MercurialHosting lists many mercurial hosting sites. Given bitbuckets weak features in access control and no hierarchical storage of repositories; are any of these better? Barry

1 0

Re: [petsc-dev] XXDestroy() can be called more than once while changing type through an indirect type name
by Jed Brown 13 Feb '12

13 Feb '12

On Mon, Feb 13, 2012 at 00:42, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > An alternative is to make clear vec->ops->destroy after calling it. This > seems more robust, so I'm inclined to do it. > I chose this version, let me know if you prefer the more radical variant. http://petsc.cs.iit.edu/petsc/petsc-dev/rev/1262149b3e20 > > A more radical alternative is to zero the whole vtable. Are there use > cases where the user wants to change the type, but still expects some of > their own MatOps to not be overwritten when changing the type? >

1 0

Re: [petsc-dev] OpenMP support
by Gerard Gorman 13 Feb '12

13 Feb '12

Matthew Knepley emailed the following on 14/02/12 00:34: > > As a first step - can we add OpenMP support to PETSc conf? > Lawrence made > a first pass at this: > https://bitbucket.org/wence/petsc-dev-omp/src/52afd5fd2c25/config/PETSc/pac… > It does need extending because it will fail in it is current state > for a > number of compilers. I am guessing we would have to reimplement > something like ax_openmp or similar...what is the right thing to > do here? > > > Can you explain the right test? The definitive test would be to try to compile a test code: eg int main(){ #ifndef _OPENMP choke me #endif return 0; } The OpenMP standard specifies that the preprocessor macro name _OPENMP should be set. As for the actual compile flag ... reading FindOpenMP.cmake you can see that they take the test compile approach as above, and they have a list of candidates (OpenMP_C_FLAG_CANDIDATES) which are tested. Another option would be to allow --with-openmp[=magic_flag] for the odd compiler not recognised. For example I notice that the Fujitsu compiler is not listed in FindOpenMP.cmake. Cheers Gerard

1 0

Re: [petsc-dev] OpenMP support
by Matthew Knepley 13 Feb '12

13 Feb '12

On Mon, Feb 13, 2012 at 9:28 AM, Gerard Gorman <g.gorman(a)imperial.ac.uk>wrote: > Hi > > I have been working with Lawrence Mitchell and Michele Weiland at EPCC > to add OpenMP support to the mat/vec classes and we are at the stage > that we would like to give other other people a chance to play with it. > > Lawrence put a branch on bitbucket if you want to browse: > https://bitbucket.org/wence/petsc-dev-omp/overview > > I think that there is a lot in there that needs > discussion(/modification), so I propose that we try to break this into a > number of discussions/steps (also I do not want to write a several page > email). > > I am making the assumption here that OpenMP is interesting enough to > want to put in PETSc. Other than the garden variety multicore, it can > also be used on Intel MIC. Does this need further discussion? > > As a first step - can we add OpenMP support to PETSc conf? Lawrence made > a first pass at this: > > https://bitbucket.org/wence/petsc-dev-omp/src/52afd5fd2c25/config/PETSc/pac… > It does need extending because it will fail in it is current state for a > number of compilers. I am guessing we would have to reimplement > something like ax_openmp or similar...what is the right thing to do here? > Can you explain the right test? > Regarding cmake - I only recently learned cmake myself and I have been > using: > FIND_PACKAGE(OpenMP) (i.e. cmake does all the heavy lifting in > FindOpenMP.cmake which it provides). However, as PETSc does not appear > to use the find_package feature I am not sure what approach should be > adopted for PETSc. Suggestions? > If the configure works right, there is nothing left to do for CMake. Matt > Cheers > Gerard > > -- 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

OpenMP support
by Gerard Gorman 13 Feb '12

13 Feb '12

Hi I have been working with Lawrence Mitchell and Michele Weiland at EPCC to add OpenMP support to the mat/vec classes and we are at the stage that we would like to give other other people a chance to play with it. Lawrence put a branch on bitbucket if you want to browse: https://bitbucket.org/wence/petsc-dev-omp/overview I think that there is a lot in there that needs discussion(/modification), so I propose that we try to break this into a number of discussions/steps (also I do not want to write a several page email). I am making the assumption here that OpenMP is interesting enough to want to put in PETSc. Other than the garden variety multicore, it can also be used on Intel MIC. Does this need further discussion? As a first step - can we add OpenMP support to PETSc conf? Lawrence made a first pass at this: https://bitbucket.org/wence/petsc-dev-omp/src/52afd5fd2c25/config/PETSc/pac… It does need extending because it will fail in it is current state for a number of compilers. I am guessing we would have to reimplement something like ax_openmp or similar...what is the right thing to do here? Regarding cmake - I only recently learned cmake myself and I have been using: FIND_PACKAGE(OpenMP) (i.e. cmake does all the heavy lifting in FindOpenMP.cmake which it provides). However, as PETSc does not appear to use the find_package feature I am not sure what approach should be adopted for PETSc. Suggestions? Cheers Gerard

1 0

XXDestroy() can be called more than once while changing type through an indirect type name
by Jed Brown 13 Feb '12

13 Feb '12

I found this issue when changing a VECSEQ to VECCUSP. The first step goes through without errors, but frees vec->data. #0 0x00000000004b8033 in VecDestroy_Seq (v=0x8f3a6b0) at bvec2.c:776 #1 0x0000000000496c07 in VecSetType (vec=0x8f3a6b0, method=0x7fffffffe140 "cusp") at vecreg.c:46 #2 0x0000000000491b7d in VecSetTypeFromOptions_Private (vec=0x8f3a6b0) at vector.c:1379 #3 0x0000000000492035 in VecSetFromOptions (vec=0x8f3a6b0) at vector.c:1416 #4 0x00000000005f9af1 in DMCreateGlobalVector_DA (da=0x8f2d2d0, g=0x7fffffffe3a8) at dadist.c:36 #5 0x0000000000638864 in DMCreateGlobalVector (dm=0x8f2d2d0, vec=0x7fffffffe3a8) at dm.c:363 #6 0x0000000000409079 in main (argc=7, argv=0x7fffffffe5c8) at ex47cu.cu:31 Since the function pointers were not cleared, we enter the same function again with vec->data zero and SEGV at this line. ierr = PetscFree(vs->array_allocated);CHKERRQ(ierr); #0 0x00000000004b7f43 in VecDestroy_Seq (v=0x8f3a6b0) at bvec2.c:775 #1 0x0000000000496c07 in VecSetType (vec=0x8f3a6b0, method=0x10706d5 "seqcusp") at vecreg.c:46 #2 0x0000000000528246 in VecCreate_CUSP (v=0x8f3a6b0) at mpicusp.cu:238 #3 0x0000000000496cb7 in VecSetType (vec=0x8f3a6b0, method=0x7fffffffe140 "cusp") at vecreg.c:52 #4 0x0000000000491b7d in VecSetTypeFromOptions_Private (vec=0x8f3a6b0) at vector.c:1379 #5 0x0000000000492035 in VecSetFromOptions (vec=0x8f3a6b0) at vector.c:1416 #6 0x00000000005f9af1 in DMCreateGlobalVector_DA (da=0x8f2d2d0, g=0x7fffffffe3a8) at dadist.c:36 #7 0x0000000000638864 in DMCreateGlobalVector (dm=0x8f2d2d0, vec=0x7fffffffe3a8) at dm.c:363 #8 0x0000000000409079 in main (argc=7, argv=0x7fffffffe5c8) at ex47cu.cu:31 The simplest fix is to wrap that call, but that semantic is a pain for the implementations. An alternative is to make clear vec->ops->destroy after calling it. This seems more robust, so I'm inclined to do it. A more radical alternative is to zero the whole vtable. Are there use cases where the user wants to change the type, but still expects some of their own MatOps to not be overwritten when changing the type?

1 0