[Libmesh-users] Algebraic multigrid

On Thu, 22 Feb 2007, Travis Austin wrote:
> I've tested my patch by doing a 'make run_examples' using
> petsc-2.1.6 and petsc-2.2.0. All of the examples run fine and
> everything seems to be OK. The more recent petsc that I have tested
> against was petsc-2.3.2-p6.
>
> I used default compilation in terms of OPT or DBG. Are there other
> tests to run?
The test coverage we get with "make run_examples" is abysmal, but
it would have caught any obvious errors with those PETSc versions,
and I haven't noticed any subtle errors with petsc-2.3.1. I'll commit
your patch (with a slight assert() reordering John suggested) to CVS
tonight; I don't think it'll break anyone else's code either.
For those who want to experiment with algebraic multigrid, try the
latest CVS. The options "-pc_type hypre -pc_hypre_type boomeramg"
seem to be a good start.
---
Roy

Thread view

Hi,=0A=0ASounds like a great idea and is the direction that we (at the Univ=
ersity of Auckland) want to=0Atake libMesh. But I was figuring on using Al=
gebraic Multigrid (AMG) for all of our multilevel =0Acomputing needs. Boom=
erAMG from LLNL is available within Petsc (may need to be =0Adownloaded sep=
arately) and easy to use. Is there any particular reason that you are *not=
* =0Ausing AMG other than better efficiency? I just wanted to make sure yo=
u were aware of using =0AAMG as an optimal solver.=0A=0ACheers,=0ATravis Au=
stin=0A=0A----- Original Message ----=0AFrom: Roy Stogner <roystgnr@...=
exas.edu>=0ATo: Shun Wang <shunwang@...>=0ACc: libMesh maillist <Libme=
sh-users@...>=0ASent: Thursday, December 14, 2006 6:10:43=
PM=0ASubject: Re: [Libmesh-users] Multilevel and multigrid on libMesh=0A=
=0AOn Wed, 13 Dec 2006, Shun Wang wrote:=0A=0A> I am using libMesh to =
develop a multilevel solver. I understand the=0A> adaptive mesh in libMesh =
is hierarchical and embeded, which is good for=0A> multilevel/multigrid typ=
e of solvers. But I am wondering if there is an easy=0A> way to construct l=
inear systems on meshes at different levels and represent=0A> vectors on th=
ose levels. That is essential for multilevel/multigrid methods.=0A> If the =
current implementation of libMesh is not easy for this, could you=0A> shed =
some light on what extension I can make to keep things easy?=0A=0AFor a mul=
tigrid solver you basically need a smoother operator at every=0Alevel, plus=
restriction and interpolation operators, yes? I assume=0Ayou'll want to l=
et application code fiddle with different smoother=0Apossibilities, so the =
goal with libMesh would be to just provide the=0Awhole linear system at eve=
ry level.=0A=0AGetting the hierarchy of linear systems would be the easiest=
part -=0Asave a copy of the original mesh and vectors, then repeatedly=0Au=
niform_coarsen() while calling assemble() and saving a copy of the=0Alinear=
system at every level, then restore everything. See the=0AUniformRefineme=
ntEstimator for an example of a similar process that=0Agoes in the other di=
rection (although because uniform refinement never=0Adestroys information, =
in that code we save the vectors but not the=0Amesh).=0A=0AGetting the tran=
sfer operators is a bit harder.=0ASystem::project_vector() does the operati=
ons you need, but it's not=0Anearly efficient enough to use in a multigrid =
solver. You can=0Aprobably start from a copy of that code, but instead of =
using the=0Aelement-by-element operations to project each vector, you'd exp=
ress=0Athem as matrices to insert into global sparse interpolation/projecti=
on=0Amatrices.=0A=0AAnd, of course, the last tricky bit is hooking all this=
into PETSc.=0AThey've got a nice multigrid framework for you to use, but y=
ou'll have=0Ato figure out the APIs first.=0A=0AIf you're willing to LGPL t=
he code, let me know (ideally via the=0Alibmesh-devel list) if you need any=
help. This is the sort of project=0Athat I think everyone would like dist=
ributed with the library.=0A---=0ARoy=0A=0A--------------------------------=
-----------------------------------------=0ATake Surveys. Earn Cash. Influe=
nce the Future of IT=0AJoin SourceForge.net's Techsay panel and you'll get =
the chance to share your=0Aopinions on IT & business topics through brief s=
urveys - and earn cash=0Ahttp://www.techsay.com/default.php?page=3Djoin.php=
&p=3Dsourceforge&CID=3DDEVDEV=0A___________________________________________=
____=0ALibmesh-users mailing list=0ALibmesh-users@...=0Ah=
ttps://lists.sourceforge.net/lists/listinfo/libmesh-users=0A=0A=0A=0A=0A=0A=
=0A_______________________________________________________________________=
_____________=0AWant to start your own business?=0ALearn how on Yahoo! Smal=
l Business.=0Ahttp://smallbusiness.yahoo.com/r-index

