'Action' object has no attribute 'ufl_shape'

[pbrubeck]

I would like to create a FormSum where one of the weights is an instance of action.

from firedrake import *

mesh = UnitIntervalMesh(2)

V = FunctionSpace(mesh, "CG", 1)
b = Cofunction(V.dual())
u = Function(V)
f = action(b, u) * b

assemble(f)

I get the following error message:

Traceback (most recent call last):
  File "/home/pbrubeck/git/dphil_thesis/static_condensation/snippets/bug_action.py", line 8, in <module>
    f = action(b, u) * b
  File "/home/pbrubeck/firedrake-dev-20221228-mpich/src/ufl/ufl/form.py", line 186, in __rmul__
    if is_scalar_constant_expression(scalar):
  File "/home/pbrubeck/firedrake-dev-20221228-mpich/src/ufl/ufl/checks.py", line 73, in is_scalar_constant_expression
    if expr.ufl_shape:
AttributeError: 'Action' object has no attribute 'ufl_shape'

[nbouziani]

I am not sure we want Action to have a ufl_shape. The error you are observing is more a consequence of the assumption that Form can only be left-multiplied by ufl.Expr objects. Given the recent discussion on relaxing the assumption on the type of FormSum's weights, this check needs to be updated to consider non-scalar types as well.

I think we may want to have something like:

class BaseForm(...):
     ...
     def __rmul__(self, scalar):
          # `scalar` can either be a BaseForm mapping to R or a constant scalar value
          if (isinstance(scalar, BaseForm) and not len(scalar.arguments())) or is_scalar_constant_expression(scalar):
               return FormSum((self, scalar))
          return NotImplemented

[pbrubeck]

It should be more or less straightforward to allow for non-constant FormSum weights. I'm not saying this would be the best approach, but perhaps we could handwrite the product rule in derivative(). Could it be that straightforward?

[nbouziani]

Updating the differentiation rule at the derivative level is one step. You also need to:

• Update the DAG representation of FormSum, i.e. add the weights to its list of children.
• Update the DAG visitor accordingly (currently assumes the operands are the components)
• Update the assembly (in firedrake) so that weights are visited when their assembly is necessary

If you want to have a try, I would recommend having a test that computes the adjoint model of assembling a FormSum with non-constant weights. This would test your differentiation, assembly, and AD implementations.