evaluate_functional yields in some cases wrong functional

[Simon Funke]

During the development of ReducedFunctional I struggled with functionals that integrate over time periods, e.g.
Functional(inner(u_1, u_1)*dx*dt) - while for pointwise timeevaluation the whole optimisation machinery works fine (taylor tests pass, ...) it fails as soon as I use something like "*dt".

A closer look suggests that there is a problem with the time evaluation. To demonstrate this, I wrote a simple problem (code is attached) that first runs two timesteps (dt = 1.0) and integrates the functional manually. It then uses the ReducedFunctional and the functional_evaluation to recompute this functional value.
Here is the output:

+++++++++++++ INITIAL RUN +++++++++
Functional contribution at timestep 0.0 : 0.0
Functional contribution at timestep 1.0 : 2.0
Functional contribution at timestep 2.0 : 8.0
Manually computed functional value: 5.0

+++++++++++++ REPLAY +++++++++
Functional contribution at timestep 0 from reduced functional: 1.0
Functional contribution at timestep 1 from reduced functional: 6.0
Functional value from reduced functional: 7.0

Of course they should yield the same answer...

[Simon Funke (simon-funke)]

I should mention that this code requires the lp:~libadjoint/dolfin-adjoint/improved-optimisation branch to run

[David Ham (david-ham)]

thinking about it, the expected functional value should be 6.0 (and not 5.)

[Simon Funke (simon-funke)]

The development of this bug continues on:

lp:~libadjoint/dolfin-adjoint/bug_1032291

[Simon Funke (simon-funke)]

A fix is commited to lp:~libadjoint/dolfin-adjoint/bug_1032291

The bug was caused by the fact that the first nonlinear solve of a variable does not annotate an initial condition.
As a consequence, the functional evaluation could not access the left hand side value of the first time interval (which is the initial condition).

This fix ensures that even for nonlinear sovles an initial condition is annotated.