-
Notifications
You must be signed in to change notification settings - Fork 32
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interpolation in Parthenon #1015
Comments
Glad to hear it was useful :) Regarding whether or not it is the right move to upstream, I defer to others, but I think it should be straightforward to do. The phoebus tracer interpolation is just tri/bi/linear interpolation here. The only thing used from |
As @AstroBarker said, we don't really use
I'd be happy to upstream our interpolation tooling. There's two paths to that:
|
I now put everything into one file, see https://github.com/parthenon-hpc-lab/athenapk/blob/pgrete/tracer/src/utils/interpolation.hpp and also "reused" the In general, I think that this kind of functionality would be great to be available from within Parthenon either directly (i.e., moving the merged file upstream) or as an (optional) submodule. |
I'm super in favor of this being upstreamed. Since you already have it ported over for athenapk do you want to just submit a PR? I can also find some time to do that if you prefer. |
New day, new question 馃槂
I happily derived tracers for AthenaPK from @AstroBarker implementations in Phoebus (note this is the first non-default "package" in AthenaPK) and I'm now wondering what to do about interpolation.
I saw that the ones in Phoebus carry a line of dependencies: singularity-eos -> spiner -> ports-of-call
Are the any plans to upstream (some simplified versions) or would that not be a good idea, @brryan @Yurlungur ?
If I followed the details correctly, a minimum version would not require that much code additional code in comparison to what's already in Phoebus.
The text was updated successfully, but these errors were encountered: