Various features in PrimitiveSolver

[PeterHammond]

Adds support for Single-Precision floating point NQT functions, hybrid table (1D) + gamma law EoSs, and neutrino equilbrium functions to PrimitiveSolver.

[jfields7]

This might be a wild idea, but I think we could do some tricks in eos.hpp to make it so that the neutrino equilibrium and chemical potential functions are only needed for an EOS where it makes sense to implement them. It would add some measure of compile-time security to ensure that an EOS that doesn't support neutrinos isn't being used in functions that need neutrinos. Maybe something along the lines of

KOKKOS_INLINE_FUNCTION Real GetBaryonChemicalPotential(Real n, Real T, Real *Y) const {
  if constexpr (supports_neutrinos) {
    return EOSPolicy::BaryonChemicalPotential(...);
  }
}

for all the extra functions, where we define supports_neutrinos via something like

template <typename EOSPolicy, typename ErrorPolicy>
class EOS : public EOSPolicy, public ErrorPolicy {
  ...
  static constexpr bool supports_neutrinos = std::is_base_of_v<SupportsNeutrinos, EOSPolicy>;
  ...
};

and then inside ps_types.hpp we add

class SupportsNeutrinos {};

and let EOSCompOSE inherit from that.

[PeterHammond]

I am not in principle against this, however it is not necessarily a blanket statement that all CompOSE EoSs can support neutrinos, and non-CompOSE EoSs can't, so I'm not sure.

[jfields7]

The non-CompOSE case would be easy because we just ensure that a hypothetical neutrino-supporting EOS extends SupportsNeutrinos. Assuming all you need for neutrino support is valid chemical potentials, this also shouldn't be a problem for EOSCompOSE; the existing ReadTableFromFile function tries to load the chemical potentials regardless of whether or not they exist. If it's possible that someone is going to try to use a full finite-temperature table that doesn't include these variables, then there needs to be a runtime check either to disallow these tables altogether or to avoid trying to load those variables. We can't disable the chemical potential functions at runtime, unfortunately, but we could do something more like this in place of SupportsNeutrinos:

class CanSupportNeutrinos {
 protected:
  bool has_potentials;
 public:
  KOKKOS_INLINE_FUNCTION
  bool HasChemicalPotentials() const {
    return has_potentials;
  }
};

Modules that need chemical potentials could check that HasChemicalPotentials returns true, and eos.hpp can still check if EOSPolicy inherits from CanSupportNeutrinos to enable or disable the relevant functions.

Of course, I guess the question is if this is more complicated than simply adding a bunch of empty functions inside other equations of state.

[PeterHammond]

Could we pivot slightly and use the class you suggest to generally keep track of implemented features (rather than explicitly neutrinos)? e.g. the entropy inops we currently have.

[jfields7]

Sure, that would be simple enough. Something like this, then?

class SupportsExtendedFeatures {
 private:
  bool has_potentials;
  bool has_entropy;
 public:
  bool HasChemicalPotentials() const {
    return has_potentials;
  }
  bool HasEntropy() const {
    return has_entropy;
  }
};