feat: Move CO2-Brine parameters to xml

[dkachuma]

This PR removes the parameter files used for CO2-Brine model input. This is replaced by direct xml entries. This is a breaking change in terms of user interaction requiring changes to input models. This is evidenced by the extensive changes required in the geos integrated tests.

The key change is the removal of the two fields phasePVTParaFiles and flashModelParaFile on the CO2BrineFluid models. The information that was in these files is now required within the xml itself. This includes:

• Pressure and temperature table ranges. Generally these models involve creation of tables internally and the user was expected to enter the points for these tables by specifying a min, max and step for pressure and temperature. Now the pressureCoordinates captures the range while the pressureInterval captures the step and similarly for temperature. The new formulation is different from the old in that
  • All properties have the same pressure and temperature discretisation points whereas the old setup allowed different points for the different properties (flash, density, viscosity).
  • The new setup does not assume equally spaced points. The user can explicitly give the list of pressures in pressureCoordinates and ignore pressureInterval. This is useful in some cases where a log space might be more appropriate.
• The salinity with a default of 0.
• The density and viscosity Ezrokhi coefficients. These can be captured with ezrokhiDensityCoefficients and ezrokhiViscosityCoefficients. These default to 0 if not specified.
• The solubility model can now be explicitly defined with choices between (DuanSun (default), SpycherPruess and Tables). The table formulation works in conjunction with the solubilityTables field in which the user provides (externally generated) solubility tables directly.

The implementation involves creation of the BrineFluidParameters object to contain all the parameters. This is then passed around when creating PVT models instead of lists of strings.

The CO2-Brine documentation has been updated to reflect not only the changes but also to include all previously developed features that had not been documented.

Changes in results:

• The biggest change is the use of common points for all tables. Some of the examples were using different table ranges for the different properties. This has resulted in reasonable changes in the results now that a common set of points and ranges is used.

Example change:

    <CO2BrineEzrokhiFluid
      name="fluid"
      phaseNames="{ gas, water }"
      componentNames="{ co2, water }"
      componentMolarWeight="{ 44e-3, 18e-3 }"
      phasePVTParaFiles="{ tables/pvtgas.txt, tables/pvtliquid_ez.txt }"
      flashModelParaFile="tables/co2flash.txt" />

    <CO2BrineEzrokhiFluid
      name="fluid"
      phaseNames="{ gas, water }"
      componentNames="{ co2, water }"
      componentMolarWeight="{ 44e-3, 18e-3 }"
      pressureCoordinates="{1.0e5, 6e7}"
      pressureInterval="1e5"
      temperatureCoordinates="{283.15, 393.5}"
      temperatureInterval="5"
      salinity="1.901285269"
      ezrokhiDensityCoefficients="{0.1033, -2.2991e-5, -2.3658e-6}"
      ezrokhiViscosityCoefficients="{0, 0, 0}" />

Since this is a breaking change, detailed migration instructions are posted at #4022

[MelReyCG]

This is really a good thing. This will also allow to simply unit tests.
Will the previous behaviour with external tables be kept for backward compatibility? Or is it possible to include a documentation like "How to convert PVT parameters files to the new PVT settings."?

[dkachuma]

Will the previous behaviour with external tables be kept for backward compatibility?

No. This is a breaking change. The idea is to add an issue describing how to change the parameters.

[joshua-white]

Looks great. Just a few comments regarding providing default values and making sure we do good parameter consistency checking when possible.

[dkachuma]

Baseline updates

1. Input Format Changes (No Numerical Differences)

The new implementation introduced changes to the input format. For most of the affected cases, this resulted in baseline diffs solely due to this. There are actually no numerical differences.

2. PVT Consistency Fixes (testPVT cases)

The testPVT cases exhibited similar diffs because they required updates to resolve inconsistencies in the original test definitions:

• Salinity Consistency: The original cases had inconsistent salinity values between the flash settings (salinity=0) and brine properties (salinity=1). The update ensures that only a single, consistent salinity input (salinity=1) is used across all testPVT cases.

