loghefrac parameter

[kecnry]

This PR:

• introduces an loghefrac parameter next to the existing abun parameter, which is visible if ANY atm parameter starts with "tmap" (in the future we may want this visible_if logic to be more general/flexible to actually test the inputs of the atmosphere itself). The abun parameter is visible if ANY atm parameter does not start with "tmap".

TODO:

• implement compute-level checks for value of loghefrac/abun: TMAP_DA (-10) and TMAP_DO (9.4) are single abundance grids. TMAP_DAO (-5 to 0) and TMAP_sdO (-1.55 to -0.42) are not.
• test coverage for compute-level checks
• attempt to cache which atmospheres support which inputs via basic_axes and switch visible_if logic to rely on that instead of hardcoding atmosphere check
• test coverage for visiblity of loghefrac/abun parameters
• decide whether shipped passbands should include TMAP atmosphere by default (otherwise CI will need to pull one that does or override atm choices)
• clarify parameter definitions and when they are applicable in parameter descriptions and docstring
• confirm qualifier=hefrac vs loghefrac

[Raindogjones]

introduces an hefrac parameter next to the existing abun parameter, which is visible if ANY atm parameter starts with "tmap"

I think this and the converse for abun should come from the basic axes of the new model atmosphere scheme rather than being hard-coded on a per atmosphere basis. i.e. if atm.basic_axes contains abun then expose abun.

confirm qualifier=hefrac vs loghefrac

My vote is for loghefrac as it is implemented as log(He/H)

[kecnry]

I think this and the converse for abun should come from the basic axes of the new model atmosphere scheme rather than being hard-coded on a per atmosphere basis. i.e. if atm.basic_axes contains abun then expose abun.

Agreed, I'll see if I can find a way to do that in a performance-friendly way (perhaps cache it when loading the passbands-list)... but for now this will at least show the functionality.

My vote is for loghefrac as it is implemented as log(He/H)

Ok, that's a bit awkward with abun, but unless we rename that to its true definition (which will be somewhat backwards-breaking), its probably worth it and we should just make sure to be clear with the new parameter. EDIT: updated the PR to use loghefrac now.