Starspots emit light and---if their surface coverage is large enough---that light can be significant enough to be perceived as a weak constituent in the stellar-disk-averaged spectrum. The extent of this starspot emission can be quantified with two parameters:
$f_\mathrm{spot}$ the coverage fraction of the projected stellar disk exhibiting starspots (e.g. 7%)
$T_{\mathrm{spot}}$ the characteristic temperature of the spot, typically less than the ambient photosphere Temperature (e.g. "2800 K)
Idea: We could add these two parameters as new sliders in the dashboard.
The problem with this idea is that it's fairly specialized: most folks don't need such parameterization, since it affects special categories of stars (mostly pre-main sequence, sub-subgiants, and M dwarfs). Only the most profoundly spotted stars ($f_{\mathrm{spot}}\gtrsim20$%) exhibit enough collective emission to be visually detected in a typical echelle spectrum. So most practitioners safely ignore this effect, or turn to precision techniques. In general, caution should be exercised when deciding to build a tool that is narrowly tailored to a tiny application area.
One strategy could be to generalize the dashboard code: make it more modular and therefore easier to stick pieces together on-the-fly. That redesign would suit both this application and eclipsing binaries, veiling, and other ideas. As currently written, the widgets are hard-coded, preventing this ease of extensibility. I can't easily think of a way to generalize the code, but I haven't thought about it too much. I suppose a dialog about it with some architecture-minded folks could reveal some new strategy.
Another strategy would be to build it, but keep it out of gollum altogether: to allow custom plug-ins or verbatim-mimicked/adapted dashboards that tolerate hardcode, and they simply live elsewhere, so as not to muddle gollum too much.
I think for now I favor the latter approach: build a bespoke dashboard offline. We can take the lessons learned from it and apply them back into gollum later on, if needed.
Starspots emit light and---if their surface coverage is large enough---that light can be significant enough to be perceived as a weak constituent in the stellar-disk-averaged spectrum. The extent of this starspot emission can be quantified with two parameters:
Idea: We could add these two parameters as new sliders in the dashboard.
The problem with this idea is that it's fairly specialized: most folks don't need such parameterization, since it affects special categories of stars (mostly pre-main sequence, sub-subgiants, and M dwarfs). Only the most profoundly spotted stars ($f_{\mathrm{spot}}\gtrsim20$%) exhibit enough collective emission to be visually detected in a typical echelle spectrum. So most practitioners safely ignore this effect, or turn to precision techniques. In general, caution should be exercised when deciding to build a tool that is narrowly tailored to a tiny application area.
One strategy could be to generalize the dashboard code: make it more modular and therefore easier to stick pieces together on-the-fly. That redesign would suit both this application and eclipsing binaries, veiling, and other ideas. As currently written, the widgets are hard-coded, preventing this ease of extensibility. I can't easily think of a way to generalize the code, but I haven't thought about it too much. I suppose a dialog about it with some architecture-minded folks could reveal some new strategy.
Another strategy would be to build it, but keep it out of
gollum
altogether: to allow custom plug-ins or verbatim-mimicked/adapted dashboards that tolerate hardcode, and they simply live elsewhere, so as not to muddle gollum too much.I think for now I favor the latter approach: build a bespoke dashboard offline. We can take the lessons learned from it and apply them back into
gollum
later on, if needed.