Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
Close
From: <pcorreia@ue...>  20080410 12:09:42

Hi, How can I use a direct solver to solve a linear system of equations? Thanks in advance, Paulo 
From: Blome Mark <blome@au...>  20060223 12:49:30

Hi everybody, I would like to use a direct sparse matrix solver package within libmesh = (for example umfpack, pardiso or thelike).=20 Am I right that I have to implement an interface for the solver package = by deriving from the class LinearSolver (linear_solver.h)? Are there any = pitfalls I should be aware of ? How do I include the solver package into = the libmesh Makefile so it will get linked correctly? Did anybody alreay = implement a direct solver interface ?=20 Thanks for any help on this, Mark=20 
From: <pcorreia@ue...>  20080410 12:09:42

Hi, How can I use a direct solver to solve a linear system of equations? Thanks in advance, Paulo 
From: Jed Brown <libmesh@59...>  20080410 12:29:26

On Thu 20080410 14:09, pcorreia@... wrote: > Hi, > How can I use a direct solver to solve a linear system of equations? > Thanks in advance, > Paulo You can do this entirely with PETSc command line arguments. For instance ksp_type preonly pc_type lu will solve the system using LU decomposition. If your matrix is symmetric, you can try pc_type cholesky. You can select different direct solvers by changing the matrix type with mat_type. Run the program with help and you will see the supported types (such as umfpack, superlu, aijspooles, sbaijmumps). Depending on the problem, you may want to try preconditioning with algebraic multigrid. You can build PETSc with libraries like Hypre, ML, and Prometheus, then use pc_type hypre. For 3D problems, I find this starts beating a direct method for quite small sizes. Jed 
From: John Peterson <jwpeterson@gm...>  20080410 14:03:03

Great answer, thanks Jed. J On Thu, Apr 10, 2008 at 7:27 AM, Jed Brown <libmesh@...> wrote: > On Thu 20080410 14:09, pcorreia@... wrote: > > Hi, > > How can I use a direct solver to solve a linear system of equations? > > Thanks in advance, > > Paulo > > You can do this entirely with PETSc command line arguments. For instance > > ksp_type preonly pc_type lu > > will solve the system using LU decomposition. If your matrix is symmetric, you > can try pc_type cholesky. You can select different direct solvers by changing > the matrix type with mat_type. Run the program with help and you will see the > supported types (such as umfpack, superlu, aijspooles, sbaijmumps). Depending > on the problem, you may want to try preconditioning with algebraic multigrid. > You can build PETSc with libraries like Hypre, ML, and Prometheus, then use > pc_type hypre. For 3D problems, I find this starts beating a direct method > for quite small sizes. > > Jed > > > >  > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers > 
From: <pcorreia@ue...>  20080410 16:21:23

I appreciate your answer but in fact I want to define the solver inside the code since I have different solvers for different systems. So I rewrite the question: How to call a direct solver with something like 'linear_solver>set_solver_type'? Thanks Paulo > On Thu 20080410 14:09, pcorreia@... wrote: >> Hi, >> How can I use a direct solver to solve a linear system of equations? >> Thanks in advance, >> Paulo > > You can do this entirely with PETSc command line arguments. For instance > > ksp_type preonly pc_type lu > > will solve the system using LU decomposition. If your matrix is > symmetric, you > can try pc_type cholesky. You can select different direct solvers by > changing > the matrix type with mat_type. Run the program with help and you will > see the > supported types (such as umfpack, superlu, aijspooles, sbaijmumps). > Depending > on the problem, you may want to try preconditioning with algebraic > multigrid. > You can build PETSc with libraries like Hypre, ML, and Prometheus, then > use > pc_type hypre. For 3D problems, I find this starts beating a direct > method > for quite small sizes. > > Jed > >  > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers > 
From: Jed Brown <libmesh@59...>  20080410 18:04:19

On Thu 20080410 18:01, pcorreia@... wrote: > I appreciate your answer but in fact I want to define the solver inside > the code since I have different solvers for different systems. > So I rewrite the question: > How to call a direct solver with something like > 'linear_solver>set_solver_type'? > Thanks > Paulo I've only dabbled with libmesh, but it looks like 'ksp_type preonly' does not have an analogue. It looks like you could set it with KSPSetType(linear_solver>ksp(), KSPPREONLY); Choosing LU as a preconditioner is more natural: linear_solver>set_preconditioner_type(LU_PRECOND); If the preconditioning matrix is the same as the system matrix, this should make any iterative method converge after one step. Using 'ksp_type preonly' just eliminates some overhead. Also note that you can set a prefix for a particular solver and then set options using the options database. For example, KSPSetOptionsPrefix(schur_linear_solver>ksp(), "schur_"); and then you can specify options like: schur_ksp_gmres_restart 60 schur_pc_type asm schur_sub_pc_factor_levels 1 I hope this help. Jed 
From: Jed Brown <libmesh@59...>  20080411 15:47:22

