refactor: Add component selector for fluid models

[dkachuma]

In IsothermalCompositionalMultiphaseFVMKernels.hpp:2127-2157 and ThermalCompositionalMultiphaseFVMKernels.hpp:1397-1432, we have calls of the form

constitutive::constitutiveUpdatePassThru( fluidBase, [&]( auto & fluid )
{
  using FluidType = TYPEOFREF( fluid );
  // ...
  isothermalCompositionalMultiphaseBaseKernels::internal::kernelLaunchSelectorCompSwitch( numComps, [&]( auto NC )
  {
    integer constexpr NUM_COMP = NC();

    // ...
    using kernelType = DirichletFaceBasedAssemblyKernel< NUM_COMP, NUM_DOF, typename FluidType::KernelWrapper >;
    
    // ...
  } );
} );

This expands over all available fluid types and within each expansion, we further expand over all possible numbers of components. The possible number of components is currently set to be from 1 to 5. However, not all fluid types support all these component numbers. For example the CO2BrineFluid models support only 2 components. As such we end up here with unnecessary expansions. The end result of all these expansions is to make the CompositionalMultiphaseFVM class extremely large to compile especially for CUDA builds. This is so bad that some of the fluid models have been commented out in MultiFluidSelector.hpp:39-58 just to be able to compile on GHA.

This PR tries to reduce the number of combinations by explicitly listing, for each fluid type, the number of components that it allows. The expansion is a combination of the fluid model type and number of components. Furthermore, not all fluid models support thermal simulations. So the thermal kernels are expanded only over those models that support thermal simulations.

Some other changes

• Each fluid model class is tagged with a static boolean isThermalType() method.
• Some validation of the user input has been added to ensure that the number of components listed in MultiFluidSelector are honoured.
• Added a couple of integrated tests to include the constant pressure boundary condition.

[codecov]

Codecov Report

Attention: Patch coverage is 71.68142% with 32 lines in your changes missing coverage. Please review.

Project coverage is 55.83%. Comparing base (18db014) to head (cb97a03).
Report is 85 commits behind head on develop.

Files with missing lines	Patch %	Lines
...dFlow/ThermalCompositionalMultiphaseFVMKernels.hpp	0.00%	17 Missing ⚠️
...ow/IsothermalCompositionalMultiphaseFVMKernels.hpp	0.00%	14 Missing ⚠️
...uid/compositional/CompositionalMultiphaseFluid.hpp	0.00%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #3213      +/-   ##
===========================================
+ Coverage    55.71%   55.83%   +0.11%     
===========================================
  Files         1041     1042       +1     
  Lines        88575    88652      +77     
===========================================
+ Hits         49353    49501     +148     
+ Misses       39222    39151      -71     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[CusiniM]

I think that you can do something like this to avoid specifying each number:

template<integer Begin, integer End, integer... Is>
struct create_integer_sequence_impl
    :  create_integer_sequence_impl<Begin, End - 1, End - 1, Is...> {};

template<integer Begin, Integer... Is>
struct create_integer_sequence_impl<Begin, Begin, Is...>
{
    using type = camp::int_seq<integer, Is...>;
};

and then use it like:

template<>
struct Components< CompositionalTwoPhaseConstantViscosity >
{
using type = typename create_integer_sequence_impl<2, 5>::type;
}

and maybe I would define the value in the max and min value of components as constexpr in each fluid model itself and have something like:

template<typename FLUID_TYPE>
struct Components< >
{
using type = typename create_integer_sequence_impl<FLUID_TYPE::min_n_components, FLUID_TYPE::max_n_components>::type;
}

@wrtobin thoughts?

[wrtobin]

IIRC camp has builtin support for range generation... but looking at it it seems like they only support [0...N) generation.
So yeah we should be able to avoid explicitly listing all numbers unless there is a compelling reason to do so.

I think its typically logical to add a third component for the step size which defaults to 1, so we can e.g. count by 2's etc, but that is just as a general mechanism.

[CusiniM]

if we make it even more generic it could probably even go in common or in datatypes. Honestly, it should probably live directly in camp. I also had a look in camp and I didn't see exactly what we need.

In any case I don't see a real reason for explicitly listing all numbers, so I think we should do something like what I wrote above but @dkachuma feel free to also the step size and move it somewhere else.

[dkachuma]

I particularly like the idea of min/max component with each fluid. Let me see how I can fit this in.

[CusiniM]

nice! We did have something like this already.

[MelReyCG]

I approve the common/TypeDispatch part.

Just a side question, what do you think of the name isThermalType() to keep the isX() naming with the thermal() static method?