From: Jan B. <bie...@tu...> - 2010-12-17 09:49:20
Attachments:
biermann.vcf
|
Dear developers, I just implemented two new solvers in Petsc that make use of Krylov subspace recycling, which means that if you have to solve a sequence of linear systems, the overall cost can be reduced significantly (by 10 to 100). I also coded the respective interface in libmesh and now I am wondering if you are interested in submitting this and in case, how to submit it. I could also come up with an example of how to use it. Jan |
From: John P. <pet...@cf...> - 2010-12-17 15:58:06
|
On Fri, Dec 17, 2010 at 3:49 AM, Jan Biermann <bie...@tu...> wrote: > Dear developers, > > I just implemented two new solvers in Petsc that make use of Krylov subspace > recycling, which means that if you have to solve a sequence of linear > systems, the overall cost can be reduced significantly (by 10 to 100). I > also coded the respective interface in libmesh and now I am wondering if you > are interested in submitting this and in case, how to submit it. I could > also come up with an example of how to use it. Hi Jan, That sounds very interesting. Would you be able to submit a patch (you can email an attachment the -devel list and/or me and Roy directly) against the most recent SVN head (just use svn diff to generate)? If you could also send a small working example that demonstrates the capability, that would be very useful for testing the patch, etc. We would most likely wait to check-in until Roy has returned from holiday vacation and has had a chance to look over/comment on the patch, so there is no hurry. -- John |
From: Roy S. <roy...@ic...> - 2010-12-18 05:16:47
|
On Fri, 17 Dec 2010, John Peterson wrote: > We would most likely wait to check-in until Roy has returned from > holiday vacation and has had a chance to look over/comment on the > patch, so there is no hurry. Thanks. :-) I'm barely keeping up on my email at the moment; won't have time to check out patches until New Years. And I'd definitely like to look at the API for this one; it would be nice if it was forward-compatible to any Trilinos addition of this capability in the future... and I also wonder if it ought to also be available in some generic "reuse_everything" option? I suspect that many people who are successfully reusing preconditioners from system to system would benefit from reusing Krylov vectors as well. --- Roy |
From: Jed B. <je...@59...> - 2010-12-18 01:00:48
|
On Fri, Dec 17, 2010 at 10:49, Jan Biermann <bie...@tu...> wrote: > I just implemented two new solvers in Petsc that make use of Krylov > subspace recycling, which means that if you have to solve a sequence of > linear systems, the overall cost can be reduced significantly (by 10 to > 100). Have you sent these to pet...@mc...? We would be happy to add them. Why is a special interface needed from libmesh? |
From: Roy S. <roy...@ic...> - 2010-12-18 05:23:55
|
On Sat, 18 Dec 2010, Jed Brown wrote: > On Fri, Dec 17, 2010 at 10:49, Jan Biermann <bie...@tu...> wrote: > I just implemented two new solvers in Petsc that make use of > Krylov subspace recycling, which means that if you have to solve > a sequence of linear systems, the overall cost can be reduced > significantly (by 10 to 100). > > > Have you sent these to pet...@mc...? We would be happy to add > them. > > Why is a special interface needed from libmesh? Just to enable/disable the recycling, I'd assume? Our LinearSolver doesn't know a priori how related each solve is to the previous. --- Roy |
From: Jan B. <bie...@tu...> - 2010-12-21 13:42:17
Attachments:
biermann.vcf
|
Hi all, first, I sent the stuff to Petsc and they want to include it (otherwise it would not make any sense to make the changes in libmesh I guess). second, I didn't include the "switch" for enableing or disableing for the configure, I just included the necessary things in linear solver / petsc_linear_solver and in linear_implicit_system. I assume it is not the most elegant way I did it ( I leave that to the pros) but it works just fine and it does not affect older code. I will make the diff now and setup a little example program to show the functionality. to answer Jed's question (Why is a special interface needed from libmesh?) There are certain petsc functions that need to be included additionally but most important, I chose to handle the recycle space (that will be reused from one solve to the other) at the linear implicit system, so outside from petsc. This way it is easier to switch between solvers etc. without reallocating memory and the recycle space is easier to manipulate (there is a lot of freedom and potential for optimization) Thanks, Jan Am 18.12.2010 06:23, schrieb Roy Stogner: > > > On Sat, 18 Dec 2010, Jed Brown wrote: > >> On Fri, Dec 17, 2010 at 10:49, Jan Biermann <bie...@tu...> >> wrote: >> I just implemented two new solvers in Petsc that make use of >> Krylov subspace recycling, which means that if you have to solve >> a sequence of linear systems, the overall cost can be reduced >> significantly (by 10 to 100). >> >> >> Have you sent these to pet...@mc...? We would be happy to >> add >> them. >> >> Why is a special interface needed from libmesh? > > Just to enable/disable the recycling, I'd assume? Our LinearSolver > doesn't know a priori how related each solve is to the previous. > --- > Roy |
From: Jed B. <je...@59...> - 2010-12-21 20:21:55
|
On Tue, Dec 21, 2010 at 14:42, Jan Biermann <bie...@tu...> wrote: > first, I sent the stuff to Petsc and they want to include it (otherwise it > would not make any sense to make the changes in libmesh I guess). > Okay, I asked because I hadn't seen it go by and it's not in the petsc-dev repository yet. to answer Jed's question (Why is a special interface needed from libmesh?) > There are certain petsc functions that need to be included additionally but > most important, I chose to handle the recycle space (that will be reused > from one solve to the other) at the linear implicit system, so outside from > petsc. > This way it is easier to switch between solvers etc. without reallocating > memory and the recycle space is easier to manipulate (there is a lot of > freedom and potential for optimization) > Without looking at the code, the downside is that this makes the interface more complicated. It's very likely that Barry wants the basic interface to be that users just call KSPSolve repeatedly and take advantage of a recycled subspace. Having an interface to manipulate it, or even pull it out as a separate entity may remain, but if I know Barry, he'll likely tweak things so that the basic interface does not involve the user doing anything special with a subspace. With that in mind, you might want to wait until it goes into petsc-dev before committing the libmesh interface. |
From: Barry S. <bs...@mc...> - 2010-12-21 20:27:13
|
On Dec 21, 2010, at 2:21 PM, Jed Brown wrote: > On Tue, Dec 21, 2010 at 14:42, Jan Biermann <bie...@tu...> wrote: > first, I sent the stuff to Petsc and they want to include it (otherwise it would not make any sense to make the changes in libmesh I guess). > > Okay, I asked because I hadn't seen it go by and it's not in the petsc-dev repository yet. > > to answer Jed's question (Why is a special interface needed from libmesh?) There are certain petsc functions that need to be included additionally but most important, I chose to handle the recycle space (that will be reused from one solve to the other) at the linear implicit system, so outside from petsc. > This way it is easier to switch between solvers etc. without reallocating memory and the recycle space is easier to manipulate (there is a lot of freedom and potential for optimization) > > Without looking at the code, the downside is that this makes the interface more complicated. It's very likely that Barry wants the basic interface to be that users just call KSPSolve repeatedly and take advantage of a recycled subspace. In fact that type of thing already exists using the Fischer method. You just turn it on initially with an option and it goes. Since I have not seen the proposed new interface I cannot comment on it. But Jed is totally on the mark, and is ready to take my place as PETSc referee and stylist :-) Barry > Having an interface to manipulate it, or even pull it out as a separate entity may remain, but if I know Barry, he'll likely tweak things so that the basic interface does not involve the user doing anything special with a subspace. With that in mind, you might want to wait until it goes into petsc-dev before committing the libmesh interface. > ------------------------------------------------------------------------------ > Forrester recently released a report on the Return on Investment (ROI) of > Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even > within 7 months. Over 3 million businesses have gone Google with Google Apps: > an online email calendar, and document program that's accessible from your > browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew_______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |