Currently there are a variety of allowed input types for matched pixel and wavelengths - both can be an input quantity array, an input Q table with specific column names, a combination of table and column, or two separate one-column tables. I think this is a bit confusing, especially because it becomes the case where some parameters are only used if others are set, and we should allow only one input format. The decision of which one to allow (two arrays vs. table) should be standard across the package as well. I think that requiring two quantity arrays makes the most sense, since this avoids checking for specific column names and that the data type matches these column names.
Additionally, there are references in the code to matched pixel+frequency being allowed for the fit, but there are checks for the presence of specifically a 'wavelength' column, so this simplification of inputs should address this as well.
Currently there are a variety of allowed input types for matched pixel and wavelengths - both can be an input quantity array, an input Q table with specific column names, a combination of table and column, or two separate one-column tables. I think this is a bit confusing, especially because it becomes the case where some parameters are only used if others are set, and we should allow only one input format. The decision of which one to allow (two arrays vs. table) should be standard across the package as well. I think that requiring two quantity arrays makes the most sense, since this avoids checking for specific column names and that the data type matches these column names.
Additionally, there are references in the code to matched pixel+frequency being allowed for the fit, but there are checks for the presence of specifically a 'wavelength' column, so this simplification of inputs should address this as well.