Return physical constants object from opacities

[brryan]

It would be nice to see the physical constants being used by singularity-opac in downstream codes for consistency. This PR provides a way to do that, although we lose the constexprness of the constants with this approach (templating the variant to make ReturnPhysicalConstants a static method appears to be a tricky proposition).

[Yurlungur]

This is a nice idea. Unfortunate we can't output the constants with a static method though... I feel like that's much more likely the model we'd want in, e.g., Phoebus. Are you sure you can't do static constexpr to output the object?

[brryan]

This is a nice idea. Unfortunate we can't output the constants with a static method though... I feel like that's much more likely the model we'd want in, e.g., Phoebus. Are you sure you can't do static constexpr to output the object?

The issue I ultimately couldn't avoid was having a variant method that's like

PORTABLE_INLINE_FUNCTION
auto GetPhysicalConstants() const {
  return mpark::visit[](... opac.GetPhysicalConstants();
}

because type deduction for the return value fails because it'll necessarily be different PhysicalConstants types depending on the unit system.

We may want to leave phoebus as-is for now, this change was partially motivated to support made-up physical constants being used for some shock tube test problems, but this approach also lets one at least check the singularity-opac constants for consistency with a downstream code which isn't a performance-critical operation.

My workaround is to have a RuntimePhysicalConstants (constbut notstatic constexprmembers) that is constructed with a constructor templated on aPhysicalConstants object.

[Yurlungur]

Yeah I think your workaround is reasonable. I wonder if an alternative workaround is if the unit system modifier lives on top of the variant, so the return type is known and no visit is required? I.e., an individual opacity doesn't own the unit system, the variant itself does?

[brryan]

Yeah I think your workaround is reasonable. I wonder if an alternative workaround is if the unit system modifier lives on top of the variant, so the return type is known and no visit is required? I.e., an individual opacity doesn't own the unit system, the variant itself does?

I think the issue with doing that is that in a downstream code youll then have to template on the unit system, so you'd have to either have one unit system at compile time or template your whole code on the unit system. Stop me if I'm not seeing a way around that though.

[Yurlungur]

Ah yeah you're right. Let's leave it then.