Roy,=0A=0AThat would figure. It looks like I still need to get hypre insta=
lled with my version of petsc. As this is=0Asomething that I want to do fo=
r my research (get AMG working) I'll probably be working on it in the =0Ane=
xt several weeks. If anyone else gets it going it would be nice to hear if=
there are known hurdles=0Ato get over.=0A=0AAnyway I assumed that BoomerAM=
G came installed with hypre by default. I'll check later.=0A=0ATravis=0A=
=0A=0A=0A----- Original Message ----=0AFrom: Roy Stogner <roystgnr@...=
xas.edu>=0ATo: Travis Austin <austint73@...>=0ACc: libMesh maillist <=
Libmesh-users@...>=0ASent: Friday, December 15, 2006 8:13=
:17 AM=0ASubject: Re: [Libmesh-users] Multilevel and multigrid on libMesh=
=0A=0AOn Thu, 14 Dec 2006, Travis Austin wrote:=0A=0A> Sounds like a great =
idea and is the direction that we (at the=0A> University of Auckland) want =
to take libMesh. But I was figuring on=0A> using Algebraic Multigrid (AMG)=
for all of our multilevel computing=0A> needs. BoomerAMG from LLNL is ava=
ilable within Petsc (may need to=0A> be downloaded separately) and easy to =
use. Is there any particular=0A> reason that you are *not* using AMG other=
than better efficiency? I=0A> just wanted to make sure you were aware of =
using AMG as an optimal=0A> solver.=0A=0AI actually didn't realize that was=
available; unfortunately even now=0Ait doesn't seem to be working on my PE=
TSc installation. =0A"-pc_type hypre -pc_hypre_type euclid" works fine, and=
boomeramg is in=0Athe "-help" list of arguments for "-pc_hypre_type", but =
"-pc_type=0Ahypre -pc_hypre_type boomeramg" gives me a segfault. Perhaps I=
don't=0Ahave the BoomerAMG code installed, and HYPRE or PETSc just isn't b=
eing=0Asmart about giving me an error message to that effect.=0A---=0ARoy=
=0A=0A---------------------------------------------------------------------=
----=0ATake Surveys. Earn Cash. Influence the Future of IT=0AJoin SourceFor=
ge.net's Techsay panel and you'll get the chance to share your=0Aopinions o=
n IT & business topics through brief surveys - and earn cash=0Ahttp://www.t=
echsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV=0A_____=
__________________________________________=0ALibmesh-users mailing list=0AL=
ibmesh-users@...=0Ahttps://lists.sourceforge.net/lists/li=
stinfo/libmesh-users=0A=0A=0A=0A=0A=0A =0A_________________________________=
___________________________________________________=0ADo you Yahoo!?=0AEver=
yone is raving about the all-new Yahoo! Mail beta.=0Ahttp://new.mail.yahoo.=
com

