From: Roy S. <roy...@ic...> - 2009-10-15 19:30:15
|
I'm going to need to change out the adjoints API a bit, mostly to accomodate the possibility of multiple QoIs. My current plans: Make System::qoi into a vector<Number>. The user will be responsible for resizing this before calling qoi assembly, parameter sensitivity calculations, etc. Add a DiffContext::qoi proxy; that way when we add threaded assembly to FEMSystem it won't give anyone race conditions. Give assemble_qoi and assemble_qoi_derivative optional arguments of type vector<int> telling them which QoIs to assemble "this time" - typically the argument would just be the default empty vector, which would be shorthand for "assemble them all". The qoi_parameter_sensitivity call (which would now fork off to forward and adjoint versions depending on which is more efficient, by comparing qoi->size() and parameters->size()) would now fill a vector<vector<Number> > of sensitivities. Remaining questions: Should we provide a vector of RHS NumericVectors for adjoint work, as well as a vector of adjoint_solution NumericVectors? Then adjoint_solve(vector<int>) could do all (or some subset) of the adjoint solves at once. Or, should we assume that only one solve is being done at a time (leaving the library in charge of trying to reuse preconditioners efficiently), and keep using a single adjoint_solution and reusing rhs? I'm leaning toward the former solution; it uses more RAM but it would allow the QoI derivative assembly to build every rhs at once, saving some CPU. I'm also leaning toward keeping the adjoint_solution vectors around after an adjoint_solve creates them, so their projections will be useful as good initial iterates when they need to be recalculated after a refinement step. Any thoughts? --- Roy |
From: John P. <pet...@cf...> - 2009-10-15 19:36:58
|
On Thu, Oct 15, 2009 at 2:30 PM, Roy Stogner <roy...@ic...> wrote: > > Remaining questions: > > Should we provide a vector of RHS NumericVectors for adjoint work, as > well as a vector of adjoint_solution NumericVectors? Then > adjoint_solve(vector<int>) could do all (or some subset) of the > adjoint solves at once. > > Or, should we assume that only one solve is being done at a time > (leaving the library in charge of trying to reuse preconditioners > efficiently), and keep using a single adjoint_solution and reusing > rhs? > > I'm leaning toward the former solution; it uses more RAM but it would > allow the QoI derivative assembly to build every rhs at once, saving > some CPU. I'm also leaning toward keeping the adjoint_solution > vectors around after an adjoint_solve creates them, so their > projections will be useful as good initial iterates when they need to > be recalculated after a refinement step. > > Any thoughts? Multiple solutions + multiple rhs sounds like the right idea. With ghosted vectors it doesn't waste that much RAM after all...if the user prefers to assemble/solve one at a time, this design does not preclude that approach. -- John |
From: Roy S. <roy...@ic...> - 2009-10-15 19:43:23
|
On Thu, 15 Oct 2009, John Peterson wrote: > On Thu, Oct 15, 2009 at 2:30 PM, Roy Stogner <roy...@ic...> wrote: >> >> Remaining questions: >> >> Should we provide a vector of RHS NumericVectors for adjoint work, as >> well as a vector of adjoint_solution NumericVectors? Then >> adjoint_solve(vector<int>) could do all (or some subset) of the >> adjoint solves at once. >> >> Or, should we assume that only one solve is being done at a time >> (leaving the library in charge of trying to reuse preconditioners >> efficiently), and keep using a single adjoint_solution and reusing >> rhs? >> >> I'm leaning toward the former solution; it uses more RAM but it would >> allow the QoI derivative assembly to build every rhs at once, saving >> some CPU. I'm also leaning toward keeping the adjoint_solution >> vectors around after an adjoint_solve creates them, so their >> projections will be useful as good initial iterates when they need to >> be recalculated after a refinement step. >> >> Any thoughts? > > Multiple solutions + multiple rhs sounds like the right idea. With > ghosted vectors it doesn't waste that much RAM after all...if the user > prefers to assemble/solve one at a time, this design does not preclude > that approach. Good point - the user would have to manually get rid of the old vectors in between solves (I'll add a System::remove_vector() method to make that easier), but anyone who's so hard up for RAM is probably willing to do that sort of low level work... or perhaps I've been spoiled, since the last user who was that hard up for RAM gave us ghosted vectors! ;-) --- Roy |
From: Roy S. <roy...@ic...> - 2009-10-16 22:52:01
|
On Thu, 15 Oct 2009, John Peterson wrote: > On Thu, Oct 15, 2009 at 2:30 PM, Roy Stogner <roy...@ic...> wrote: >> >> Remaining questions: >> >> Should we provide a vector of RHS NumericVectors for adjoint work, as >> well as a vector of adjoint_solution NumericVectors? Then >> adjoint_solve(vector<int>) could do all (or some subset) of the >> adjoint solves at once. >> >> Or, should we assume that only one solve is being done at a time >> (leaving the library in charge of trying to reuse preconditioners >> efficiently), and keep using a single adjoint_solution and reusing >> rhs? >> >> I'm leaning toward the former solution; it uses more RAM but it would >> allow the QoI derivative assembly to build every rhs at once, saving >> some CPU. I'm also leaning toward keeping the adjoint_solution >> vectors around after an adjoint_solve creates them, so their >> projections will be useful as good initial iterates when they need to >> be recalculated after a refinement step. >> >> Any thoughts? > > Multiple solutions + multiple rhs sounds like the right idea. With > ghosted vectors it doesn't waste that much RAM after all...if the user > prefers to assemble/solve one at a time, this design does not preclude > that approach. Multiple solutions + multiple rhs is what I went with. It's a more intrusive change than I'd hoped it would be, though, so those of us who are foolhardy enough to be trying to use adjoint results already might want to have a regression test case ready. I won't do an svn commit until Vikram and I have done a bit of testing, but even when things are right within the library there will still be necessary changes to user code. Vikram, try the patch ~roystgnr/libmesh/svn/libmesh_qois.diff You can also find my corresponding changes to the benchmark app code in ~roystgnr/libmesh/svn/src/apps/adjoints_test_poisson/application_code --- Roy |
From: Roy S. <roy...@ic...> - 2009-10-19 23:12:10
|
On Thu, 15 Oct 2009, Roy Stogner wrote: > I'm going to need to change out the adjoints API a bit, mostly to > accomodate the possibility of multiple QoIs. > Give assemble_qoi and assemble_qoi_derivative optional arguments of > type vector<int> telling them which QoIs to assemble "this time" - > typically the argument would just be the default empty vector, which > would be shorthand for "assemble them all". > > The qoi_parameter_sensitivity call (which would now fork off to > forward and adjoint versions depending on which is more efficient, by > comparing qoi->size() and parameters->size()) would now fill a > vector<vector<Number> > of sensitivities. A couple other changes: I'm also going to give that optional indices argument to qoi_parameter_sensitivity and its forward/adjoint versions. Users can already solve with a subset of their systems' parameters by leaving those out of the parameters argument, but the most natural way to solve for a subset of QoIs seems to be with that indices arg. The indices argument is also going in element_qoi, etc. for FEMSystem users. --- Roy |
From: Derek G. <fri...@gm...> - 2009-10-21 15:51:36
|
Just to be clear since I haven't chimed in here... all these changes sound good to me. I think you're really the only one using the new interface anyway.... so I'm good with whatever you think is best! ;-) Derek On Mon, Oct 19, 2009 at 5:11 PM, Roy Stogner <roy...@ic...>wrote: > > On Thu, 15 Oct 2009, Roy Stogner wrote: > > > I'm going to need to change out the adjoints API a bit, mostly to > > accomodate the possibility of multiple QoIs. > > > > Give assemble_qoi and assemble_qoi_derivative optional arguments of > > type vector<int> telling them which QoIs to assemble "this time" - > > typically the argument would just be the default empty vector, which > > would be shorthand for "assemble them all". > > > > The qoi_parameter_sensitivity call (which would now fork off to > > forward and adjoint versions depending on which is more efficient, by > > comparing qoi->size() and parameters->size()) would now fill a > > vector<vector<Number> > of sensitivities. > > A couple other changes: > > I'm also going to give that optional indices argument to > qoi_parameter_sensitivity and its forward/adjoint versions. Users can > already solve with a subset of their systems' parameters by leaving > those out of the parameters argument, but the most natural way to > solve for a subset of QoIs seems to be with that indices arg. > > The indices argument is also going in element_qoi, etc. for FEMSystem > users. > --- > Roy > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > |
From: Roy S. <roy...@ic...> - 2009-10-21 16:10:34
|
On Wed, 21 Oct 2009, Derek Gaston wrote: > Just to be clear since I haven't chimed in here... all these changes > sound good to me. I think you're really the only one using the new > interface anyway... Yeah, so far, but you're paying for half of it. ;-) I've barely even started with the code that *only* PECOS is likely to use. Adjoint-based parameter sensitivity and error indicators are both surely in INL's best interests, yes? Where we really go down the rabbit hole is for the inverse UQ acceleration; forward sensitivity solves are just step one towards an option for full sensitivity Hessians and/or Hessian-vector product. That latter stuff shouldn't require many further API changes, though. One method for full Hessians would require the user to provide contractions with a qoi_second_derivative operator, but everything else (including a slightly-less-efficient full Hessian method) should be doable via the existing interface. > so I'm good with whatever you think is best! Good to know. --- Roy |
From: Derek G. <fri...@gm...> - 2009-10-21 16:15:09
|
On Oct 21, 2009, at 10:10 AM, Roy Stogner wrote: > I've barely even started with the code that *only* PECOS is likely to > use. Adjoint-based parameter sensitivity and error indicators are > both surely in INL's best interests, yes? Where we really go down the > rabbit hole is for the inverse UQ acceleration; forward sensitivity > solves are just step one towards an option for full sensitivity > Hessians and/or Hessian-vector product. Yes! This is all good for us here! And we are planning on using it "real soon now"... I just wanted to point out that we're not YET so it's not a big deal if the API changes now (in fact... change it as much as you want for now while there isn't a lot of dependence on it). Good to hear about some of your future plans in this direction.. Derek |