moustakas
commented
6 months ago It sounds like there's quite a bit of interest in this project.
To jumpstart the effort, @sbailey pointed out that functionality already exists to read BOSS-style spectra, including mocking up a DESI-compatible resolution matrix: https://github.com/desihub/redrock/blob/main/py/redrock/external/boss.py#L81
Since FastSpecFit is agnostic about the number of cameras in its input spectra, this should be pretty straightforward to implement.
Sent to the GQP team on Slack:
@Wei-Jian Guo, during the GQP telecon / work session yesterday, you asked whether FastSpecFit could be developed to work on SDSS spectroscopy and I said that this wasn’t something I was planning to work on (but volunteers were welcome!). The fitting engine, of course, doesn’t care where the data come from, but FastSpecFit’s I/O is specialized to the DESI data model, particularly the resolution matrix. However, while thinking about it some more, rather than changing FastSpecFit, what if we just changed the SDSS spectra by putting the data into the DESI data model? I know that Redrock has been run on (e)BOSS spectroscopy, so code must already exist to transform SDSS’s measurements of its line-spread function into a DESI-like resolution matrix, and many of the other (fairly minimal) required inputs to FastSpecFit should be quite straightforward to adopt. Once this hard work is done once, we would then have the benefit of FastSpecFit’s parallelism and speed and the ability to add more functionality to the code and run it over the SDSS dataset many times. The time-domain work you’re doing on changing-look spectra, I think, would especially benefit from a value-added catalog like this.