On Thu, 15 Oct 2009, John Peterson wrote:

On Thu, Oct 15, 2009 at 2:30 PM, Roy Stogner <[email protected]> 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
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel

Reply via email to