libadjoint team mailing list archive

["Marie E. Rognes" <meg@xxxxxxxxx>]

On 06/11/2012 10:55 AM, Patrick Farrell wrote:
> 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.

Agree. Whatever DOLFIN does later on that I have any influence on
in the time course of, say the next year, will be orthogonal to this.

> > 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.

I fully agree that if you have integrals and evaluation at points in time,
most functionals should be covered.

However, one comment: do we really have any underlying continuous 
representation
of, say, 'u' over the time interval (0, T)?  As far as I understand, 
what we've
got is a set/sequence of {u_k} and a set of times {t_i}. Any integration 
will
be some form of guess of what these u_k corresponds to, right? I guess
what I'm asking is how you can deduce an integral from a sequence of fields
which are decoupled from the original (time-dependent) pde.

> > 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()?

Yes, I like this a lot better than say adj_time_start.

--
Marie

> Patrick