feat: Adaptive multilinear interpolation for OBL solver

[av-novikov]

This PR adds interfaces for embedding of Python function into C++ code, adds multilinear adaptive interpolation with given exact evaluator from Python and adds the support of both static and adaptive interpolation in ReactiveCompositionalMultiphaseOBLKernels. Ultimate goal is to run simulation similar to open-darts from a corresponding (part of) model given from Python.

• fix assembly in ReactiveCompositionalMultiphaseOBLKernels
• multilinear adaptive interpolation
• interfaces to call Python function from C++ (from interpolator)
• convergence test for multilinear adaptive interpolation
• generalize input of OBL fluid physics for static and adaptive interpolation
• pass Python-based OBL operators evaluator to solver
• test model comparing simulations under static and adaptive interpolation
• use LvArray/src/python/PyFunc for embedding Python function to C++
• deduce access level in LvArray::python::PyArrayWrapper to support MODIFIABLE arguments: LvArray: PR 336
• unify casting-to-numpy interfaces between GEOS and open-darts: open-darts: MR 138
• Python interfaces to GEOS from Makutu repository: geosPythonPackages: PR 44

FAQ:

Q: Why do we use __uint128_t ?
A: We need to count nodes and hypercubes in multidimensional state space. Even with 300 points per axis in 8-dim space (e.g. 8-component fluid), the number of points (300^8) surpasses the maximum of 64-bit integer. Moreover, single __uint128_t key type simplifies hashing points and hypercubes in std::unordered_map storage.

Q: Do we duplicate the storage of points?
A: Yes, because we minimize memory accesses by excessive, but consecutive storage.

[sframba]

Thanks @av-novikov for this PR! I think that the python scripts shouldn't go in a subfolder of compositionalMultiphaseFlow, but in a higher-level folder (maybe in a new folder scripts/pygeos?). We'll be adding the remaining Makutu scripts in the (possbly near) future and they'll be used for geophysics and potentially geomechanics workflows. All these base python classes and utilities need to be common to these other solvers as well. @CusiniM @rrsettgast what's your opinion?

[av-novikov]

Thanks @av-novikov for this PR! I think that the python scripts shouldn't go in a subfolder of compositionalMultiphaseFlow, but in a higher-level folder (maybe in a new folder scripts/pygeos?). We'll be adding the remaining Makutu scripts in the (possbly near) future and they'll be used for geophysics and potentially geomechanics workflows. All these base python classes and utilities need to be common to these other solvers as well. @CusiniM @rrsettgast what's your opinion?

Thank you @sframba !
I moved them into scripts/pygeosx.

[CusiniM]

Thanks @av-novikov for this PR! I think that the python scripts shouldn't go in a subfolder of compositionalMultiphaseFlow, but in a higher-level folder (maybe in a new folder scripts/pygeos?). We'll be adding the remaining Makutu scripts in the (possbly near) future and they'll be used for geophysics and potentially geomechanics workflows. All these base python classes and utilities need to be common to these other solvers as well. @CusiniM @rrsettgast what's your opinion?

I think we should put all of these scripts in the python tools repository.

[av-novikov]

Thanks @av-novikov for this PR! I think that the python scripts shouldn't go in a subfolder of compositionalMultiphaseFlow, but in a higher-level folder (maybe in a new folder scripts/pygeos?). We'll be adding the remaining Makutu scripts in the (possbly near) future and they'll be used for geophysics and potentially geomechanics workflows. All these base python classes and utilities need to be common to these other solvers as well. @CusiniM @rrsettgast what's your opinion?

I think we should put all of these scripts in the python tools repository.

@CusiniM @sframba Should I place interfaces in different folders in geosPythonPackages repo according to their purposes, e.g. input -> geos-xml-tools, mesh -> geos-mesh ? Or should i place everything to the same folder, e.g. makutu-utilities?

[Bubusch]

Thanks @av-novikov for this PR! I think that the python scripts shouldn't go in a subfolder of compositionalMultiphaseFlow, but in a higher-level folder (maybe in a new folder scripts/pygeos?). We'll be adding the remaining Makutu scripts in the (possbly near) future and they'll be used for geophysics and potentially geomechanics workflows. All these base python classes and utilities need to be common to these other solvers as well. @CusiniM @rrsettgast what's your opinion?

I think we should put all of these scripts in the python tools repository.

@CusiniM @sframba Should I place interfaces in different folders in geosPythonPackages repo according to their purposes, e.g. input -> geos-xml-tools, mesh -> geos-mesh ? Or should i place everything to the same folder, e.g. makutu-utilities?

I think we should keep them in the same package/folder in geosPythonPackages repo. That way we just have to do one pip install to get the python package up and running. Two ways we could go for:

• create a new package called pygeos-handler which indicates that the package is designed to manipulate GEOS (inputs, solvers, etc.).
• reuse the existing package pygeos-tools which is a more generic tooling package for interacting with pygeos

@CusiniM @sframba any preference/suggestion ?

[av-novikov]

Dear @Bubusch @sframba @CusiniM
Python interfaces are going to be placed in pygeos-tools in geosPythonPackages: PR 44.
Hope it works to you.