Add option to distribute volume according to geometric distribution

[wouterjdb]

This PR introduces the option to distribute the FlowNet model volume based on the geometrical distribution in the original model.

---

Contributor checklist

• 🎉 This PR closes Volume distribution uneven with high "flow path" density #315 and closes FOIP differences #376.
• 📜 I have broken down my PR into the following tasks:
  • Implement volume distribution method
  • Add option to choose either model volume or flownet bounding box volume (see remark @wouterjdb) (related issue Node placement in volume of original model #368)
  • Add option to distribute volume per grid cell (see remark from @olwijn) (new issue Distribute volume per cell #358)
  • Expose distribution method to user
  • Test
  • Fix removal of volume by, for example, non-reservoir tube removal. @LonnekevB Could you try to incorporate this?
  • Test again
  • Add error when users ask for a method that depends on a sim model that is not supplied.
• 🤖 I have added tests, or extended existing tests, to cover any new features or bugs fixed in this PR.
• 📖 I have considered adding a new entry in CHANGELOG.md.
• 📚 I have considered updating the documentation.

[wouterjdb]

Comparison of the distribution in the original and new distribution method:

Some observations:

• The new method shows a high-volume-ring around the Brugge case. This is correct: the original Brugge model has a large aquifer that is modeled with active gridcells. This volume is now assigned to the nearest modelled FlowNet tube....

  ❗ However, as our bulk volume estimation is coming from the hull between drilled wells I am actually assigning to little volume to the HC-bearing formation in this case. Either I can:

  • use the total volume from the original model OR
  • only distribute the volume of those cells of the original model that lie inside the hull that was used for the original volume estimation.

  What do you think @edubarrosTNO @olelod @olwijn @tayloris?

• The internal tubes in the model have a relatively low volume. This is what one would expect: in areas with a high density of tubes the volume assigned to an individual tube should be lower.

[olwijn]

Could this approach to volume distribution perhaps be taken one step further and be used to distribute the flow tube volume over the grid cells of each flow tube? If so, volumes of flow tube cells that connect to or are close to wells would get low volume (since there are many cells from other flow tubes nearby) while cells that arefar away from wells would receive a larger volume.

[wouterjdb]

Could this approach to volume distribution perhaps be taken one step further and be used to distribute the flow tube volume over the grid cells of each flow tube? If so, volumes of flow tube cells that connect to or are close to wells would get low volume (since there are many cells from other flow tubes nearby) while cells that arefar away from wells would receive a larger volume.

That is an interesting thought 👍 - and yes, I think it could be done.

[wouterjdb]

@olwijn I tried simply expanding the algorithm to a per cell setting. This works in some areas as expected (see increasing volume further away from the well node):

However, you already see some problems in the back. Because of the resolution of the original model not all FlowNet gridcells now get assigned some volume, leading to many holes in the model. Also, at the flownet well connection only one (or none, if unlucky) cell get volume assigned - so the wells are now poorly connected.

I think this is a really nice idea, but it requires more work to implement it. Therefore I suggest that I do not implement it here and now but we make an issue out of it to be taken at a later time (could be soon - be at least separate).

[olwijn]

an alternative could perhaps be to first assign volumes to flow tubes, as you have already done, and then to somehow distribute that volume over the flow tube cells based on the distance to the end points?

[wouterjdb]

an alternative could perhaps be to first assign volumes to flow tubes, as you have already done, and then to somehow distribute that volume over the flow tube cells based on the distance to the end points?

Let's continue this discussion in #358.

[olelod]

Nice work.

Just reminding you of the testing in the config_parser we discussed yesterday, and some other cosmetic changes.

The bulk volume of the FlowNet when using the Voronoi option will always be equal to the simulation model volume, right? There is no need to test or assure that? Or maybe print volumes to screen for the user to see?

[edubarrosTNO]

To add to this discussion, here are some thoughts that @olwijn and I had today:
Even if we get a good solution to distribute the pore volume within the FlowNet tubes, we might still have issues in matching the volume of oil-water-gas initially in place (i.e. we have been observing FOIP volumes pretty much off in our current results).

A possible explanation relates to the fact that we rely on initialization by equilibration in the reservoir simulator. Just like we are with this PR aiming at distributing PORV across the cells / tubes of FlowNet, we must check if the distribution of fluid volumes across tubes is also done properly, otherwise we should control the initialization of saturations within FlowNet and not using the EQUIL keyword in OPM-Flow / Eclipse.

[edubarrosTNO]

PS: the comment above is based on the fact that my tests with the code of this PR branch did not show to have any impact on the offset of FOIP volumes that we have been observing in the Norne example

[olelod]

So I'm only getting ~75% of the original volume. I think this is a result of FlowNet tubes being remove when they, for example, go through non-reservoir. To be able to keep the volume the same from the original to the flownet model the algorithm should not distribute volume to tubes that later on are deactivate (overwritten with PORV = 0).

The non-reservoir part should not be a problem, I think, since we drop those start/end points before we generate the FlowNet network. The same goes for angles. So I guess the only removal/deactivation happening after generation of the FlowNet is in the rendering of the realizations (where permx < min_permeability leads to PORV = 0). You see the same thing if you run without defining min_permeability?

[wouterjdb]

During the assignment of volume to tubes, volume is also assigned to the inactive grid cells. These cells should not be assigned volume.

Potential problem areas:
https://github.com/wouterjdb/flownet/blob/f87804345ce8531055405591115bc2045b7bb3a4/src/flownet/data/from_flow.py#L420

[wouterjdb]

During the assignment of volume to tubes, volume is also assigned to the inactive grid cells. These cells should not be assigned volume.

Potential problem areas:
https://github.com/wouterjdb/flownet/blob/f87804345ce8531055405591115bc2045b7bb3a4/src/flownet/data/from_flow.py#L420

This is now fixed. Also a correction for NTG has been added.

[wouterjdb]

Tested again:

PORV now nearly identical when the bulk volume multiplier is set to 1. The mismatch is now only due to differences in PORO; that is as expected.

[olelod]

LGTM 🚀