libadjoint team mailing list archive

[Patrick Farrell <patrick.farrell06@xxxxxxxxxxxxxx>]

On 10/06/12 12:25, Simon Funke wrote:
> > To me, a Constant just means that it is "constant in space and time".
> > Doesn't mean it's exactly known, or not variable from one model run
> > to another. For example, in the mantle, the exact Rayleigh number isn't
> > known -- it makes good sense for it to be a Constant in the model, but
> > optimised as part of the assimilation.
>
> I understand your example but I am still not convinced that Constant
> is the right choice here.

What does "the right choice" mean? Users *use* them. For example, the
mantle convection code I first got from Marie used a Constant for the
Rayleigh number (and many other things too). A user will want to
optimise with respect to those. We should support Dolfin as people write
it, and not delete useful, working, tested code for theoretical reasons
about distinctions between scalars and functions that take the same
scalar value everywhere in time and space.

> To me, Constant is just a special case for an Expression; therefore
> even though it is constant in time and space, it is not a scalar
> value but a non-discretised function in space (the documentation

But as it is used in practice it means scalar values.

> Now, let's use the fact that the type of the Parameter and the
> gradient are always the same.

The gradient of a Functional with respect to a Constant is just
a scalar number. So it can be represented as a Constant, in exactly
the same way. This doesn't break any principle.

> has some issues: First ScalarParameter is a misleading name (maybe
> ConstantParameter or

I suppose you'd think it's misleading if you think Constants don't
represent scalars. We can call it ConstantParameter, I agree that's
probably better.

> ExpressionParameter). Second the gradient of a ScalarParameter should
> not return a single number
> but an Expression.

It should return a Constant, actually, for exactly the principle you
stated above. At the moment it doesn't, it just returns a Python float.

> Third I have no good idea how this gradient
> Expression can be computed.

Gradients of Constants are being computed, in lots of tests, and those
gradients are being rigorously verified.

> In my opinion, the main difficulty is the fact that
> Constant/Expression are non-discretised functions that can be written
> as a compact analytical format (e.g. 1.0 or sin(x)). However, the
> gradient will in general not be representable in a compact analytical
> format and so I do not see a nice way to fix this.

I agree about UFL expressions (not Expressions). We need to have the
control discretised to differentiate with it.
> On the other side, a Real function is a scalar, so this is what you
> really want in your Rayleigh example.

What I "really want" is for the code normal users write to work with
as few modifications as possible. *We can support differentiating
with respect to Constants* -- we already have, in fact -- so why on
earth would we delete that, and make users replace them with Functions
defined on FunctionSpace(mesh, "R", 0)?

> To make a long story short, I think we can only compute gradients with
> respect to dicretised objects -
> and that is not the case for Constant/Expression objects.

Constants are "discretised objects". They can be represented exactly
with one real number. So there's no problem in differentiating with
respect to them. As I keep saying, it works right now, in the trunk.

Patrick