On Fri, 22 Apr 2011, Vikram Garg wrote:

> Alright, will this work ?
>
> 1) Declare two new virtual functions in linear_solver.h: virtual bool
> reuse_preconditioner() and LinearSolver::adjoint_solve().

Yes.

> If the user
> wants to reuse preconditioners either for a different rhs or solving a
> transpose matrix he/she calls reuse_preconditioner to set
> same_preconditioner to true.

Yes.

> If same_preconditioner is true and the user calls adjoint_solve,
> PETSc uses KSPSolveTranspose,

PetscLinearSolver would always use KSPSolveTranspose for
adjoint_solve; reuse_preconditioner would just affect the flags we
pass to it.

> otherwise the regular ImplicitSystem::adjoint_solve is called.

Literally, no - the LinearSolver doesn't have a system object to play
with.

Metaphorically, yes - I'd just remove the relevant code from
ImplicitSystem::adjoint_solve, and put it in
LinearSolver::adjoint_solve, then make the former call the latter.
That ought to handle Trilinos and Laspack, once anyone stops
slacking off and implements get_transpose() for those.

The PetscLinearSolver::adjoint_solve() code would look more like the
PetscLinearSolver:solve() code, but using KSPSolveTranspose instead of
KSPSolve.

> 2) Define the new functions in linear_solver.h/.C
>
> 3) 3) Rework petsc_linear_solver.C to accomodate the use of KSPSolveTranspose
>
> 4) Add to examples, and verify performance improvement in adjoint_solve call

Yes/yes/yes.

Along with verifying the performance improvement, you'll want to just
comment out the PetscLinearSolver implementations so that it falls
back on the LinearSolver implementation, and try that to regression
test the speed/accuracy of the refactored old code.
---
Roy

------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been 
demonstrated beyond question. Learn why your peers are replacing JEE 
containers with lightweight application servers - and what you can gain 
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel

Reply via email to