On Thu, Feb 10, 2011 at 11:25 AM, Roy Stogner <[email protected]> wrote: > > 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. >
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. > 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? > Yeah, I thought about this as well. But wouldnt the side_adjoint_constraint and side_adjoint_derivative be able to handle those cases ? >> 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. I would say lets get the DiffSystem API sorted out first. Unless there are lots of people who are wanting to use adjoints (with user specified boundary conditions) and are using non DiffSystem frameworks. > --- > Roy Thanks. -- Vikram Garg PhD Candidate Institute for Computational and Engineering Sciences The University of Texas at Austin http://users.ices.utexas.edu/~vikram/ http://www.runforindia.org/runners/vikramg ------------------------------------------------------------------------------ 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
