On Wed, 9 Feb 2011, Vikram Garg wrote: > Currently our adjoints framework assembles the discrete adjoint > problem by transposing the matrix representing the discrete forward > problem. This is simple and works as long as we have (or only desire) > the discrete adjoint for an adjoint consistent formulation. Of course, > this might not be the case for all problems. > > In particular, while computing boundary QoIs that are ill-posed due to > regularity issues, one might want to follow the approach described in > a paper by Giles, Larson et al. Here one imposes a Dirichlet bc for > the adjoint problem on the boundary in question, modifying the trial > space. This ensures that we are solving a well posed adjoint problem.
The problem class I'm most familiar with is the one we looked at when first starting with the automatic adjoints code, where the discrete adjoint solution looked ill-posed but surprisingly worked, the more traditional problem would have replaced the automatic homogeneous Dirichlet boundary condition with a heterogeneous Dirichlet B.C. Worst case I know of in these problems, the automatic adjoint does fail but the homogeneous->heterogeneous Dirichlet tricks like in that Giles/Larson paper look similar. That's (in situations where we need it) doable within the current framework, for anyone using penalty Dirichlet BCs, no? You've already got the correct penalty matrix, and you just need to add the proper penalty forcing term to your qoi_derivative. We'll have to worry again when we extend the library: when we add an official in-library method for strict Dirichlet BCs we'll need to remember to allow optional separate Dirichlet BCs to be used on adjoint problems, and when we do transient adjoints then the penalty really will need to be in a constraint-type rather than a time-derivative-type term. 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? > One way of extending the current framework to include such adjoint > formulations would be to have the user specify a side_qoi_constraint > along the lines of side_qoi_derivative and side_constraint. The user > would specify the stiffness matrix entries (penalty terms) for the > Dirichlet bc in side_qoi_residual and the corresponding residual term > in side_qoi_derivative. We can then include side_qoi_constraint in the > assembly before solving the adjoint. > > Does this sound reasonable ? Of course any other ideas are welcome. The only additional issue with side_qoi_constraint (I'd name it side_adjoint_constraint, since it wouldn't end up being called in qoi evaluations) only makes sense for the DiffSystem-based adjoint. The rest of the adjoint features work for LinearImplicitSystem and NonlinearImplicitSystem based codes as well, and I'd rather any new feature work as widely, if possible. On the other hand, side_qoi_constraint might be the proper way to do this for transient adjoint problems, which are going to be difficult-to-impossible to do in TransientSystem<SomeImplicitSystem> anyway, so maybe the thing to do is to get the DiffSystem API sorted out now and leave the other systems stuck with qoi_derivative hacks. --- 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