Roy and others,=0A=0AI've successfully been able to use HYPRE/BoomerAMG wit=
h libMesh. Here is what I did. =0A=0AI compiled libMesh with petsc-2.3.2-p=
7 and hypre-1.1.19b. My first attempt at using =0AHYPRE/BoomerAMG ("-pc_ty=
pe hypre -pc_hypre_type boomeramg") ran into the same hurdle =0Aas found by=
Roy. Also, using HYPRE/Euclid ("-pc_hypre_type euclid") worked fine.=0A=
=0AThe problem was that there is a slightly different initialization proces=
s for BoomerAMG within =0AHYPRE and the current set of calls in petsc_linea=
r_solver.C works for HYPRE/Euclid but not for HYPRE/BoomerAMG. In particul=
ar, it was the init(...) and solve(...) calls that needed minor reworking. =
=0AWhat I've done so far is created a new init(...) that takes the matrix =
(a PetscMatrix) as an argument =0Aso that I can call KSPSetOperators in ini=
t(...). =0A=0AIt is presently called in solve(...) which is too late for H=
YPRE/BoomerAMG. HYPRE/BoomerAMG =0Aneeds KSPSetOperators(...) called befor=
e KSPSetFromOptions(...). This is all done within init(...) in petsc_linea=
r_solver.C. I then commented out KSPSetOperators(...) within solve(...) si=
nce it was =0Aalready called.=0A=0AIt is probably best to completely replac=
e the init() call with an init(PetscMatrix <T>* matrix) call. =0AAny thoug=
hts on the cleanest way to fix this up.=0A=0ACheers,=0ATravis=0A=0A----- Or=
iginal Message ----=0AFrom: Travis Austin <austint73@...>=0ATo: Roy S=
togner <roystgnr@...>; Travis Austin <austint73@...>=0ACc=
: libMesh maillist <Libmesh-users@...>=0ASent: Friday, De=
cember 15, 2006 8:49:03 AM=0ASubject: Re: [Libmesh-users] Multilevel and mu=
ltigrid on libMesh=0A=0ARoy,=0A=0AThat would figure. It looks like I still=
need to get hypre installed with my version of petsc. As this is=0Asometh=
ing that I want to do for my research (get AMG working) I'll probably be wo=
rking on it in the =0Anext several weeks. If anyone else gets it going it =
would be nice to hear if there are known hurdles=0Ato get over.=0A=0AAnyway=
I assumed that BoomerAMG came installed with hypre by default. I'll check=
later.=0A=0ATravis=0A=0A=0A=0A----- Original Message ----=0AFrom: Roy Stog=
ner <roystgnr@...>=0ATo: Travis Austin <austint73@...>=0A=
Cc: libMesh maillist <Libmesh-users@...>=0ASent: Friday, =
December 15, 2006 8:13:17 AM=0ASubject: Re: [Libmesh-users] Multilevel and =
multigrid on libMesh=0A=0AOn Thu, 14 Dec 2006, Travis Austin wrote:=0A=0A> =
Sounds like a great idea and is the direction that we (at the=0A> Universit=
y of Auckland) want to take libMesh. But I was figuring on=0A> using Algeb=
raic Multigrid (AMG) for all of our multilevel computing=0A> needs. Boomer=
AMG from LLNL is available within Petsc (may need to=0A> be downloaded sepa=
rately) and easy to use. Is there any particular=0A> reason that you are *=
not* using AMG other than better efficiency? I=0A> just wanted to make sur=
e you were aware of using AMG as an optimal=0A> solver.=0A=0AI actually did=
n't realize that was available; unfortunately even now=0Ait doesn't seem to=
be working on my PETSc installation. =0A"-pc_type hypre -pc_hypre_type euc=
lid" works fine, and boomeramg is in=0Athe "-help" list of arguments for "-=
pc_hypre_type", but "-pc_type=0Ahypre -pc_hypre_type boomeramg" gives me a =
segfault. Perhaps I don't=0Ahave the BoomerAMG code installed, and HYPRE o=
r PETSc just isn't being=0Asmart about giving me an error message to that e=
ffect.=0A---=0ARoy=0A=0A---------------------------------------------------=
----------------------=0ATake Surveys. Earn Cash. Influence the Future of I=
T=0AJoin SourceForge.net's Techsay panel and you'll get the chance to share=
your=0Aopinions on IT & business topics through brief surveys - and earn c=
ash=0Ahttp://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CI=
D=3DDEVDEV=0A_______________________________________________=0ALibmesh-user=
s mailing list=0ALibmesh-users@...=0Ahttps://lists.source=
forge.net/lists/listinfo/libmesh-users=0A=0A=0A=0A=0A=0A =0A_______________=
_____________________________________________________________________=0ADo =
you Yahoo!?=0AEveryone is raving about the all-new Yahoo! Mail beta.=0Ahttp=
://new.mail.yahoo.com=0A=0A------------------------------------------------=
-------------------------=0ATake Surveys. Earn Cash. Influence the Future o=
f IT=0AJoin SourceForge.net's Techsay panel and you'll get the chance to sh=
are your=0Aopinions on IT & business topics through brief surveys - and ear=
n cash=0Ahttp://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge=
&CID=3DDEVDEV=0A_______________________________________________=0ALibmesh-u=
sers mailing list=0ALibmesh-users@...=0Ahttps://lists.sou=
rceforge.net/lists/listinfo/libmesh-users=0A=0A=0A=0A=0A=0A =0A____________=
________________________________________________________________________=0A=
Finding fabulous fares is fun. =0ALet Yahoo! FareChase search your favorit=
e travel sites to find flight and hotel bargains.=0Ahttp://farechase.yahoo.=
com/promo-generic-14795097

On Mon, 15 Jan 2007, Travis Austin wrote:
> It is probably best to completely replace the init() call with an
> init(PetscMatrix <T>* matrix) call. Any thoughts on the cleanest
> way to fix this up.
Well, we'd need that to be init(SparseMatrix<T>* matrix) instead for
consistency with other solver implementations... but then what
happens when we don't have a matrix built when we call init?
In the PETSc methods, pc() and ksp() both call init(); what do we have
them hand in as a matrix?
I'd certainly like algebraic multigrid working, but I don't want to
inadvertently break anything else in the process. I don't know enough
about the PETSc API, but is there really no way to move the offending
functions from init() to solve() to avoid such an odd matrix
dependency?
---
Roy

Roy,=0A=0A1) Yes it should be "init(SparseMatrix<T>* matrix) " instead of "=
init(PetscMatrix<T>* matrix)".=0A=0A2) I overloaded init() so that there is=
one that takes a matrix and the original init() that does=0Anot take a mat=
rix as input. PC() and KSP() still use the original init() with no argumen=
ts. I have =0Aonly used the "init(SparseMatrix<T>* matrix) " in the call t=
o solve(...) where I used a matrix that =0Ahas been dynamically cast from a=
SparseMatrix to a PetscMatrix. Thus there should always there =0Abe a mat=
rix available.=0A=0A3) If we called KSPSetOperators() before calling init()=
in solve then that would remove=0Athis odd dependency. It is still clunky=
code though. I could also try to call KSPSetFromOptions()=0Ain solve and =
get rid of this call in init().=0A=0ATravis=0A=0A----- Original Message ---=
-=0AFrom: Roy Stogner <roystgnr@...>=0ATo: Travis Austin <austi=
nt73@...>=0ACc: libMesh maillist <Libmesh-users@...=
>=0ASent: Tuesday, January 16, 2007 10:27:17 AM=0ASubject: Re: [Libmesh-use=
rs] Multilevel and multigrid on libMesh=0A=0AOn Mon, 15 Jan 2007, Travis Au=
stin wrote:=0A=0A> It is probably best to completely replace the init() cal=
l with an=0A> init(PetscMatrix <T>* matrix) call. Any thoughts on the clea=
nest=0A> way to fix this up.=0A=0AWell, we'd need that to be init(SparseMat=
rix<T>* matrix) instead for=0Aconsistency with other solver implementations=
... but then what=0Ahappens when we don't have a matrix built when we call=
init?=0AIn the PETSc methods, pc() and ksp() both call init(); what do we =
have=0Athem hand in as a matrix?=0A=0AI'd certainly like algebraic multigri=
d working, but I don't want to=0Ainadvertently break anything else in the p=
rocess. I don't know enough=0Aabout the PETSc API, but is there really no =
way to move the offending=0Afunctions from init() to solve() to avoid such =
an odd matrix=0Adependency?=0A---=0ARoy=0A=0A------------------------------=
-------------------------------------------=0ATake Surveys. Earn Cash. Infl=
uence the Future of IT=0AJoin SourceForge.net's Techsay panel and you'll ge=
t the chance to share your=0Aopinions on IT & business topics through brief=
surveys - and earn cash=0Ahttp://www.techsay.com/default.php?page=3Djoin.p=
hp&p=3Dsourceforge&CID=3DDEVDEV=0A_________________________________________=
______=0ALibmesh-users mailing list=0ALibmesh-users@...=
=0Ahttps://lists.sourceforge.net/lists/listinfo/libmesh-users=0A=0A=0A=0A=
=0A=0A=0A=0A =0A___________________________________________________________=
_________________________=0ABe a PS3 game guru.=0AGet your game face on wit=
h the latest PS3 news and previews at Yahoo! Games.=0Ahttp://videogames.yah=
oo.com/platform?platform=3D120121

