[petsc-dev] XXDestroy() can be called more than once while changing type through an indirect type name
On Mon, Feb 13, 2012 at 00:42, Jed Brown 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? > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120213/157741b1/attachment.html>
[petsc-dev] OpenMP support
On Mon, Feb 13, 2012 at 9:28 AM, Gerard Gorman 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/packages/openmp.py > 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 -- next part ------ An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120213/af0ebdbf/attachment.html>
[petsc-dev] OpenMP support
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/packages/openmp.py 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
[petsc-dev] XXDestroy() can be called more than once while changing type through an indirect type name
I found this issue when changing a VECSEQ to VECCUSP. The first step goes through without errors, but frees vec->data. #0 0x004b8033 in VecDestroy_Seq (v=0x8f3a6b0) at bvec2.c:776 #1 0x00496c07 in VecSetType (vec=0x8f3a6b0, method=0x7fffe140 "cusp") at vecreg.c:46 #2 0x00491b7d in VecSetTypeFromOptions_Private (vec=0x8f3a6b0) at vector.c:1379 #3 0x00492035 in VecSetFromOptions (vec=0x8f3a6b0) at vector.c:1416 #4 0x005f9af1 in DMCreateGlobalVector_DA (da=0x8f2d2d0, g=0x7fffe3a8) at dadist.c:36 #5 0x00638864 in DMCreateGlobalVector (dm=0x8f2d2d0, vec=0x7fffe3a8) at dm.c:363 #6 0x00409079 in main (argc=7, argv=0x7fffe5c8) 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 0x004b7f43 in VecDestroy_Seq (v=0x8f3a6b0) at bvec2.c:775 #1 0x00496c07 in VecSetType (vec=0x8f3a6b0, method=0x10706d5 "seqcusp") at vecreg.c:46 #2 0x00528246 in VecCreate_CUSP (v=0x8f3a6b0) at mpicusp.cu:238 #3 0x00496cb7 in VecSetType (vec=0x8f3a6b0, method=0x7fffe140 "cusp") at vecreg.c:52 #4 0x00491b7d in VecSetTypeFromOptions_Private (vec=0x8f3a6b0) at vector.c:1379 #5 0x00492035 in VecSetFromOptions (vec=0x8f3a6b0) at vector.c:1416 #6 0x005f9af1 in DMCreateGlobalVector_DA (da=0x8f2d2d0, g=0x7fffe3a8) at dadist.c:36 #7 0x00638864 in DMCreateGlobalVector (dm=0x8f2d2d0, vec=0x7fffe3a8) at dm.c:363 #8 0x00409079 in main (argc=7, argv=0x7fffe5c8) 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? -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120213/78130c43/attachment.html>
