From: Benjamin S. K. <not...@gi...> - 2013-02-17 17:36:14
|
Both are actively developed and increasingly support threads, which are a significant benefit for shared-memory machines when you don't want to deal with MPI. Eigen is released under the MPL, so as we discussed before I think we could depend heavily on it and ultimately expect it to be available: http://eigen.tuxfamily.org/index.php?title=Licensing_FAQ Suitesparse is GPL, so it shouldn't be a core dependency. @libmesh-devel, thoughts? --- Reply to this email directly or view it on GitHub: https://github.com/libMesh/libmesh/issues/44 |
From: jwpeterson <not...@gi...> - 2013-02-17 20:52:19
|
-- John On Feb 17, 2013, at 10:36 AM, "Benjamin S. Kirk" <not...@gi...> wrote: > Both are actively developed and increasingly support threads, which are a significant benefit for shared-memory machines when you don't want to deal with MPI. > > Eigen is released under the MPL, so as we discussed before I think we could depend heavily on it and ultimately expect it to be available: > http://eigen.tuxfamily.org/index.php?title=Licensing_FAQ > > Suitesparse is GPL, so it shouldn't be a core dependency. > > @libmesh-devel, thoughts? > Eigen is all headers so its really nice. Also we already configure for it, so it should be easy to just include with libmesh... --- Reply to this email directly or view it on GitHub: https://github.com/libMesh/libmesh/issues/44#issuecomment-13695319 |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2013-02-17 21:23:42
|
On Feb 17, 2013, at 2:52 PM, jwpeterson <not...@gi...> wrote: > > Eigen is all headers so its really nice. Also we already configure for it, so it should be easy to just include with libmesh… I've got a branch going for this and will have a pull request soon - you are right, it's easy… -Ben |
From: roystgnr <not...@gi...> - 2013-02-17 22:15:08
|
Fantastic - thanks, Ben! --- Reply to this email directly or view it on GitHub: https://github.com/libMesh/libmesh/issues/44#issuecomment-13698058 |
From: Paul T. B. <not...@gi...> - 2013-02-18 03:01:37
|
Rock on, sir. Thanks! --- Reply to this email directly or view it on GitHub: https://github.com/libMesh/libmesh/issues/44#issuecomment-13704643 |
From: jwpeterson <not...@gi...> - 2013-02-18 16:02:25
|
@benkirk is your plan here to add a new SolverPackage enumeration and LinearSolver subclass? Looks like Eigen supports several sparse iterative and direct solvers... http://eigen.tuxfamily.org/dox/TutorialSparse.html#TutorialSparseDirectSolvers --- Reply to this email directly or view it on GitHub: https://github.com/libMesh/libmesh/issues/44#issuecomment-13728496 |
From: Benjamin S. K. <not...@gi...> - 2013-02-18 16:34:22
|
Precisely. They support some sparse iterative solvers internally (GC and BiCGSTAB are blessed, GMRES is in unsupported but looks like it is incoming), and can interface with SuiteSparse to do sparse direct. I think we'll easily be able to support the sparse iterative stuff easily enough, as it is all Eigen3, and I'm looking at the sparse direct. I think an option to use an installed SuiteSparse it the way to go (building it is nontrivial), but there is an autotools port that we could fall back to - I'm playing with that now to see how big it would be (https://github.com/benkirk/suitesparse.git) --- Reply to this email directly or view it on GitHub: https://github.com/libMesh/libmesh/issues/44#issuecomment-13730191 |
From: Paul T. B. <not...@gi...> - 2013-02-18 17:51:29
|
On Mon, Feb 18, 2013 at 10:34 AM, Benjamin S. Kirk <not...@gi... > wrote: > I think an option to use an installed SuiteSparse it the way to go > (building it is nontrivial), > Check out our build scripts on the ICES system (/opt/apps/ossw/build_scripts/octave ... I think). I setup a build script for SuiteSparse that might be helpful. --- Reply to this email directly or view it on GitHub: https://github.com/libMesh/libmesh/issues/44#issuecomment-13734052 |
From: jwpeterson <not...@gi...> - 2013-02-18 18:26:46
|
Testing gmail filtering... disregard. --- Reply to this email directly or view it on GitHub: https://github.com/libMesh/libmesh/issues/44#issuecomment-13735697 |
From: Benjamin S. K. <not...@gi...> - 2013-02-18 18:36:24
|
Make that https://github.com/libMesh/suitesparse.git - I needed to make some changes, forked it to my personal account, but thought it more legitimate to put it somewhere the whole team could commit to, if needed. This is a pretty slick wrapper: ```bash $ ./build.bash ALL ``` --- Reply to this email directly or view it on GitHub: https://github.com/libMesh/libmesh/issues/44#issuecomment-13736158 |
From: Benjamin S. K. <not...@gi...> - 2013-02-20 22:30:20
|
I've got a branch at https://github.com/benkirk/libmesh.git working this, feel free to throw stones... --- Reply to this email directly or view it on GitHub: https://github.com/libMesh/libmesh/issues/44#issuecomment-13860951 |
From: Benjamin S. K. <not...@gi...> - 2013-02-21 16:08:45
|
Argh!!! MatType is a template parameter for Eigen, and a #define by PETSc... let the hackery ensue. --- Reply to this email directly or view it on GitHub: https://github.com/libMesh/libmesh/issues/44#issuecomment-13896806 |
From: roystgnr <not...@gi...> - 2013-02-21 16:26:40
|
On Thu, 21 Feb 2013, Benjamin S. Kirk wrote: > Argh!!! MatType is a template parameter for Eigen, and a #define by PETSc... A #define in which PETSc header? It seems like we should be trying to keep that out of non-petsc-related source files regardless. --- Reply to this email directly or view it on GitHub: https://github.com/libMesh/libmesh/issues/44#issuecomment-13897839 |
From: Benjamin S. K. <not...@gi...> - 2013-02-21 16:37:57
|
On Feb 21, 2013, at 10:25 AM, roystgnr <not...@gi...> wrote: > A #define in which PETSc header? It seems like we should be trying to > keep that out of non-petsc-related source files regardless. benkirk(3)$ grep -r MatType /software/x86_64/petsc/3.3-p4/include | grep define /software/x86_64/petsc/3.3-p4/include/finclude/petscmatdef.h:#define MatType character*(80) --- Reply to this email directly or view it on GitHub: https://github.com/libMesh/libmesh/issues/44#issuecomment-13898539 |
From: Roy S. <roy...@ic...> - 2013-02-21 16:48:04
|
On Thu, 21 Feb 2013, Benjamin S. Kirk wrote: > benkirk(3)$ grep -r MatType /software/x86_64/petsc/3.3-p4/include | grep define > /software/x86_64/petsc/3.3-p4/include/finclude/petscmatdef.h:#define MatType character*(80) It's also in petscmat.h in their C includes, which gets it into our petsc_matrix.h, all reasonably enough... Except that then petsc_matrix.h needs to be included in sparse_matrix.C for use in SparseMatrix<T>::build(), and so do the Eigen headers, and then stuff breaks. I can think of a few ways to fix this, but all are pretty ugly... |
From: Benjamin S. K. <not...@gi...> - 2013-02-21 17:00:50
|
On Feb 21, 2013, at 10:47 AM, LibMesh Developers <not...@gi...> wrote: > > I can think of a few ways to fix this, but all are pretty ugly… For now this seems to do the trick, but it is a one-off… // hack to avoid MatType collision... #undef libMeshSaveMatType #ifdef MatType # define MatType libMeshSaveMatType # undef MatType #endif // Eigen includes #include <Eigen/Dense> #include <Eigen/Sparse> #ifdef libMeshSaveMatType # define libMeshSaveMatType MatType # undef libMeshSaveMatType #endif --- Reply to this email directly or view it on GitHub: https://github.com/libMesh/libmesh/issues/44#issuecomment-13899872 |
From: Roy S. <roy...@ic...> - 2013-02-21 17:24:46
|
On Thu, 21 Feb 2013, Benjamin S. Kirk wrote: > For now this seems to do the trick, but it is a one-off… Yeah; that'll break just as soon as PETSc replaces that macro with a typedef, but good enough for now. I think the long-term solution is going to have to be {petsc,eigen...}_matrix_build.{h,C} files, each with a PetscMatrixBuild() type method. Then sparse_matrix.h will only have to include petsc_matrix_build.h, which won't have to include petsc_matrix.h, and we'll never have a single source file which requires two different packages' headers. |
From: Benjamin S. K. <not...@gi...> - 2013-02-21 21:40:03
|
Gotta love this one, from Ubuntu-LTS's bundled eigen3: The sparse module API is not stable yet. To use it anyway, please define the EIGEN_YES_I_KNOW_SPARSE_MODULE_IS_NOT_STABLE_YET preprocessor token. ```bash CXX src/numerics/libmesh_opt_la-eigen_preconditioner.lo In file included from ./include/libmesh/eigen_core_support.h:45:0, from ./include/libmesh/eigen_preconditioner.h:28, from src/numerics/eigen_preconditioner.C:25: /usr/include/eigen3/Eigen/Sparse:19:2: error: #error The sparse module API is not stable yet. To use it anyway, please define the EIGEN_YES_I_KNOW_SPARSE_MODULE_IS_NOT_STABLE_YET preprocessor token. In file included from src/numerics/eigen_preconditioner.C:26:0: ./include/libmesh/eigen_sparse_matrix.h:89:11: error: 'Triplet' in namespace 'Eigen' does not name a type make[1]: *** [src/numerics/libmesh_opt_la-eigen_preconditioner.lo] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all-recursive] Error 1 program finished with exit code 2 elapsedTime=483.055488 ``` --- Reply to this email directly or view it on GitHub: https://github.com/libMesh/libmesh/issues/44#issuecomment-13914530 |