Today we conducted valuable user testing with @astrocaroline. Key insights:
HPFSpectrum(file) Does not work out of the box: file is a kwarg and not just an arg. I think that choice is baked-in by Spectrum1D accepting Spectrum1D(wavelength, flux, error), but that use case is extremely rare for our custom HPFSpectrum, and would indeed break most of our methods that assume certain metadata from the get-go. I propose we:
[ ] Study if it's possible to turn file into the only arg?
HPFSpectrum(file=file, order=???) we currently default to order=19, to ensure that we reutrn back a single echelle order. We have intentionally made the single order the default pattern for most applications. Eventually, we should consider support for stitching orders. But then the spectra become too bulky to plot at full native resolution. We may one day want to support a scenario where the user passes order='all' or order=[1,2,5], we return a SpectrumList object (which we already support), and then the user can stitch the orders together.
Or maybe we state that HPF spectrum defaults to returning a SpectrumList (aka order='all'), but then the common usage pattern is: spec.get_order(10).normalize().... That's great because we can implement a method .get_order(wavelength=1.0830*u.micron) that fetches the single order of interest. I like this idea the most.
[ ] Implement a get_order() method on SpectrumList objects, and add a flag for HPFSpectrum(order='all')
Finally, we found that the order of operations matters, which we knew, but that such ordering should be explained better or maybe trigger a warning? For example deblazing caused problems when it was not previously normalized.
[ ] Add a warning when it's clear that certain expected operations have not occurred yet (e.g. spectrum has NaNs or is not normalized).
Today we conducted valuable user testing with @astrocaroline. Key insights:
HPFSpectrum(file)Does not work out of the box:fileis a kwarg and not just an arg. I think that choice is baked-in by Spectrum1D acceptingSpectrum1D(wavelength, flux, error), but that use case is extremely rare for our custom HPFSpectrum, and would indeed break most of our methods that assume certain metadata from the get-go. I propose we:fileinto the only arg?HPFSpectrum(file=file, order=???)we currently default toorder=19, to ensure that we reutrn back a single echelle order. We have intentionally made the single order the default pattern for most applications. Eventually, we should consider support for stitching orders. But then the spectra become too bulky to plot at full native resolution. We may one day want to support a scenario where the user passesorder='all'ororder=[1,2,5], we return a SpectrumList object (which we already support), and then the user can stitch the orders together.Or maybe we state that HPF spectrum defaults to returning a SpectrumList (aka
order='all'), but then the common usage pattern is:spec.get_order(10).normalize().... That's great because we can implement a method.get_order(wavelength=1.0830*u.micron)that fetches the single order of interest. I like this idea the most.get_order()method on SpectrumList objects, and add a flag forHPFSpectrum(order='all')Finally, we found that the order of operations matters, which we knew, but that such ordering should be explained better or maybe trigger a warning? For example deblazing caused problems when it was not previously normalized.
NaNs or is not normalized).