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]

I suggest we set default values here, and then remove these parameters from the integrated test XMLs unless they differ from the default. It looks like they all use the same set of values.

[joshua-white]

Ditto. Could set good default values. Users may not know how to set these params properly.

[joshua-white]

Suggest we set default values and remove these coefficients wherever possible from XMLs.

[joshua-white]

I think this check could be handled by the BrineFluidParameters object itself. We could centralize all checking of parameter physicality there?

[joshua-white]

Not specific to this PR, but this is such a common user error I wonder if we should revisit the idea that it is not our responsibility to check for out of bounds and warn the user. Would be nice if this was a flaggable check. We could probably even just check the initial formation pressure range and any BHP conditions flagged in the XML and say someone is likely to exceed bounds, without doing range checking at every table call mid-simulation.

[joshua-white]

Or once a timestep compute the (max / min) (pressure / temp) over the whole domain and see if those values are in bounds for the table.

[joshua-white]

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