BrineFluidProperties + SimpleFluidProperties: density always wrong in unsaturated flow

[josebastiase]

Hi,

I am modelling variably-saturated NaCl transport with PorousFlow. Water97FluidProperties crashes at negative liquid pressures (suction) via inRegion(), so I need to replace it with SimpleFluidProperties as the water backend inside BrineFluidProperties. Whatever I try, the reported density is always 939 kg/m³, which is exactly the density that the default SimpleFluidProperties produces at 293 K with its default parameters (density0=1000, thermal_expansion=2.14e-4). My specified values are being ignored.

What I tried

1. Modifying BrineFluidProperties.C directly. I tried registering a SimpleFluidProperties sub-object inside the constructor via addUserObject, setting custom params with params.set("density0") before registering. Still 939. I believe addUserObject silently no-ops if the name is already in the warehouse and returns the stale default object, so our custom params are discarded.

2. Passing an explicit water_fp. After removing the fluidName() != "water" guard (which rejects SimpleFluidProperties because it returns "simple_fluid", not "water"):

[simple_water]
  type = SimpleFluidProperties
  density0 = 998.0
  thermal_expansion = 0.0
  bulk_modulus = 2.1e15
[]

[brine]
  type = BrineFluidProperties
  water_fp = simple_water
[]

What I think is happening

Two issues, possibly both active at once:

1. The Driesner virtual-temperature mapping overrides whatever SimpleFluidProperties would return

rho_from_p_T_X does not call _water_fp->rho_from_p_T(p, T) directly — it first computes a virtual temperature Tv from the Driesner NaCl correlation, then calls rho_from_p_T(p, Tv). This mapping was designed for Water97's internal reference state. With SimpleFluidProperties (rho = density0 * exp(p/K - alpha*T)), feeding Tv instead of the real T produces garbage, regardless of what density0 is set to.

2. addUserObject silently returns a stale warehouse object

When constructing the sub-object internally, addUserObject appears to skip registration if the name already exists, and getUserObject returns the pre-existing default-param object. The result is always the default SimpleFluidProperties at 293 K → 939 kg/m³, regardless of what we pass.

I have attached a modified BrineFluidProperties.C that bypasses both issues: the Driesner virtual-temperature mappings for rho, h, and cp are removed (all three now evaluate at the real (p, T)), negative pressures are clamped to 1 Pa before calling SimpleFluidProperties, and the fluidName() guard is removed. I still get 939 with this file....

https://github.com/josebastiase/issues/tree/main/brine_issue

[GiudGiud]

Hello

how are you checking the density? With an auxkernel?

When constructing the sub-object internally, addUserObject appears to skip registration if the name already exists, and getUserObject returns the pre-existing default-param object. The result is always the default SimpleFluidProperties at 293 K → 939 kg/m³, regardless of what we pass.

There is an error in the warehouse in the problem tries to add the exact same object twice.
Are you compiled in devel mode? This error is missed in opt since it'd be a developer error if that happened

[josebastiase]

I figured it out! The fix turned out to be straightforward once we found the right place to look...

The root cause was that both BrineFluidProperties.C and PorousFlowBrine.C have a fluidName() != "water" guard that rejects any water backend that isn't Water97. SimpleFluidProperties returns "simple_fluid" from fluidName(), so it was always rejected.

Removing those two checks in both files and passing water_fp = simple_water on the [Materials]/[brine] block (not on [FluidProperties] as I was doing) fixed it immediately.

I was also confused for a long time because we were declaring the water_fp on the [FluidProperties]/[brine] block, not realising that PorousFlowBrine constructs its own internal BrineFluidProperties so mystandalone [FluidProperties] block was never connected to anything.

Thanks for the hint about the warehouse duplicate object error in devel mode...that pointed the right direction