Add energy balance equation to Compositional solver.

[CusiniM]

This original content of the PR has been split into multiple pieces that have been implemented separately:

• PR 1: Add a model for solid internal energy (Add solid internal energy. #1660)
• PR 2: Add the enthalpy and internal energy functions to the CO2-brine fluid model (Refactor enthalpy and internal energy for CO2 brine #1689)
• PRs 3, 4, 5: Refactor accumulation, flux, and property kernels (Implemented new kernel interface for flux #1696, Implemented new interface for accumulation and volume balance kernels #1672, and Implemented new kernel interface for compositional properties #1698)
• PR 6: Add thermal conductivity constitutive model (Implemented thermal conductivity models #1732)
• PR 7: Reduce the size of the fluid kernel wrapper (Combined multifluid derivatives to reduce fluid kernel wrapper size #1779)
• PR 8: Put everything together in a CO2BrineThermal fluid model (Activated thermal option in CO2-brine fluid model #1755)
• This PR: Add the energy balance equation to the compositional solver

This PR implements the kernel interfaces that add the thermal derivatives and assemble the energy balance (internal energy term, enthalpy flux, conduction flux).

• Unit test (finite difference derivatives)
• Integrated test (CO2-brine simulation)

Rebaseline in https://github.com/GEOSX/integratedTests/pull/213

[CusiniM]

Conduction is still missing. I see two way to add it:

1. add another stencil with it's own coefficient which would be the conductivity.
2. allow the stencil to have more than one coefficient. Basically I would modify the stencil so that it could contain weights relative to two different properties (or coefficients). We may want to modify some of the naming if we choose this path.

I personally prefer option 2 because the connections for the advective and the conductive parts are exactly the same so we would only have to loop over the connections once instead of twice.

@francoishamon @rrsettgast @klevzoff @castelletto1 opinions?

[francoishamon]

@CusiniM GitHub prevents me from selecting your name as a reviewer because you opened this PR, but it is now ready for review. I added an 2D integrated test with cold CO2 injection in brine, and I will now work on validation against another code.

I am also going to add a unit test to validate the derivatives, but I am going to refactor the unit tests testCompMultiphaseFlow and testCompMultiphaseHybrid first to avoid code duplication (in a separate PR -> this is done now).

[CusiniM]

Outstanding job @francoishamon ! It's a pretty big PR:

• we should probably organize a walk through
• we should allow you to merge asap. maintaining it up-to-date with develop is going to be painful.

[CusiniM]

is this still happening?

[francoishamon]

Yes, I really don't understand what is going on there:

• If I add only CO2BrinePhillipsThermalFluid, the code compiles and works
• If I add only CO2BrineEzrokhiThermalFluid, the code compiles and works
• If I add both, I get the following error:

[ 61%] Building CUDA object coreComponents/physicsSolvers/CMakeFiles/physicsSolvers.dir/fluidFlow/CompositionalMultiphaseBase.cpp.o                                                      
[ 63%] Building CUDA object coreComponents/physicsSolvers/CMakeFiles/physicsSolvers.dir/fluidFlow/wells/CompositionalMultiphaseWell.cpp.o                                                
[ 63%] Building CUDA object coreComponents/constitutive/CMakeFiles/constitutive.dir/fluid/PVTDriver.cpp.o                                                                                
[ 88%] Built target constitutive                                                                                                                                                         
nvcc error   : 'ptxas' died due to signal 11 (Invalid memory reference)                                                                                                                  
make[3]: *** [coreComponents/physicsSolvers/CMakeFiles/physicsSolvers.dir/build.make:115: coreComponents/physicsSolvers/CMakeFiles/physicsSolvers.dir/fluidFlow/CompositionalMultiphaseBase.cpp.o] Error 11 

This is not a blocking problem for me, but I don't understand why it does not compile with the two models activated.

[CusiniM]

why twice? I m guessing it's just to pass smt to the function coz thta should be the derivative wrt to pressure.

[francoishamon]

For thermal conductivity, I implemented what the two of us discussed some time ago: the dependence of thermal conductivity on saturation and porosity is treated explicitly to make sure that we can easily reuse the computeWeights function. So yes you are right, I pass m_thermalConductivity twice because I need to pass something, but I don't have anything else to pass. I added more explanations in the code.

In a future PR, we could modify the computeWeights function to accommodate explicit coefficients (just pass the coefficient, and return the transmissibility). That would be useful for thermal transmissibility and also for diffusion transmissibility that would likely be explicit/lagged in iteration as well.

[klevzoff]

Looks great!

[klevzoff]

I wonder if it's too late at this point to think about changing our (flow) formulations from oldField, deltaField to oldField, newField. So much extra code can be eliminated...
(This is obviously not a comment on this PR, just thinking out loud)

[francoishamon]

I think it would be great to try, if everyone agrees. I can post an issue to get feedback and try after the PR is merged.

[klevzoff]

I have an issue with the length of these namespace names (and it's only got worse now). I don't have a specific suggestion for this PR, but intuitively it seems that having a more nested namespace structure might be one way to deal with it, e.g. ::geosx::flow::multiphase::kernels::isothermal or ::geosx::kernels::flow::multiphase::isothermal (we'd have to think about the order). The benefit is being able to reference any level of this hierarchy by an explicit local alias or a using directive, and thus reduce typing.