On Tue, 16 Jan 2007, Travis Austin wrote:
> 2) I overloaded init() so that there is one that takes a matrix and
> the original init() that does not take a matrix as input. PC() and
> KSP() still use the original init() with no arguments. I have only
> used the "init(SparseMatrix<T>* matrix) " in the call to solve(...)
> where I used a matrix that has been dynamically cast from a
> SparseMatrix to a PetscMatrix. Thus there should always there be a
> matrix available.
That sounds good to me. Can you put together a patch for us to test
out?
> 3) If we called KSPSetOperators() before calling init() in solve
> then that would remove this odd dependency. It is still clunky code
> though. I could also try to call KSPSetFromOptions() in solve and
> get rid of this call in init().
Hmm... The options line parsing sounds like it belongs in init(), and
setting up the operators early is kind of odd. Perhaps a version of
init() which takes a matrix (or a single version of init() whose
matrix pointer argument defaults to NULL) would be best.
I'll forward an extra copy of this to Ben to make sure he's following
the thread. Part of the reason I started using libMesh was that I
was discovering how hard it was to add PETSc support to another code,
and I'm still not too comfortable working with their API.
---
Roy

On Thu, 22 Feb 2007, Travis Austin wrote:
> I've tested my patch by doing a 'make run_examples' using
> petsc-2.1.6 and petsc-2.2.0. All of the examples run fine and
> everything seems to be OK. The more recent petsc that I have tested
> against was petsc-2.3.2-p6.
>
> I used default compilation in terms of OPT or DBG. Are there other
> tests to run?
The test coverage we get with "make run_examples" is abysmal, but
it would have caught any obvious errors with those PETSc versions,
and I haven't noticed any subtle errors with petsc-2.3.1. I'll commit
your patch (with a slight assert() reordering John suggested) to CVS
tonight; I don't think it'll break anyone else's code either.
For those who want to experiment with algebraic multigrid, try the
latest CVS. The options "-pc_type hypre -pc_hypre_type boomeramg"
seem to be a good start.
---
Roy

