Modular science pack idea

[drvdputt]

In my recent work, I have started a new habit where I treat science packs in a modular way.

An example use cases is as follows:

You have two objects:

1. A PDR
2. A galaxy

And you would like a science pack situation as follows

• dust_feature tuning: keep it the same for both. And you are making frequent adjustment as testing them on both objects.
• dust_continuum tuning: custom for each. And the galaxy needs a starlight component too.
• (lines: separate pack for PDR and galaxy)

In that case you could put the dust features in a general file, and the continuum in separate ones
dust_features.yaml, continuum_pdr.yaml, continuum_galaxy.yaml

To load them and combine them into a single science pack, I wrote the following function

from astropy.table import vstack
def make_multi_yaml_model(*args):
    return Model(vstack([Features.read(fn) for fn in args]))

If we think this would be something useful for the general userbase, the minimum effort to implement this would be to just allow Model to take a list of YAML files at setup, and make it apply this function. In practice, it would probably be best to include a few checks though. Most importantly, making sure that all feature names are unique.

[jdtsmith]

This is interesting. Separate line packs might also be very smart, since non-existent lines chew up CPU, and sometimes you just don't need that many. A separate continuum pack makes sense too.

In terms of what packs to distribute, this is harder. We don't want to make it easy for users to shoot themselves in the foot, so shipping "blessed combinations" make sense. From that point of view, extending our YAML Features syntax to allow referencing other sibling YAML files might make the most sense, e.g. an entire pdr.yaml pack could read:

scipack_include: pdr_lines
scipack_include: classic_continuum
scipack_include: classic_starlight
scipack_include: classic_attenuation
scipack_include: ice_absorption

This would include pdr_lines.yaml, etc. (and warn about any duplicate names). Of course you can directly remove features from the model.features table itself.

One other issue is tied constraints, which may bridge modular input packs. But we can cross that budget when we get to it.