Colors Bugfix: use Fe/H instead of zbase

[Debraheem]

This pr addresses the colors bug motivated by Jake Hassan's investigation in #938.

I think the main issue was that the colors module was using Zbase instead of the photospheric metallicity for interpolating the atmosphere tables. The solution was to switch to using metallicity, and add a control for the default reference metallicity used in the computation of the atmosphere tables, which i believe is gs98 for Atlas9. I've added docs for this change as well, but a changelog entry is still necessary, and potentially a "known bugs" entry.

mesa/star/private/history.f90

Lines 270 to 271 in 9ee3f0a

	call data_for_colors_history_columns(s%T(1), log10(s%grav(1)), s%R(1), s%kap_rq%Zbase, &
	s% colors_handle, num_colors_cols, colors_col_names, colors_col_vals, ierr)

And then in another location, negative metallicities were being rejected (I think since Z was being used instead of [Fe/H])

mesa/colors/private/colors_history.f90

Line 115 in 9ee3f0a

if (t_eff >= 0 .and. metallicity >= 0) then

@nialljmiller , @mjoyceGR perhaps you could sweep through these changes and see if they make sense?

I've done some preliminary testing with a 5 Msun model that i stop on the pre-ms when it hits 5000K, for five different metallicities. Below I show the SED normalized and not normalized to illustrate that the colors module is working, and i did this test with type_2_opacities = .true., the mesa default.

One concern raised by this investigation is: what do we do when there is no H? Obviously the current atm tables are H atmosphere tables, but we might want to think about a bette fall back for no H than adopting the lowest metallicity table in the grid? I'm not sure.

If this passes testing, we can merge it into the r25.12.1_colors_updated branch as well, which will ultimately becoming r26.3.1, or probably r26.4.1 now.

[JakeBHassan]

Just thought I would mention, a possible alternative could be to calculate the Z values for every ATLAS model on the grid, and then use Z throughout the whole code.

[Debraheem]

@JakeBHassan That's a good idea!

[Debraheem]

I'm not totally sure interpolating in logZ would provide any benefit or be any different from interpolating in [Fe/H], but i need to think about it longer.

Sidenote: I notice the Atlas grids shipped with MESA stop at only -2.5 in [Fe/H], i think. I'm guessing this was a deliberate choice by @nialljmiller so as to not to inflate the repo size, but i'm curious how expensive it would be to extend the grid downward to say -4.

[nialljmiller]

Yes, given the GitLFS issues I was trying to use the smallest usable set of the data. I dont think it would be too much more data to extend this. I think the data that is shipped with the colors module (filters and SEDs) could be considered further.

[Debraheem]

I will cherry pick this branch into r25.12.1_colors_updated shortly. We can update the changelog and bug_report there, and once r25.12.1_colors_updated is ready for release, we can merge this pr into main and update the changelog on main from the colors branch.

[VincentVanlaer]

Closing since this has been merged to r25.12.1_colors_updated