We have the following support for adjoints. Roy/Paul please correct/add/expand as you see fit.

Fully coupled or single-physics problems:
1) Adjoint refinement based error estimators (Global bounds for | Q(u) - Q(u_h) |, Adjoint Example 4 )
2) Adjoint refinement based error indicators (Adjoint Example 4)
3) Adjoint Residual based error indicators (Has been there for a while)
4) Adjoint parameter sensitivity analysis and Hessians (Been there for a while as well)

Future work:
1) Proper scaling for local error indicators for the Adjoint Refinement indicator (this is almost done, needs some refactoring in the library to be finally implemented)
2) Support for user specified adjoint boundary conditions + DirichletBoundary (for boundary flux type QoIs)
3) We probably want something better than 'store primal solution' at every timestep for time dependent adjoint problems (This might become a high priority for me soon, so I might try implementing some kind of checkpointing algorithm in the coming weeks.)
4) For one-way coupled problems, right now we force the user to write the system as one block. We might want to allow the user more flexibility here.   

Thanks.

On Thu, Oct 25, 2012 at 7:28 PM, Cody Permann <codypermann@gmail.com> wrote:
Ah, yes my mistake. I didn't mean Makefile, but I think you all
figured out what I meant.  Just wanted to maintain old behavior as
much as possible from the user perspective.  I don't particularly have
any strong opinions on exactly how we generate those files (something
akin to our current bootstrap process is fine with me as others have
pointed out).  I think we are all on the same page.

Cody

Sent from my iPhone

On Oct 25, 2012, at 4:58 PM, Roy Stogner <roystgnr@ices.utexas.edu> wrote:

>
> On Thu, 25 Oct 2012, Paul T. Bauman wrote:
>
>> 1. FEMContext work - Finish off hiding public members and putting in
>> accessors. I can get this done pretty quickly so I don't think it
>> would hold up a release, but nothing is broken at the moment. We are
>> storing redundant FE info (not much) until we decide to break
>> backward compatibility.
>
> Oh, I forgot about this.  I'd definitely like such simple API
> improvements to make it into the next release.
>
> I'd also like the DiffPhysics refactoring to be finished the way the
> DiffQoI refactoring was, but hopefully this time without me slacking
> off so long that Paul has to do it.  I wouldn't be able to get to this
> until next week, though.
> ---
> Roy
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Libmesh-devel mailing list
> Libmesh-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel

--
Vikram Garg
PhD Candidate
Institute for Computational and Engineering Sciences
The University of Texas at Austin