From: Jed B. <je...@59...> - 2011-07-31 16:39:18
|
--- include/numerics/petsc_vector.h | 15 ++++++++++++++- 1 files changed, 14 insertions(+), 1 deletions(-) |
From: Jed B. <je...@59...> - 2011-07-31 16:39:34
|
--- include/numerics/petsc_macro.h | 10 +++++ include/numerics/petsc_vector.h | 2 +- src/numerics/petsc_matrix.C | 8 ++-- src/numerics/petsc_vector.C | 20 +++++----- src/solvers/petsc_diff_solver.C | 2 +- src/solvers/petsc_linear_solver.C | 72 +++++++++++++++++----------------- src/solvers/petsc_nonlinear_solver.C | 2 +- 7 files changed, 63 insertions(+), 53 deletions(-) |
From: Derek G. <fri...@gm...> - 2011-07-31 19:03:21
|
Sweet! Any timing numbers on this? We see a pretty good chunk of our runtime getting eaten up by mapping... Derek Sent from my iPad On Jul 31, 2011, at 10:39 AM, Jed Brown <je...@59...> wrote: > --- > include/numerics/petsc_vector.h | 15 ++++++++++++++- > 1 files changed, 14 insertions(+), 1 deletions(-) > > <0001-Use-public-LocalToGlobalMapping-APIs-unfortunately-n.patch> > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don't ask for help often. > Plus, you'll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Jed B. <je...@59...> - 2011-07-31 19:06:48
|
On Sun, Jul 31, 2011 at 14:03, Derek Gaston <fri...@gm...> wrote: > Sweet! Any timing numbers on this? We see a pretty good chunk of our > runtime getting eaten up by mapping... > This patch does not change the algorithm at all, it just uses a public API to access the local-to-global mapping (which we have moved around, so the private access will not work anymore). The right solution here is to get rid of the global-to-local mapping. There is no algorithmic reason to need it (at least in performance-sensitive locations). The local-to-global mapping is fast and scalable, so it should not be an issue. |
From: John P. <jwp...@gm...> - 2011-08-01 17:34:02
|
I can commit these patches unless someone else is already in the process of doing it... -- John On Sun, Jul 31, 2011 at 10:39 AM, Jed Brown <je...@59...> wrote: > --- > include/numerics/petsc_macro.h | 10 +++++ > include/numerics/petsc_vector.h | 2 +- > src/numerics/petsc_matrix.C | 8 ++-- > src/numerics/petsc_vector.C | 20 +++++----- > src/solvers/petsc_diff_solver.C | 2 +- > src/solvers/petsc_linear_solver.C | 72 +++++++++++++++++----------------- > src/solvers/petsc_nonlinear_solver.C | 2 +- > 7 files changed, 63 insertions(+), 53 deletions(-) |
From: Roy S. <roy...@ic...> - 2011-08-01 18:07:36
|
On Mon, 1 Aug 2011, John Peterson wrote: > I can commit these patches unless someone else is already in the > process of doing it... I'm still catching up on older stuff, and at first glance don't see any problems here; go for it. --- Roy |
From: John P. <jwp...@gm...> - 2011-08-01 18:49:56
|
On Mon, Aug 1, 2011 at 12:07 PM, Roy Stogner <roy...@ic...> wrote: > > On Mon, 1 Aug 2011, John Peterson wrote: > >> I can commit these patches unless someone else is already in the >> process of doing it... > > I'm still catching up on older stuff, and at first glance don't see > any problems here; go for it. The second patch is giving me some problems. I'm compiling against PETSc 2.3.3. Compiling C++ (in debug mode) src/numerics/numeric_vector.C... In file included from /opt/packages/petsc/gnu-opt/petsc-2.3.3-p13/include/petscvec.h:9, from /Users/petejw/projects/libmesh_git/include/numerics/petsc_vector.h:44, from src/numerics/numeric_vector.C:29: /opt/packages/petsc/gnu-opt/petsc-2.3.3-p13/include/petscis.h:33: warning: ‘ISDestroy’ initialized and declared ‘extern’ /opt/packages/petsc/gnu-opt/petsc-2.3.3-p13/include/petscis.h:33: error: expected primary-expression before ‘)’ token In file included from /Users/petejw/projects/libmesh_git/include/numerics/petsc_vector.h:44, from src/numerics/numeric_vector.C:29: /opt/packages/petsc/gnu-opt/petsc-2.3.3-p13/include/petscvec.h:72: warning: ‘VecDestroy’ initialized and declared ‘extern’ /opt/packages/petsc/gnu-opt/petsc-2.3.3-p13/include/petscvec.h:72: error: expected primary-expression before ‘)’ token /opt/packages/petsc/gnu-opt/petsc-2.3.3-p13/include/petscvec.h:325: warning: ‘VecScatterDestroy’ initialized and declared ‘extern’ /opt/packages/petsc/gnu-opt/petsc-2.3.3-p13/include/petscvec.h:325: error: expected primary-expression before ‘)’ token In file included from src/numerics/numeric_vector.C:29: /Users/petejw/projects/libmesh_git/include/numerics/petsc_vector.h: In member function ‘void libMesh::PetscVector<T>::clear()’: /Users/petejw/projects/libmesh_git/include/numerics/petsc_vector.h:934: error: ‘VecDestroy’ cannot be used as a function /Users/petejw/projects/libmesh_git/include/numerics/petsc_vector.h: In member function ‘void libMesh::PetscVector<T>::clear() [with T = double]’: src/numerics/numeric_vector.C:368: instantiated from here /Users/petejw/projects/libmesh_git/include/numerics/petsc_vector.h:934: error: ‘VecDestroy’ cannot be used as a function I think it's because petsc_macro.h is #include'd *before* the relevant petsc header, so the macro is defined before the extern XXDestroy functions are declared, at which point they get macro-fied...? Anyway, we can fix this by having a different name for our macro: #if PETSC_VERSION_RELEASE && PETSC_VERSION_LESS_THAN(3,1,1) # define LibMeshVecDestroy(x) VecDestroy(*(x)) # define LibMeshVecScatterDestroy(x) VecScatterDestroy(*(x)) # define LibMeshMatDestroy(x) MatDestroy(*(x)) # define LibMeshISDestroy(x) ISDestroy(*(x)) # define LibMeshKSPDestroy(x) KSPDestroy(*(x)) # define LibMeshSNESDestroy(x) SNESDestroy(*(x)) # define LibMeshPetscViewerDestroy(x) PetscViewerDestroy(*(x)) #else # define LibMeshVecDestroy(x) VecDestroy(x) # define LibMeshVecScatterDestroy(x) VecScatterDestroy(x) # define LibMeshMatDestroy(x) MatDestroy(x) # define LibMeshISDestroy(x) ISDestroy(x) # define LibMeshKSPDestroy(x) KSPDestroy(x) # define LibMeshSNESDestroy(x) SNESDestroy(x) # define LibMeshPetscViewerDestroy(x) PetscViewerDestroy(x) #endif I've implemented the above, but am open to suggestions on macro names and/or other solutions to the problem. -- John |
From: Jed B. <je...@59...> - 2011-08-01 19:22:01
|
On Mon, Aug 1, 2011 at 12:49, John Peterson <jwp...@gm...> wrote: > I think it's because petsc_macro.h is #include'd *before* the relevant > petsc header, so the macro is defined before the extern XXDestroy > functions are declared, at which point they get macro-fied...? > Hmm, I wonder why this would be different with 2.3.3 (which is too many years old for me to remember to test). Was there a reason why petsc_macro.h should be included first? > > Anyway, we can fix this by having a different name for our macro: > This is fine, thanks. |
From: John P. <jwp...@gm...> - 2011-08-01 20:48:30
|
On Mon, Aug 1, 2011 at 1:21 PM, Jed Brown <je...@59...> wrote: > On Mon, Aug 1, 2011 at 12:49, John Peterson <jwp...@gm...> wrote: >> >> I think it's because petsc_macro.h is #include'd *before* the relevant >> petsc header, so the macro is defined before the extern XXDestroy >> functions are declared, at which point they get macro-fied...? > > Hmm, I wonder why this would be different with 2.3.3 (which is too many > years old for me to remember to test). Was there a reason why petsc_macro.h > should be included first? Hmm... I think there used to be. We used to need to define EXTERN_C_FOR_PETSC_BEGIN EXTERN_C_FOR_PETSC_END inside petsc_macro.h, before we could include any other petsc headers. (At some point the petsc headers began extern C'ing themselves.) In general, though I'd like to avoid any weird future errors regardless of the order in which somebody decides to include petsc_macro... >> Anyway, we can fix this by having a different name for our macro: > > This is fine, thanks. Your patches are in now, thanks for sending them to us. -- John |
From: Jed B. <je...@59...> - 2011-08-01 21:08:20
|
On Mon, Aug 1, 2011 at 14:48, John Peterson <jwp...@gm...> wrote: > Hmm... I think there used to be. We used to need to define > > EXTERN_C_FOR_PETSC_BEGIN > EXTERN_C_FOR_PETSC_END > > inside petsc_macro.h, before we could include any other petsc headers. > (At some point the petsc headers began extern C'ing themselves.) > This was done as far back as 2.2.0 which is the oldest clone I have handy. |