Implementation of a Parametrised Reduced Functional

[divijghose]

Current method to use parameters

The derivative_components optional argument of ReducedFunctional is used after adding parameters to the list of controls, to specify which components are to be zeroed out (by omitting them from derivative_components). This allows the user to update parameters by calling the Reduced Functional while zeroing out the gradient with respect to the parameters.

Parametrised Reduced Functional

ParametrisedReducedFunctional is a subclass of ReducedFunctional with wrapping call and derivative methods, with the parameters as attributes. The parameter_update method is called to update parameters. The parameters are not included in the derivative calculation and the optional argument derivative_components is not required.

[JHopeCollins]

In the current implementation ParameterisedReducedFunctional inherits the controls property from ReducedFunctional. I think this means that this will pass when really it shouldn't:

prf = ParameterisedReducedFunctional(functional, user_controls, parameters)
assert len(prf.controls) == len(user_controls) + len(parameters)

This will also be a problem later because the optimisers will expect:

len(prf.derivative()) == len(prf.controls)

when you will actually have (correctly):

len(prf.derivative()) == len(prf.user_controls)

If this is the case then you may need to override the controls property for ParameterisedReducedFunctional so that it returns only what the user thinks are the controls.
However, if I remember correctly how Python inheritance works, that will then mean that when the parent ReducedFunctional accesses self.controls (for example to calculate the derivative here), it will won't see the full list of user_controls + parameter, but will only see user_controls.

To get around this, you may have to instead inherit from the AbstractReducedFunctional base class and just internally create your own ReducedFunctional(functional=functional, controls=user_controls+parameters).

[divijghose]

In this intermediate implementation, the ParametrisedReducedFunctional inherits from AbstractReducedFunctional. This means that self.controls returns user_controls, which is the required behaviour as discussed above.

However, a lot of the code is duplicated, and, as @colinjcotter suggested, a more efficient way to do this would be to call ReducedFunctional inside ParametrisedReducedFunctional, which will get the required behaviour from self.controls while reusing most of the methods from ReducedFunctional.

[JHopeCollins]

We should have a think about whether these should be for all_controls (as it is currently), or just the ParameterisedReducedFunctional.controls, and possibly add separate callbacks for the parameters.

[JHopeCollins]

Repeated arg in the middle of the kwargs?

Suggested change

controls: derivative_components,

[divijghose]

@JHopeCollins, the argument list is the similar to the one used in ReducedFunctional, with derivative_components omitted and parameters added.

[JHopeCollins]

Does passing an empty list work?

[divijghose]

Passing an empty list should not work. I have updated ParametrisedReducedFunctional to check for it:

        if len(Enlist(parameters)) == 0:
            raise ValueError("Parameters list cannot be empty. If no parameters are needed, use ReducedFunctional instead.")

along with a corresponding test

def test_parametrised_rf_empty_parameter_list():
    """Test that creating a ParametrisedReducedFunctional with an empty parameter list raises an error."""
    c = AdjFloat(2.0)
    J = c * 3.0 
    with pytest.raises(ValueError):
        Jhat = ParametrisedReducedFunctional(J, Control(c), parameters=[])

[JHopeCollins]

If the user didn't give us a list of controls then we shouldn't return a list of derivatives

Suggested change

	return Enlist(derivatives_all)[:self.n_opt]
	return self.controls.delist(Enlist(derivatives_all)[:self.n_opt])

[JHopeCollins]

Suggested change

	return hessian_all[:self.n_opt] # Return only the hessian components corresponding to optimization controls.
	# Return only the hessian components corresponding to optimization controls.
	return self.controls.delist(Enlist(hessian_all)[:self.n_opt])

[JHopeCollins]

self._reduced_functional.hessian will expect len(m_dot) == len(self._all_controls) so I think you will have to pad it with zeros (but you should write out the maths to check this will DTRT). Something like:

m_dot_all = Enlist(m_dot) + [p._ad_init_zero() for p in self.parameters]

[JHopeCollins]

1. You'll need the same zero-padding of m_dot here as in the hessian.
2. The result of tlm lives in the same space as the functional so you don't need to apply the mask.

Suggested change

	@no_annotations
	def tlm(self, m_dot):
	tlm_all = self._reduced_functional.tlm(m_dot)
	return tlm_all[:self.n_opt] # Return only the tlm components corresponding to optimization controls.
	@no_annotations
	def tlm(self, m_dot):
	tlm_all = self._reduced_functional.tlm(m_dot)
	return tlm

[JHopeCollins]

This is shaping up nicely!

I've left a few comments, but my main two requests are for a bit more test coverage.

1. Please can you test the convergence rates from taylor_to_dict? This will do both the first and second order taylor tests so that we can check that the tlm and hessian are correct.
2. Please can you add an optimisation test? You could just use a quadratic polynomial as the objective functional with the coefficients being parameters. Then the optimisation should be globally convergent and you can test the result against the analytic minimum.
   If you want to be very thorough then you could also test a multivariate quadratic to make sure that it works with multiple controls.

[JHopeCollins]

It'd be nice to show a few lines of maths to explain here like in the docstring of AbstractReducedFunctional

[JHopeCollins]

Why does prf_np = ReducedFunctionalNumPy(parameterised_rf) not work? We should fix that instead of duplicating all this code. In theory the numpy rf should work for any AbstractReducedFunctional.