Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transmissibility output #3091

Open
wants to merge 32 commits into
base: develop
Choose a base branch
from
Open

Conversation

MelReyCG
Copy link
Contributor

@MelReyCG MelReyCG commented Apr 24, 2024

This PR aims to add a new component: the StencilOutput, that allow to add a CellToCellOutput task node in the xml to output ConnectionData (global id pairs, transmissibilities).

For now, by using the writeCSV="1" attribute, the CellToCellOutput will output this data in a CSV. Here is an exemple:

  • XML excerpt
  <Solvers gravityVector="{0.0, 0.0, 0.0}">
    <SinglePhaseFVM
      name="singlePhaseFlowSolver"
      […]
    </SinglePhaseFVM>
  </Solvers>

  <Tasks>
    <CellToCellOutput
      name="stencilOutput"
      flowSolverName="singlePhaseFlowSolver"
      writeCSV="1"
      logLevel="1" />
  </Tasks>

  <Events maxTime="10.0">
    <SoloEvent
      name="stencilOutputEvent"
      targetCycle="1"
      target="/Tasks/stencilOutput" />
  </Events>
  • First 10 lines of the generated CSV
time [s] , A global id , B global id , A transmissibility [(Pa*s*rm3/s)/Pa] , B transmissibility [(Pa*s*rm3/s)/Pa]
       4 ,           0 ,        2715 , 7.55463e-18                          , -7.55463e-18                        
       4 ,           0 ,       47546 , 8.06167e-18                          , -8.06167e-18                        
       4 ,           0 ,      134459 , 6.63826e-18                          , -6.63826e-18                        
       4 ,           0 ,      165202 , 7.78139e-18                          , -7.78139e-18                        
       4 ,           1 ,        4642 , 1.83325e-17                          , -1.83325e-17                        
       4 ,           1 ,       53907 , 1.76737e-17                          , -1.76737e-17                        
       4 ,           1 ,      184341 , 1.81705e-17                          , -1.81705e-17                        
       4 ,           2 ,        5459 , 1.7414e-17                           , -1.7414e-17                         
       4 ,           2 ,       63907 , 1.86145e-17                          , -1.86145e-17                        
       4 ,           2 ,      177257 , 1.86145e-17                          , -1.86145e-17                        

(the CSV has been aligned here for readability)

@MelReyCG MelReyCG self-assigned this Apr 24, 2024
@MelReyCG MelReyCG added the type: feature New feature or request label Apr 24, 2024
outputFile << time << ","
<< conn.globalId[0] << ","
<< conn.globalId[1] << ","
<< conn.transmissibility[0] << ","
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure it makes much sense to print the same transmissibility value twice but it's ok, not a big deal

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it will be more useful to output two half-transmissibilities.

FiniteVolumeManager const & fvManager = numericalMethodManager.getFiniteVolumeManager();
FluxApproximationBase const & fluxApprox = fvManager.getFluxApproximation( m_solver->getDiscretizationName() );

fluxApprox.forStencils< CellElementStencilTPFA >( mesh, [&]( auto const & stencil )
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you please check if all that will work for https://github.com/GEOS-DEV/GEOS/blob/develop/inputFiles/compositionalMultiphaseFlow/co2_hybrid_1d.xml ?
not sure hybrid discretization has the same things as TPFA

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose the key here is that fvManager.getFluxApproximation( m_solver->getDiscretizationName() ); might return null if the solver doesn't have a flux approximation. So I would add a validator (postProcessInput()) to the solverName field of this to ensure that the solver provided has the appropriate flux approximation.

FiniteVolumeManager const & fvManager = numericalMethodManager.getFiniteVolumeManager();
FluxApproximationBase const & fluxApprox = fvManager.getFluxApproximation( m_solver->getDiscretizationName() );

fluxApprox.forStencils< CellElementStencilTPFA >( mesh, [&]( auto const & stencil )
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose the key here is that fvManager.getFluxApproximation( m_solver->getDiscretizationName() ); might return null if the solver doesn't have a flux approximation. So I would add a validator (postProcessInput()) to the solverName field of this to ensure that the solver provided has the appropriate flux approximation.

Copy link
Collaborator

@CusiniM CusiniM left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that we are trying to only write a file for rank 0 but I don't see when you gather all stencil data there? This would only work for small cases....
In any case, why not using the timehistory and writing in a parallel format instead? @wrtobin opinions?

Besides debugging I don't really see why someone would want to write out transmissibilities.

Point is to allow to do an HDF output, and remove the CSV one.
…end.

Point is to solve a bug where the StencilDataCollection buffer size are not known for the HDF chunk sizes.
Copy link

codecov bot commented Jun 13, 2024

Codecov Report

Attention: Patch coverage is 11.53846% with 138 lines in your changes missing coverage. Please review.

Project coverage is 55.62%. Comparing base (f91800b) to head (c5df35b).

Files Patch % Lines
...physicsSolvers/fluidFlow/StencilDataCollection.cpp 0.00% 87 Missing ⚠️
src/coreComponents/common/Units.hpp 14.58% 41 Missing ⚠️
...physicsSolvers/fluidFlow/StencilDataCollection.hpp 10.00% 9 Missing ⚠️
...vers/multiphysics/CoupledReservoirAndWellsBase.hpp 0.00% 1 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #3091      +/-   ##
===========================================
- Coverage    55.69%   55.62%   -0.07%     
===========================================
  Files         1032     1034       +2     
  Lines        87739    87841     +102     
===========================================
+ Hits         48863    48864       +1     
- Misses       38876    38977     +101     

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

@MelReyCG
Copy link
Contributor Author

MelReyCG commented Jul 2, 2024

@CusiniM

It seems that we are trying to only write a file for rank 0 but I don't see when you gather all stencil data there? This would only work for small cases.... In any case, why not using the timehistory and writing in a parallel format instead? @wrtobin opinions?

Besides debugging I don't really see why someone would want to write out transmissibilities.

This proposal is not completely finished, but it now takes into account all connections within all ranks. The CellToCellDataCollection now can be used for bigger cases.

To explain why we want to output this data, the goal is to compare the transmissibility data from other simulator(s), in order to understand the differences between the simulations.

@rrsettgast
Copy link
Member

@MelReyCG Can you resolve conflicts?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you remove these? Coz they are also written in French.

FiniteVolumeManager const & fvManager = numericalMethodManager.getFiniteVolumeManager();
FluxApproximationBase const & fluxApprox = fvManager.getFluxApproximation( m_solver->getDiscretizationName() );

fluxApprox.forStencils< CellElementStencilTPFA >( mesh, [&]( auto const & stencil )
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe supporting the output for all the other stencils could be useful too. I m thinking of debugging of fractured problems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants