lp:~pefarrell/dolfin-adjoint/alnaes-replay-cb

Branch merges

Propose for merging

No branches dependent on this one.

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

641. By Patrick Farrell on 2013-05-06

Implement a replay_cb in the ReducedFunctional to let users look at convergence of the state.

640. By Patrick Farrell on 2013-04-30

Handle Constant.assign.

There are two options how to handle this. (Well, three, really).

The first option is to just consider Constants like Functions in
FunctionSpace(mesh, "R", 0), and then all the machinery just works: they are
annotated as initial conditions, their updates get assignment equations, etc.
The disadvantage of that is the unacceptable performance penalty: most likely
Constants will be used in many equations, and so their adjoint equation will
have lots and lots of entries, and be a nightmare to assemble (c.f. Marie's
experiences of the integral-constraint Lagrange multiplier in the cardiac
example). It isn't necessary at all to compute it, but it would be computed if
they were treated like Functions.

The second option (adopted) is to consider the value of Constants as a mutable
part of the state to be bundled with the context of the callbacks registered
with libadjoint, just as the values of parameters to Expressions are. This
slightly increases the memory required, but hopefully people aren't declaring
millions of Constants. It has a nasty side-effect which I'll discuss below.

The third option (preferred) is to not assign to Constants. They're either
Constant or they're NotConstant! A Constant that changes value is a
contradiction in my book, but anyway. I don't get to define dolfin semantics.

The nasty side effect: so, when a callback is called, it re-sets the values of
all Constants to the values they had when it was registered -- as described
above, the values of Constants are now part of the state to be re-set. Except
when they're not! And when are they not? When you're perturbing the value of
the damn Constant (such as for a Taylor test, or an optimisation). Then you
don't want to re-set the Constant value! Agh! You only want to re-set the values
of the "other" constants. Hideous, no? Anyway, the best solution I could come up
with was to say that "Constants that are part of a ScalarParameter aren't to be
re-set", which fixes the Taylor test/optimisation problem at the cost of a
nauseating hack. An alternative would be to introduce a NotConstant class, which
behaves like a Constant except it can be assigned to, but I doubt that would
fly.

639. By Patrick Farrell on 2013-04-30

Some fixes for symmetric BC application and dolfin == 1.2.0.

638. By Patrick Farrell on 2013-04-26

Expose some utility functions useful for annotating nonlinear problems with Picard: annotate, and record.

637. By Patrick Farrell on 2013-04-26

Not called symmetric_operator anymore.

636. By Patrick Farrell on 2013-04-24

Set the parameters in the replay too.

635. By Patrick Farrell on 2013-04-24

Get the replay for the PointIntegralSolver working.

634. By Patrick Farrell on 2013-04-24

Annotate PointIntegralSolver.step(). Replay not working yet.

633. By Patrick Farrell on 2013-04-23

Add a small ODE solver test case to get working

632. By Patrick Farrell on 2013-04-22

Fix bug lp:1171322, reported by Marie Rognes.