Create compositional multiphase fluid #2769
Conversation
…dkachuma/compositional-fluid
| } | ||
|
|
||
| // 2. Compute phase fractions and phase component fractions | ||
| m_flash.compute( pressure, |
There was a problem hiding this comment.
it overall looks ok, following current GEOS practices for fluids
but i still do not fully understand why flash compute and phase computes can't become separate kernels?
would simplify the code imho and avoid zillions of template functions
@rrsettgast @klevzoff @francoishamon need you opinion please
There was a problem hiding this comment.
maybe i could try to implement what i am talking about for a simple fluid to see how it would look...
There was a problem hiding this comment.
Yes, a dummy design would be helpful. For the moment I suggest we keep this PR moving forward so we can get baselines in the code, but we can always revisit the design.
There was a problem hiding this comment.
The original design was influenced primarily by PVTPackage which provided a single entry point for all calculations. This does not need to be the case any more.
However a secondary reason concerns performance, especially on GPUs. Split kernel design introduces additional latency and requires input data to be brought from DRAM into SM registers multiple times. Fused kernels are typically much more efficient in that sense and also allow intermediate computation results can be reused in-kernel without storing them into memory. This may be less of a concern if 90% of simulation time is taken by the linear solver.
In addition, our current approach to running these kernels is to have the solver do it rather than the model. This allows fluid compute to be fused into another kernel with a single level of model dispatch, as is the case with Dirichlet boundary conditions in CompositionalMultiphaseFVM, which avoids the need to allocate memory to store all fluid properties at those BC locations. I don't see an easy way to do this with split kernel approach, but I'm open to experiments.
There was a problem hiding this comment.
I will presently carry on as is and welcome ideas on how to rework this.
| { | ||
| string const expectedWaterPhaseNames[] = { "water" }; | ||
| return PVTProps::PVTFunctionHelpers::findName( m_phaseNames, expectedWaterPhaseNames, viewKeyStruct::phaseNamesString() ); | ||
| return -1; |
There was a problem hiding this comment.
Is there a plan yet for how we handle the water phase index in the new design?
There was a problem hiding this comment.
Currently I'm not sure how the phaseNames input fits into all this. I haven't put this in since my current implementations are 2-phase with liquid and vapour. Once I start doing implementations with water, this will have to be worked out.
src/coreComponents/constitutive/fluid/multifluid/compositional/CompositionalMultiphaseFluid.cpp
Show resolved
Hide resolved
src/coreComponents/constitutive/fluid/multifluid/compositional/CompositionalMultiphaseFluid.cpp
Outdated
Show resolved
Hide resolved
...mponents/constitutive/fluid/multifluid/compositional/CompositionalMultiphaseFluidUpdates.hpp
Outdated
Show resolved
Hide resolved
...mponents/constitutive/fluid/multifluid/compositional/CompositionalMultiphaseFluidUpdates.hpp
Outdated
Show resolved
Hide resolved
|
Outstanding issues:
|
joshua-white
added
ci: run CUDA builds
|
I went ahead and added the "ready to be merged" flag. I assume no rebaselines are required. |
No. Shouldn't require rebaselines. |
most probably it does require rebaseline because you changed registerWrapper in some places and registered something in catalog? |
But these are new types which shouldn't exist yet in any of the tests. |
The situation will be obvious when we try to run the integrated tests :-) @dkachuma, can you (have you) run on Quartz and Lassen? We've had a few instances recently of PRs getting in without confirming tests. |
I have run the tests locally on pecan. But as of yet I don't have access to Quartz or Lassen. |
Tests pass on Quartz. New baselines are not needed. |
* Create copy of CompositionalMultiphaseFluid * Create another copy of CompositionalMultiphaseFluid * Rename files * Add a parallel CompositionalMultiphaseFluid * Rename catalog objects * Add some reasonable non-zero values for properties * Create template parameterised Compositional multiphase fluid * Create phase models * Replace template parameter pack with individual parameters * Naming conventions * Rename compositional density * Fix unit test * Remove catalog functions * Remove impl file * Rename CompositionalMultiphaseFluidPVT to CompositionalMultiphaseFluidPVTPackage * Remove superfluous comment * Pass density to viscosity kernel * Lump component molecular weight and component names into ComponentProperties * Implement water phase index * Remove third phase from kernel wrapper * Remove unused variable * Remove component properties from individual models * Remove unused variables * Updating schema
CompositionalMultiphaseFluidPVTDriverand check that the hard-coded values are output. Follow up PRs will link the actual static calculation kernels.PVTPackagetoCompositionalMultiphaseFluidPVTPackageCompositonalTwoPhaseFluidSoaveRedlichKwongandCompositonalTwoPhaseFluidPengRobinsonequationsOfStateinput. This is implied from the element tag.componentCriticalVolumewhich is optional. When not supplied this is calculated using Ihmels' (2010) correlation.