InterpolateBlock doesn't stash interpolators

[ReubenHill]

The adjoint InterpolateBlock creates a new interpolator every time it is evaluated, e.g. for calculating the hessian.

Extra interpolators should probably be stashed on the Interpolator as necessary - though this is perhaps not the only solution. I believe @nbouziani has worked on a similar fix elsewhere - comments welcome.

[nbouziani]

Sorry for the delay! I have commented what I think is the same issue, cf. #1981.

[ReubenHill]

(Closed the duplicate issue)

[nbouziani]

I have not dealt with similar issues in #1674 since the interpolate is part of the external operator evaluation process (happens inside the external operator), that is there is no additional InterpolateBlock induced.

Just to be sure I understand correctly: You want to stash Interpolator(expr, space) right ? Is it not just when you interpolate via Interpolator(expr, space).interpolate(...) that there is a computational cost ? If yes, then I don't understand the problem with defining a new Interpolator every time something needs interpolating.

[ReubenHill]

If expr and space are the same multiple times (as I think typically they will be when doing hessian evaluations as part of a firedrake_adjoint.minimize(Ĵ, method='Newton-CG')) you really ought to stash and reuse the Interpolator to save compile time costs

[nbouziani]

Ok I see. If this is just for adjoint purposes, then the information about which interpolator has already been made could also be stashed directly to the InterpolateBlock class. Although I am not sure which option is the most judicious.

[dham]

That doesn't quite work, because you get a new InterpolateBlock for every interpolate operation.

[nbouziani]

I meant having a kind of cache mechanism via shared attributes as it is done for forms with TSFCKernel.

[dham]

Global caches for interpolation matrices are going to get very expensive very fast.

[nbouziani]

Ok I see.

[wence-]

But kernel caching should be implemented for interpolation as we do for form assembly

[dham]

We should do that. However we can also avoid reassembling the matrices associated with a single interpolator object.

[wence-]

If we tie the lifetime of these things to the lifetime of the object in the forward model then that should DTRT.

[wence-]

Actually, that doesn't work