On Fri 20080411 16:47, pcorreia@... wrote: > I ran ex3 using the runtime flags and I got the following error message: You'll have to add something like KSPSetInitialGuessNonzero(ksp, PETSC_FALSE); before the solve if you want to use preonly. I was unaware that libmesh sets this by default. A prettier way to unset this parameter might be a nice thing for libmesh to do. I'd be surprised if you actually take a performance hit when leaving the solver as gmres (default) and just specifying 'pc_type lu'. It will converge after one iteration. Jed > [0]PETSC ERROR:  Error Message >  > [0]PETSC ERROR: ! > [0]PETSC ERROR: Running KSP of preonly doesn't make sense with nonzero > initial guess > you probably want a KSP type of Richardson! > [0]PETSC ERROR: >  > [0]PETSC ERROR: Petsc Release Version 2.3.2, Patch 10, Wed Mar 28 19:13:22 > CDT 2007 HG revision: d7298c71db7f5e767f359ae35d33cab3bed44428 > [0]PETSC ERROR: See docs/changes/index.html for recent updates. > [0]PETSC ERROR: See docs/faq.html for hints about trouble shooting. > [0]PETSC ERROR: See docs/index.html for manual pages. > [0]PETSC ERROR: >  > [0]PETSC ERROR: ./ex3opt on a linux named alinex2PUb8L by paulo Fri Apr > 11 15:39:31 2008 > [0]PETSC ERROR: Libraries linked from > /home/paulo/libmesh/contrib/petsc2.3.2p10/lib/linux > [0]PETSC ERROR: Configure run at Fri Apr 11 11:58:22 2008 > [0]PETSC ERROR: Configure options withcc=gcc withcxx=g++ > withfc=g77 withshared=1 downloadfblaslapack=1 > downloadsuperlu=1 withmpidir=/usr/lib/mpich > [0]PETSC ERROR: >  > [0]PETSC ERROR: KSPSolve_PREONLY() line 26 in > src/ksp/ksp/impls/preonly/preonly.c > [0]PETSC ERROR: KSPSolve() line 372 in src/ksp/ksp/interface/itfunc.c > [0]PETSC ERROR: User provided function() line 396 in > unknowndirectory/src/numerics/petsc_linear_solver.C > [0] MPI Abort by user Aborting program ! > [0] Aborting program! > p0_20759: p4_error: : 83 > > > Paulo > > > > > > On Thu 20080410 14:09, pcorreia@... wrote: > >> Hi, > >> How can I use a direct solver to solve a linear system of equations? > >> Thanks in advance, > >> Paulo > > > > You can do this entirely with PETSc command line arguments. For instance > > > > ksp_type preonly pc_type lu > > > > will solve the system using LU decomposition. If your matrix is > > symmetric, you > > can try pc_type cholesky. You can select different direct solvers by > > changing > > the matrix type with mat_type. Run the program with help and you will > > see the > > supported types (such as umfpack, superlu, aijspooles, sbaijmumps). > > Depending > > on the problem, you may want to try preconditioning with algebraic > > multigrid. > > You can build PETSc with libraries like Hypre, ML, and Prometheus, then > > use > > pc_type hypre. For 3D problems, I find this starts beating a direct > > method > > for quite small sizes. > > > > Jed 
From: Roy Stogner <roy@st...>  20080411 17:08:28

On Fri, 11 Apr 2008, Jed Brown wrote: > On Fri 20080411 16:47, pcorreia@... wrote: >> I ran ex3 using the runtime flags and I got the following error message: > > You'll have to add something like > > KSPSetInitialGuessNonzero(ksp, PETSC_FALSE); > > before the solve if you want to use preonly. I was unaware that > libmesh sets this by default. Yes; we have a lot of application codes which use projected coarse mesh solutions as initial guesses for a refined mesh, previous time steps' solutions as initial guesses for the next time step, etc. > A prettier way to unset this parameter might be a nice thing for > libmesh to do. I think we're going to be taking a harder look at our solver interface abstractions in the next few months. Previously most of the main developers just used PETSc for real work and LASPACK as an easytoinstall serial fallback, and just using PETSc's command line options has been too easy for us to bother abstracting many of them out. But, Ben Kirk and Derek Gaston have just started adding support for Trilinos' solvers, which should mean we'll be more interested in packageindependent configuration soon. > I'd be surprised if you actually take a performance hit when leaving > the solver as gmres (default) and just specifying 'pc_type lu'. It > will converge after one iteration. This is what I typically do as a last resort; you'll generally converge to any reasonable tolerance in one iteration and to 1e14 or so in two. The extra work in the Krylov solver is trivial for a problem where you're already falling back on the most expensive "preconditioner" there is.  Roy 
From: John Peterson <peterson@cf...>  20060223 14:47:22

Blome Mark writes: > > I would like to use a direct sparse matrix solver package within > libmesh (for example umfpack, pardiso or thelike). > Am I right that I have to implement an interface for the solver > package by deriving from the class LinearSolver (linear_solver.h)? > Are there any pitfalls I should be aware of ? How do I include the > solver package into the libmesh Makefile so it will get linked > correctly? Did anybody alreay implement a direct solver interface ? You might get some hints from the Petsc and Laspack implementations of the LinearSolver interface. Some things you will probably need are: 1.) UMF_Matrix derived from SparseMatrix 2.) UMF_Vector derived from NumericVector 3.) UMF_Interface as you mentioned This sounds like an interesting project. If UMF is open source, and small enough, we can distribute it directly in libmesh's contrib directory. Otherwise, you will need 4.) configure tests, etc. I think we can help with 1.)  4.) if you do end up trying to do this. J 