On Thu, 10 Feb 2011, Vikram Garg wrote:
Not always. Think about Navier Stokes in a channel. There is no
Dirichlet bc on the pressure on the channel walls. But if our QoI
involved the pressure on that boundary, then the approach of Giles et
al would require for us to apply a Dirichlet condition on the adjoint
pressure. But with the current setup we wouldnt have the penalty
matrix for the pressure on that boundary.
Yeah, that would fall into one of my "what I'm worried about NOW"
categories... except that one's especially conceptually tricky, isn't
it, due to the different function spaces involved? Do the Giles et al
tricks work the same way? Going from H^1 to an affine transform of
H^1_0 is a smaller jump than going there from L_2.
But what I'm worried about NOW: are there any cases where we'd want
more complicated boundary condition changes? Any Neumann/mixed primal
-> Dirichlet adjoint, or Dirichlet primal -> Neumann/mixed adjoint is
pretty much impossible right now, for example; any chance we'd be
painting ourselves into a corner if a feature designed now wasn't
flexible enough to handle those in the future?
Yeah, I thought about this as well. But wouldnt the
side_adjoint_constraint and side_adjoint_derivative be able to handle
those cases ?
non-Dirichlet->Dirichlet we might be able to handle with penalty terms
using adjoint_constraint equations that, unlike the qoi_derivative
stuff, add to both the system rhs and matrix.... but then this trashes
the matrix, for the more complicated adjoint-based Hessian and
Hessian-vector tricks that rely on multiple adjoint + forward
sensitivity solves.
Dirichlet(penalty)->non-Dirichlet is even worse. Even if you edit the
matrix again, floating point error makes it impossible to just
subtract off the penalty terms; x + O(1/epsilon) - O(1/epsilon) isn't
x, it's garbage.
I would say lets get the DiffSystem API sorted out first.
"First" is probably appropriate; that's basically the way we did it
with all the other adjoint APIs. But we don't want to stop thinking
ahead to how they can be generalized.
Unless there are lots of people who are wanting to use adjoints
(with user specified boundary conditions) and are using non
DiffSystem frameworks.
Not sure about the user-specified boundary conditions, but "wanting to
use adjoints while using non-DiffSystem frameworks" is true for all
the INL-based folks; loosen that very slightly to "wanting to use
adjoints even when stuck with non-DiffSystem frameworks" and it's
emphatically true for me too. ;-)
---
Roy
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
