Smaller default variant

[Yurlungur]

Given we now have additional infrastructure for automatically building custom variants, I wonder if we should shrink the default variant by removing EOS models not needed by the fortran codes we support. In particular, I think I will avoid providing the 3T EOS's for now, until that point in integration is reached.

Similarly, I wonder if we should remove the EOS's mainly used for V&V from the default variant, e.g., Carnahan Starling, Stiff Gas, etc. We could hide them behind a build option potentially. What do you think, @jhp-lanl ?

[jhp-lanl]

We could move to just injecting the variant right? Even with the Fortran codes we support, I think it's reasonable to ask them to keep around a header file that can define the Variant they want to use.

[Yurlungur]

Yeah---we're already in a place to support that from a build system perspective. We do currently provide a default variant, however, and I think it makes sense to keep some sensible default around.

[jhp-lanl]

Yeah---we're already in a place to support that from a build system perspective. We do currently provide a default variant, however, and I think it makes sense to keep some sensible default around.

Yeah that's true. But I'm just saying I don't think we need the host codes to necessarily determine the variant, and perhaps we want to think of the default variant in a different light. For example, maybe the default variant should just be what's needed to support the existing python bindings.

[Yurlungur]

A reasonable point. Do you think that merits leaving it as is? Or shrinking it a bit?