Consider reintroducing color BC table options

[Debraheem]

I've received comments from some users who have been reading in their own BC tables in r24.08.1 and prior. There is some frustration over BC tables options being removed from MESA during the colors overhaul.

An example inlist from a user has something like:

! Extra color files
color_num_files=3
color_file_names(2)='blackbody_johnson.dat'
color_num_colors(2)=5
color_file_names(3)='extras/extra_color_file.dat'
color_num_colors(3)=17

In this circumstance, the user was reading in ecternal BC tables, for example the mist tables, since they cover a wider range than the Atlas9 models in some regions. It seems, providing users with both the old BC table controls as an option along with the new atm convolution approach would be the best approach.

Perhaps we can reintroduce these controls from the old colors module, so it is backwards compatible with some of the features present before the colors module rehaul.

@nialljmiller, do you know how much work would be involved in carrying this out? I'm not suggesting you do this. it is certainly something I or someone else could address in the future.

[nialljmiller]

This would not be too difficult to include as we could check if the user points to a pre-computed file and if so, skip the on-the-fly computation. We can do this to reduce compute and preserve legacy compatibility -- the functionality the user wants is still there, just in a different form now.

The reason the new colors module doesn't natively use this is because it allows the user more flexibility once they are comfortable with the new procedure. Also, as SED -> Photometry is a non-linear and lossy process, I believe it might be more accurate to recalculate on-the-fly.
The new colors module calculates the data previously given to color_file_names(3) on the fly. It does this as the user points the colors module to a stellar atmosphere table (Kurucz2003 being the default, but it is not difficult to change) and a set of filter transmission curves.

An example inlist setup for what I am talking about:

&colors

instrument = 'data/colors_data/filters/LSST/LSST'
stellar_atm = 'data/colors_data/stellar_models/tlusty_mergedbin/'

/ ! end of colors namelist

So in this case it will calculate the BC table on the fly for the tlusty_mergedbin stellar atmosphere table -- http://svo2.cab.inta-csic.es/theory/newov2/index.php?models=tlusty_mergedbin
and the LSST filter profiles -- http://svo2.cab.inta-csic.es/theory/fps/index.php?mode=browse&gname=LSST&asttype=
Both of these are easy to obtain (and prepackaged for the colors module) with this tool -- https://github.com/nialljmiller/SED_Tools

[Debraheem]

Awesome, thanks for the feedback, perhaps we can provide this backward compatibility in the next upcoming release (with the new build system), and not worry about it for 26.3.1.

I am using colors for a project currently (thank you Niall), so i'm relatively familiar with the controls :). I still haven't tried your updated SED_Tools scripts yet though, they appear extremely useful.

I think for some specific cases, where atm tables are not available, some might still prefer the precomputed BC interpolation approach, however I see what you mean: interpolating spectra and then convolving with a filter is not equivalent to convolving spectra with filters to produce colors and then interpolating the colors! That's believable, and I hope you can show that in your manuscripts on the new colors module, since many still rely on BC tables exclusively. It would be very interesting to know how bad the systematics are from interpolating BC tables alone as opposed to interpolating the spectra first 🤔.

[Debraheem]

If one has already computed a stellar evolution track, is there a way in which colors could be called in post on its own as a module on a precomputed history file, for example a history file from a previous mesa version to produce the colors in post? Would that also be a useful feature, so one could post process a whole grid of tracks in general by calling the colors module, or using some sort of python wrapper? Maybe this capabilities is already contained within the SED_Tools?

I know this sounds more and more like just using MSG, but can be a bit more involved since it's a little more generalized. I'm curious what your thoughts are on this idea, or if it's even worth exploring?

[Debraheem]

Another thought occurred to me, would it be useful to have an option for reading in extinction curves as well inside the colors module? I was thinking a frequency dependent extinction curve applied to the seds before the convolution is done could be interesting, although I'm not sure how involved this would be or if it even makes sense?

Maybe this is something you've already though about?

[nialljmiller]

Hi Eb,

It is exciting to see such consideration of this module. I look forward to seeing this grow.

• I will certainly show some demonstration of how the placement of the interpolation step can introduce some errors. Im sure its rather subtle but certainly worth quantifying.

• I have been thinking about adding a post-processing step using python in a way exactly how you described. It is lower down the list as MSG does exist, but I wonder if there is a future where post processed colours module and MSG are combined in some way. I have a half-baked repo attempting to do just this, if I/Claude can finish it off I will be sure to send it to share it.

• Extinction is at the top of my list of new functionality to add. I played with some simple reddening a few months ago but I realised this could be an undertaking as large as the colors module depending on how much control we want to give to the user. It would even be possible for this functionality to be enabled with a full extinction map, so the user only needs to enter astrometric values (https://irsa.ipac.caltech.edu/applications/DUST/). (also, detector response curves and tellurics in the far future could be nice too)

[Debraheem]

Exciting, I'm happy to see you continually developing and supporting the colors module!