libadjoint team mailing list archive

[Patrick Farrell <patrick.farrell06@xxxxxxxxxxxxxx>]

On 09/06/12 22:42, Simon Funke wrote:
> > Why are we going to drop Constants?
> Maybe the words "likely to be dropped" was too strong here. However
> there a few reasons against allowing Constant to be a parameter in
> doflin_adjoint:

"allowing Constant to be a parameter" is another strange choice of
words, no? Constants are things users of Dolfin models will use in
their models. Since it's perfectly reasonable for us to treat it
as a Parameter (in fact, all the code is already there and working)
I don't see why we'd "disallow" it -- we should try to support as
much of Dolfin as we can.

> - Constant can be fully replaced by a function over a 'Real' functionspace.

True. We should support those as well (SteadyFunctionParameter, or
something: eventually we'll have a NonsteadyFunctionParameter, too).

> - The API interface to Constant is somewhat limited. For example, it
> does not allow to directly access the float values of a vector valued
> Constant (in particular there is no Constant.vector()). The only way
> to access this data is to call eval() on a random point.

Well, if the Dolfin API is lacking, that can be fixed. I know some
friendly Dolfin developers, and they take patches :-)

> - The word 'constant' implies that the value is fixed, hence allowing
> to compute its sensitivity or even optimising a fixed value could be
> misleading.

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.

> Another issue that I came across (but haven't fully verified it yet):
> As far as I know, in contrast to Functions, Constants are not passed
> by reference into python functions. That means that one has to be
> really careful with dolfin_adjoint to never pass the Constant into a
> function to not loose the original reference.

I don't understand what this means, but I don't see why it implies we
should delete ScalarParameter.

Welcome back :-)

Patrick