CarpetX: Interpolator caches

[Lucas Timotheo Sanches]

Pull request and detailed explanation is here

[Lucas Timotheo Sanches]

Please review

[Roland Haas]

Having a hidden cache is dangerous since it will accumulate cache entries that may no longer be required (eg a run that never regrids but updates coordinates). Something like this happened to the HTTP thorn

Better maybe to let the user code control cache entries.

Eg. Slab uses (in Slab/src/slab.h (though apparently there’s no LaTeXed docs for this) Slab_MultiTransfer_Init and Slab_MultiTransfer_Finalize to manage lifetime of its control structures. CarpetInterp2 (being C++ only) uses the fasterp_setup_tclass (CarpetInterp2/src/fasterp.hh).

This also avoids the need to have to hash the input coordinates etc. or otherwise find out which cached entry to use.

This can be added to the regular Cactus interpolator (could be in Carpet as well, though apparently I never created code for this) by having a handle based interface and storing the (int) handle is a parameter in the interpolator parameter table (in fact the interpolator is free to modify the table, so it could actually allocate the cache entry is an “emtpy” field for the cache handle is found in the table, which would require only call to deallocate the handle object).

[Roland Haas]

@Lucas Timotheo Sanches udpated the pull request to split the functionality into a “setup” and an “interpolation” step.