Split parser module into lightweight package

[juliohm]

Hi @moyner , it was nice chatting again!

I believe we can advance more quickly with the integration of our software stacks if the parser module in this repository is moved to a separate lightweight package, without Jutul-specific dependencies. It could be called PetrelIO.jl, EclipseIO.jl, or any other name that is appropriate for the file format.

We could then take this new package as a dependency in GeoIO.jl to post-process the parsed data into a structure that is compatible with GeoStats.jl while GeoEnergyIO.jl can post-process the same parsed data into a structure that is compatible with JutulDarcy.jl.

Can we act on this plan? How can I help?

[moyner]

Hi @juliohm! Glad you're interested in coupling these things together. I'd prefer not making additional packages to manage, but I think the grid processing could be moved to a Pkg extension for Jutul since Julia 1.10 is now LTS. There is also some use of Jutul.jl for units but that it is easily solvable by copying over some of the definitions.

My question is if you would want to do the parsing in GeoIO to a "processed" grid (i.e. make a grid from corner points where all faces across faults are properly split based on intersections, pinched cells are removed, etc) or if you want to reuse the already implemented processing and put that in the new structure? The former is straightforward, the latter may require some thinking about how things are to be organized.

[juliohm]

What I have in mind is something like PlyIO.jl: a package that parses mesh data from the PLY format into a Julia dict-like structure with all the information necessary to build an unstructured mesh (i.e., vertices and connectivity list). You can find an example of how it is used in GeoIO.jl here: https://github.com/JuliaEarth/GeoIO.jl/blob/master/src/extra/ply.jl

The processing steps that produce the final connectivity list from faults, etc seem specific to the file format. Ideally, these steps would be encapsulated in the lightweight package we are discussing here. From your last comment, I understand that this lightweight package will be a future release of GeoEnergyIO.jl without Jutul-specific dependencies. Is that correct?

It should be straightforward to take GeoEnergyIO.jl as a dependency in GeoIO.jl in that case.

[moyner]

The "fully processed" mesh is unfortunately quite closely tied to the Jutul grid structure at the moment. The partially processed structure (pillars and connectivity, but not fully formed faces) is not tied to Jutul. I will see how feasible it is to detangle it from the mesh itself.

Short term an option is to make GeoEnergyIO a weak dependency in GeoIO to avoid pulling in Jutul for users who are not interested in corner point grids. I could make an interface that dumps the grid structure into a Dict suitable for generic processing and then if it works I can switch to the same format internally.

[juliohm]

I will see how feasible it is to detangle it from the mesh itself.

Thank you @moyner , that is the best option. If you can disentangle the file format from the specific data structure adopted by Jutul.jl, it will open the door to much tighter integration.

Short term an option is to make GeoEnergyIO a weak dependency in GeoIO to avoid pulling in Jutul for users who are not interested in corner point grids.

Unfortunately we can't rely on extensions in GeoIO.jl as they break the intended workflow. We have pre-compile statements for all supported file formats so that users don't pay the penalty during standard usage of the package.