Starry pixel transformation
Hi, @andrew-ayala and I are have been working on some time-domain extensions to starry that we hope to port over to jaxoplanet's starry implementation. One feature we haven't been able to find is the transformation that allows starry to convert between the spherical harmonic basis and intensities sampled at the surface (https://starry.readthedocs.io/en/latest/notebooks/PixelTransform/). It would be wonderful if this functionality were also eventually available in jaxoplanet starry.
Hi @keatonb! Thanks for bringing this up yesterday and opening an issue! @lgrcia and I will chat about implementing this feature.
@lgrcia: Do you think this is something that is better done with your spotter package?
Thanks for pointing that out @keatonb, I think it would be a great addition and not too hard to implement! I will look into it.
As for spotter, @soichiro-hattori, it all depends on the light curve precision needed and the spatial resolution needed. Ultimately I think it would be interesting to have the starry pixel transform for HEALPix maps too. In this case, some of spotter's utilities might come handy.
Just a note to myself that it might be very interesting to try using the transforms from s2fft.
I think one possible goal would be:
- Implement the starry-like pixel transform and test it against
starry - Implement a transform using
s2fft - Benchmark both
If s2fft ends up being used (I suspect it will be way faster), there is the question of what pixel representation to use, among these:
some of them being quite different from the one described in https://arxiv.org/pdf/2103.03758.
If
s2fftends up being used (I suspect it will be way faster), there is the question of what pixel representation to use, among these:
some of them being quite different from the one described in https://arxiv.org/pdf/2103.03758.
Sorry @lgrcia what were you trying to share here?
See also: https://github.com/rodluger/starry/issues/283
Just a note to myself that it might be very interesting to try using the transforms from s2fft.
I think one possible goal would be:
* Implement the _starry-like_ pixel transform and test it against `starry` * Implement a transform using `s2fft` * Benchmark bothIf
s2fftends up being used (I suspect it will be way faster), there is the question of what pixel representation to use, among these:
some of them being quite different from the one described in https://arxiv.org/pdf/2103.03758.
FWIW, I think Healpix makes the most sense, as depending on the maximum ell value of a map, I think there is a minimum spatial scale of interest. But that's admittedly not a speed argument.