dolfin-adjoint

A better abstraction for parameters

Registered by David Ham

Describing the model then going back and identifying parameters is backwards. A more powerful approach would be to describe potential parameters when creating the model.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

Currently, the main parameter case is InitialConditionParameter. The modus operandi for this class is that you specify a coeff and libadjoint uses the initial condition of the parameter as the parameter. In effect, we first set up the model, then we attempt to describe what it is in the model which constitutes the parameter. This is rather hard to generalise.

Recall that an initial condition is represented by libadjoint as an additional equation of the form

I u = ic

Suppose now that in setting the initial condition we label ic as a parameter in advance. Something like:

u = Parameter(ic)

Parameter ic would have to return a decorated Function so as not to break forward Dolfin functionality. However when u eventually hits a solve, the presence of a parameter could be recorded. This then establishes the presence of the parameter and would enable dolfin-adjoint routines such as compute_gradient to immediately do the Right Thing.

This has the advantage that a parameter need not just be an explicit initial condition, it could be a coefficient in a form or a boundary condition without much change. I think it must also be possible to extend this to cover time-varying parameters in a nice manner (do Dolfin TimeSeries help here somehow?)

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.