Moved fluid variables at time n to multifluid constitutive model #1827
Moved fluid variables at time n to multifluid constitutive model #1827francoishamon merged 6 commits intodevelopfrom
Conversation
| localIndex const numElem = m_initialTotalMassDensity.size( 0 ); | ||
| localIndex const numGauss = m_initialTotalMassDensity.size( 1 ); | ||
| integer const numPhase = m_phaseMassDensity.value.size( 2 ); | ||
| integer const numComp = m_phaseCompFraction.value.size( 3 ); |
There was a problem hiding this comment.
Some day we can get rid of these hard coded indices. 😉
| phaseDensityOld[k][q][ip] = phaseDensity.value[k][q][ip]; | ||
| phaseEnthalpyOld[k][q][ip] = phaseEnthalpy.value[k][q][ip]; | ||
| phaseInternalEnergyOld[k][q][ip] = phaseInternalEnergy.value[k][q][ip]; | ||
| for( integer ic = 0; ic < numComp; ++ic ) | ||
| { | ||
| phaseCompFractionOld[k][q][ip][ic] = phaseCompFraction.value[k][q][ip][ic]; | ||
| } |
There was a problem hiding this comment.
So we do not store the derivatives, right?
There was a problem hiding this comment.
well, for the quantities at the previous time-step we only need the value non its derivatives.
| arraySlice2d< real64 const, compflow::USD_PHASE_DC - 1 > dPhaseVolFrac_dCompDens = m_dPhaseVolFrac_dCompDens[ei]; | ||
|
|
||
| arraySlice1d< real64 const, compflow::USD_PHASE - 1 > phaseDensOld = m_phaseDensOld[ei]; | ||
| arraySlice1d< real64 const, multifluid::USD_PHASE - 2 > phaseDensOld = m_phaseDensOld[ei][0]; |
There was a problem hiding this comment.
Why do you need this extra (dummy?) dimension? (The [0] at the end).
That bothers me here and there in the code.
There was a problem hiding this comment.
It's because the second dimension contains the quadrature point index. The thing is that our flow kernels assume a single integration point since we use piece-wise constant functions for all our FV relevant quantities. We could loop over quadrature points and avoid hard-coding the value 0 but it would add an extra loop that in these kernels would not make much sense. The problem is that the same constitutive model can be used with a discretization scheme that does need that second dimension. Although, at least for now, that 's not true for fluid properties so maybe we could change the types of all those. It will make it inconsistent across fluid models though so I am not sure what's best.
This PR addresses this comment from @CusiniM. I prefer to address the comment in a separate PR mergeable before or after the thermal PR.
This PR moves the phase density, phase component fraction, phase internal energy, phase enthalpy evaluated at the previous time level (time
n) to multifluid constitutive model, and add a methodsaveConvergedStateto theMultiFluidBaseclass.The PR does not introduce numerical diffs, but requires a rebaseline. Rebaseline done in https://github.com/GEOSX/integratedTests/pull/210