Please note that you must have a recent version of petsc (2.3.x) that is
compiled with HYPRE support. Earlier versions of petsc do not make room
for HYPRE use.
On 2/22/07, Roy Stogner <roystgnr@...> wrote:
>
> On Thu, 22 Feb 2007, Travis Austin wrote:
>
> > I've tested my patch by doing a 'make run_examples' using
> > petsc-2.1.6 and petsc-2.2.0. All of the examples run fine and
> > everything seems to be OK. The more recent petsc that I have tested
> > against was petsc-2.3.2-p6.
> >
> > I used default compilation in terms of OPT or DBG. Are there other
> > tests to run?
>
> The test coverage we get with "make run_examples" is abysmal, but
> it would have caught any obvious errors with those PETSc versions,
> and I haven't noticed any subtle errors with petsc-2.3.1. I'll commit
> your patch (with a slight assert() reordering John suggested) to CVS
> tonight; I don't think it'll break anyone else's code either.
>
> For those who want to experiment with algebraic multigrid, try the
> latest CVS. The options "-pc_type hypre -pc_hypre_type boomeramg"
> seem to be a good start.
> ---
> Roy
>

On Thu, 22 Feb 2007, Travis Austin wrote:
> Please note that you must have a recent version of petsc (2.3.x) that is
> compiled with HYPRE support. Earlier versions of petsc do not make room
> for HYPRE use.
I note that one probably should also have a more intimate knowledge of
HYPRE than I do - on the first complicated example problem I tried (3D
lid-driven cavity incompressible flow), the linear symmetric Stokes
flow case was unbelievably faster using multigrid, but as soon as I
turn on the nonlinear/nonsymmetric Navier-Stokes convection term,
something goes wrong. The KSP residuals say I'm converged, but Newton
doesn't think that the result is even necessarily a descent direction.
---
Roy

On Thu, 14 Dec 2006, Travis Austin wrote:
> Sounds like a great idea and is the direction that we (at the
> University of Auckland) want to take libMesh. But I was figuring on
> using Algebraic Multigrid (AMG) for all of our multilevel computing
> needs. BoomerAMG from LLNL is available within Petsc (may need to
> be downloaded separately) and easy to use. Is there any particular
> reason that you are *not* using AMG other than better efficiency? I
> just wanted to make sure you were aware of using AMG as an optimal
> solver.
I actually didn't realize that was available; unfortunately even now
it doesn't seem to be working on my PETSc installation.
"-pc_type hypre -pc_hypre_type euclid" works fine, and boomeramg is in
the "-help" list of arguments for "-pc_hypre_type", but "-pc_type
hypre -pc_hypre_type boomeramg" gives me a segfault. Perhaps I don't
have the BoomerAMG code installed, and HYPRE or PETSc just isn't being
smart about giving me an error message to that effect.
---
Roy

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

CountryState

JavaScript is required for this form.

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details