On Thu, Feb 10, 2011 at 12:31 PM, Roy Stogner <[email protected]> wrote: > > 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. >
Well the trick works for grad u which is in the same function space as p. So there should be a way to make this work. The QoIs in the paper are lift and drag, you write out the stress tensor for the Stokes equation which of course includes both the velocity gradient and the pressure tensors, and end up with an analogous case to the earlier scalar example. I think we just need to pick the right function spaces to isolate the pressure QoI of our interest. >>> 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. > Cant we just reinit those edges ? Even if we have to reassemble from the sides all over again it shouldnt cost us much. I believe all we'll have to do is to add a system.assemble_sides for the forward problem ? >> 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. > I havent really used non DiffSystem based apps for a while now. I'll need to talk to you a little bit before I can contribute meaningfully to generalizing to non-DiffSystem apps. >> 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 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
