Can you explain what's going on with the different versions of each function with and without cBoilT? Could they be combined into a single implementation where the cBoilT argument defaults to a huge value to reduce repeated code?

Also, maybe we should be adding some documentation for the liqProps stuff now, before a documentation debt builds up too much.

Can you explain what's going on with the different versions of each function with and without cBoilT? Could they be combined into a single implementation where the cBoilT argument defaults to a huge value to reduce repeated code?

The idea behind the overloaded functions was a result of some mixture density calls that used a single droplet temp like this one, while many others used a limited component-specific temperature minT = amrex::min(T_part, cBoilT[spf]). The later case was the most common and is used for all other mixture properties.

Also, maybe we should be adding some documentation for the liqProps stuff now, before a documentation debt builds up too much.

Everything we've done so far has been organizational and hasn't changed how the spray module is called from LMeX or C. I can add a brief overview of the liquid property functions used for the PeleMP method if you'd like.

I updated all the mixture functions to include a null_ptr for the third argument cBoilT, which defaults to AMREX_REAL_MAX if no pointer is passed in. This allows for a single function to handle both calls with and without cBoilT. I tested the changes with the SingleDropEvap test in LMeX and everything works as expected. This should be good to go now.

The RealArrayLike templates are designed to work for any data type that returns amrex::Real from the [] operator. Should we be more explicit about this requirement in the code?

One strategy would to be to create a helper struct:

  // Helper trait to check if T has operator[] returning amrex::Real& or const amrex::Real&
  template <typename T>
  struct is_real_array_like {
    template <typename U>
    static auto test(U* u) -> std::integral_constant<
      bool,
      std::is_same<decltype((*u)[0]), amrex::Real&>::value ||
      std::is_same<decltype((*u)[0]), const amrex::Real&>::value>;
    template <typename>
    static auto test(...) -> std::false_type;
    static constexpr bool value = decltype(test<T>(0))::value;
  };

And then in each template include a static assert:

static_assert(is_real_array_like<RealArrayLike1>::value,
               "RealArrayLike1 must have an operator[] that returns const amrex::Real&");

This has no effect on code behavior or what can compile, but makes expectations more explicit/might increase readability of the code. But it also adds significant verbosity and can potentially add confusion rather than reduce it if the reader isn't as familiar with C++.