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 ------------------------------------------------------------------------------ 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
