libadjoint team mailing list archive

[Patrick Farrell <patrick.farrell06@xxxxxxxxxxxxxx>]

On 10/06/12 18:22, David Ham wrote:

> 1. How to express time in current DOLFIN models with no time abstraction.
>
> 2. Whatever happens in the future with a DOLFIN time abstraction.
>
> 1. is what we should do now.  We should handle when 2. someone does
> the DOLFIN time abstraction.

I agree we shouldn't wait for DOLFIN's time abstraction, so that makes
perfect sense. I guess that whatever DOLFIN does later on, it shouldn't
be so dramatically different that we can't match up the abstractions.

> We proceeded from the ansatz that functionals will be forms integrated
> over time, forms evaluated at a particular time (which might be the
> start or end), and sums of the preceding two cases.

I think this is a good approach to take. We should be aware that some
strange functionals can't be expressed in this way (e.g. inner(u(t=0),
u(t=T))*dx), but it will capture 99% of the functionals in practical
use. And the functional system is sufficiently general that people can
code up by hand the necessary Functional subclass if they really want
such odd choices.

> In order to allow for Functional evaluation on the first execution of
> a model (this is needed for optimisation), it should be possible to
> register a Functional before we start.

Yep, libadjoint supports that, so it shouldn't be too hard.

> This requires a little more
> timestep-related annotation than we have at the moment
> (unfortunately). It would also be a really good idea not to assume
> that time progresses in constant timesteps from zero. I think this
> means we need the following:
>
> adj_time_start(time) : start set the start time.
> adj_inc_timestep(time): adj_inc_timestep now records the time at which
> the timestep ends.
> adj_time_finish(): indicate that time has ended and any final
> functionals can be computed.

I agree, we need more information about the time.

> (incidentally, using prefixes is unpythonic. Should we define an
> adjoint or a libadjoint namespace and have adjoint.time_start, for
> example? Actually one way we could do it is to recognise the adjointer
> as the object embodying the recorded simulation and therefore have
> adjointer.time_start() or even adjointer.time.start() opinions?)

The inconsistency in (admittedly my) API is starting to bug me,
alright. Some functions start with adj_ and some don't. I think that
making all functions live in the adj. namespace is the cleanest
way. I don't want to expose the underlying adjointer object, because
we often add a layer in between the adjointer and the user-callable
API to make things nicer for the user (for example, to dereference
the .data attribute of Vectors, etc.)

In that light: adj.time.start()?

Patrick