• Temperature Range Consistency: There was a problem with inconsistent temperature ranges, where some tables had a maximum temperature of 350 while others had 460. All testPVT cases now uniformly use a maximum temperature of 460.

3. Table Evaluation Variations

The class09_pb3_smoke_3d cases show small numerical changes. These differences are consistent with expected variations in the table evaluation caused by kinks in the tables. The changes are minor and within acceptable tolerances.

1. Input Format Changes (No Numerical Differences)
	co2_hybrid_1d_01, co2_hybrid_1d_02, co2_hybrid_1d_03, co2_flux_3d_01, co2_flux_3d_08, co2_flux_3d_27, initialization_2phase_01, initialization_2phase_02, initialization_2phase_no_cappres_01, initialization_2phase_no_cappres_02, staircase_co2_wells_3d_01, staircase_co2_wells_3d_08, staircase_co2_wells_hybrid_3d_01, staircase_co2_wells_hybrid_3d_08, isothm_mass_inj_table_01, isothm_mass_inj_table_02, isothm_vol_inj_table_01, isothm_vol_inj_table_02, staged_close_perf_1_01, staged_close_perf_1_04, staged_close_perf_2_01, staged_close_perf_2_04, staged_open_perf_1_01, staged_open_perf_1_04, staged_open_perf_2_01, staged_open_perf_2_04, PoroElastic_staircase_co2_3d_fim_01, PoroElastic_staircase_co2_3d_fim_04, PoroElastic_staircase_co2_3d_sequential_01, PoroElastic_staircase_co2_3d_sequential_04, PoroElastic_hybridHexPrism_co2_fim_3d_01, PoroElastic_hybridHexPrism_co2_fim_3d_04, PoroElastic_hybridHexPrism_co2_sequential_3d_01, PoroElastic_hybridHexPrism_co2_sequential_3d_04, co2_thermal_2d_01, co2_thermal_2d_04, ThermoPoroElastic_staircase_co2_smoke_01, ThermoPoroElastic_staircase_co2_smoke_04, thermalLeakyWell_smoke_3d_01, thermalLeakyWell_smoke_3d_04, co2_2d_plume_Z_01, co2_2d_plume_Z_04, grav_seg_drain_Z_01, grav_seg_drain_Z_02, ALM_multiphasePoromechanics_curvedFrac_smoke_01, ALM_multiphasePoromechanics_curvedFrac_smoke_04, multiphasePoromechanics_FaultModel_smoke_01, multiphasePoromechanics_FaultModel_smoke_04, multiphasePoromechanics_FaultModel_well_fim_smoke_01, multiphasePoromechanics_FaultModel_well_fim_smoke_04, multiphasePoromechanics_FaultModel_well_seq_smoke_01, multiphasePoromechanics_FaultModel_well_seq_smoke_04[cite: 1]
2. PVT Consistency Fixes
	testPVT_01, testPVT_CO2Brine_01, testPVT_CO2BrineTables_01, testPVT_docExample_01[cite: 1]
3. Table Evaluation Variations
	class09_pb3_smoke_3d_01, class09_pb3_smoke_3d_08, co2_flux_dirichlet_01, co2_flux_dirichlet_06[cite: 1]

[OmarDuran]

Perhaps this should be viewKeyStruct::pressureCoordinatesString() instead of viewKeyStruct::pressureIntervalString()?

[dkachuma]

You are correct.

[OmarDuran]

Perhaps this should be viewKeyStruct:: temperatureIntervalString() instead of viewKeyStruct:: temperatureCoordinatesString()?

[OmarDuran]

Perhaps it should be m_waterCompressibility

[dkachuma]

I have actually added both the value and the field name.

[OmarDuran]

Perhaps it should be m_tolerance

[OmarDuran]

Perhaps it should be m_salinity

[OmarDuran]

perhaps this should be maximumTemperature?

[OmarDuran]

Thank you, @dkachuma, this makes it much easier to set up compositional simulations.