-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
InterpolateBlock doesn't stash interpolators #1962
Comments
Sorry for the delay! I have commented what I think is the same issue, cf. #1981. |
(Closed the duplicate issue) |
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 Just to be sure I understand correctly: You want to stash |
If |
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 |
That doesn't quite work, because you get a new |
I meant having a kind of cache mechanism via shared attributes as it is done for forms with |
Global caches for interpolation matrices are going to get very expensive very fast. |
Ok I see. |
But kernel caching should be implemented for interpolation as we do for form assembly |
We should do that. However we can also avoid reassembling the matrices associated with a single interpolator object. |
If we tie the lifetime of these things to the lifetime of the object in the forward model then that should DTRT. |
Actually, that doesn't work |
Why doesn't it work? |
Imagine you have the following setup: def forward(mesh):
# set up forward model
interpolator = Interpolator(...)
while ...:
interpolator.interpolate()
return something_that_is_not_the_interpolator
J = forward(mesh)
compute_gradient(J) So the |
Is this an edge case where stashing on the Interpolator would at least help? Another idea, how about a global cache but only for the Interpolators in the |
No? The interpolator is the thing we're trying to keep alive.
How do you know this has happened? |
By doing the caching in the InterpolateBlock, then when a new InterpolateBlock is made, it looks in the cache of existing |
How do those get collected? |
Well I don't know the details how caching is done at the moment, but I'm imagining some runtime-only global dictionary that's filled via an annotation of an |
what I mean is, how do you decide to throw those interpolate objects away from the interpolateblock? |
I don't think I understand your question? Do you mean getting rid of the cached objects? Presumably if they lived in a dictionary in some suitably global scope, they would only exist as long as a script took to run? |
That sounds like too long. Each |
Solution: Cache all pyop2 Interpolation kernels created in |
Yes, I think that is right. |
Do function spaces have a suitable hash? |
No, but their UFL element does (or should). |
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.The text was updated successfully, but these errors were encountered: