Question about converting a grdecl grid to vtk

[Aliznia]

I have a grid for the Sleipner field, which I obtained from the CO2 DataShare portal: https://co2datashare.org/dataset/sleipner-2019-benchmark-model. I'm wondering how to convert it to VTK format. There are several Python scripts available on GitHub. The grid doesn't have any non-conformities as far as I know; it's simple, like a layer cake model, and it has the porosity and permeability properties.

[untereiner]

I don’t understand the question. If you found scripts, just try the convert and test with paraview the results. The can view you grdecl with resinsight.

I am interested of the results of you investigations

[herve-gross]

@dkachuma can you help?

[Aliznia]

I'm using the following code: https://github.com/BinWang0213/PyGRDECL
It can convert the grdecl to vtu file. but then the header of the file will be:

The vtu file is ok, I can open it and see with ParaView, but when I compared it to one of the examples of software, it is supposed to be like this:

So I saved the vtu file with ParaView with this config:

to have the same header. Still there will be an error while I run the geos:

geosx -i Sleipner_smoke.xml
Num ranks: 1
Allocated 64.0 B to the HOST : LvArray::Array<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, 1, camp::int_seq<long, 0l>, int, LvArray::ChaiBuffer>
GEOS version: 1.0.1 (develop, sha1: ececf78)

• c++ compiler: clang 14.0.0
• MPI version: Open MPI v4.1.2, package: Debian OpenMPI, ident: 4.1.2, repo rev: v4.1.2, Nov 24, 2021
• HDF5 version: 1.12.1
• Conduit version: 0.9.2
• VTK version: 9.2.6
• RAJA version: 2024.2.2
• umpire version: 2024.2.1
• chai version: 2024.2.2
• adiak version: ..
• caliper version: ..
• METIS version: 5.1.0
• PARAMETIS version: 4.0.0
• scotch version: 7.0.3
• superlu_dist version: 6.3.0
• suitesparse version: 5.7.9
• hypre version: v2.31.0-12-g06da35b1a (master)
• trilinos version: 15.1.1
• Python3 version: 3.10.12
  Started at 2024-10-24 07:17:58.756974278
  Allocated 12.0 B to the HOST : LvArray::Array<int, 1, camp::int_seq<long, 0l>, int, LvArray::ChaiBuffer>
  Allocated 12.0 B to the HOST : LvArray::Array<int, 1, camp::int_seq<long, 0l>, int, LvArray::ChaiBuffer>
  Allocated 12.0 B to the HOST : LvArray::Array<int, 1, camp::int_seq<long, 0l>, int, LvArray::ChaiBuffer>
  Opened XML file: /mnt/sleipner/run/Sleipner_smoke.xml
  Included additionnal XML file: /mnt/sleipner/run/Sleipner_base.xml
  Adding Mesh: VTKMesh, Sleipner_mesh
  Adding Mesh attribute: InternalWell, wellInjector
  Adding Well attribute: Perforation, injector1_perf1
  Adding Event: PeriodicEvent, outputs
  Adding Event: PeriodicEvent, restarts
  Adding Event: PeriodicEvent, timeHistoryCollection
  Adding Event: PeriodicEvent, timeHistoryOutput
  Adding Event: PeriodicEvent, solverApplications
  Adding Solver of type CompositionalMultiphaseFVM, named compflow
  TableFunction: initCO2CompFracTable
  TableFunction: initWaterCompFracTable
  TableFunction: initTempTable
  TableFunction: waterRelativePermeabilityTable
  TableFunction: gasRelativePermeabilityTable
  TableFunction: waterCapillaryPressureTable
  TableFunction: pressureFunction
  TableFunction: temperatureFunction
  Adding Output: VTK, simpleReservoirViz
  Adding Output: Restart, restartOutput
  Adding Output: TimeHistory, timeHistoryOutput
  TableFunction: permxFunc
  TableFunction: permyFunc
  TableFunction: permzFunc
  Adding Object CellElementRegion named reservoir from ObjectManager::Catalog.
  Adding Object WellElementRegion named wellRegion from ObjectManager::Catalog.
  TableFunction: fluid_phaseModel1_PhillipsBrineDensity_table
  TableFunction: fluid_phaseModel1_PhillipsBrineViscosity_table
  TableFunction: fluid_phaseModel2_SpanWagnerCO2Density_table
  TableFunction: fluid_phaseModel2_FenghourCO2Viscosity_table
  TableFunction: fluid_CO2Solubility_co2Dissolution_table
  TableFunction: fluid_CO2Solubility_waterVaporization_table
  VTKMesh 'Sleipner_mesh': reading mesh from /mnt/sleipner/run/Sleipner.vtu
  Generating global Ids from VTK mesh
  VTKMesh 'Sleipner_mesh': generating GEOSX mesh data structure
  ***** ERROR
  ***** LOCATION: /mnt/c/codes/GEOS/src/coreComponents/mesh/generators/VTKUtilities.cpp:2092
  ***** Controlling expression (should be false): nodeGlobalIds.count( pointGlobalID ) > 0
  ***** Rank 0: At least one duplicate point detected (globalID = 1).
  Potential fixes :
• Make sure partitionRefinement is set to 1 or higher.
• Consider checking the validity of your mesh with the mesh_doctor GEOS python tools (documentation at https://geosx-geosx.readthedocs-hosted.com/en/latest/docs/sphinx/pythonTools/mesh_doctor.html).

** StackTrace of 9 frames **
Frame 0: geos::VTKMeshGenerator::fillCellBlockManager(geos::CellBlockManager&, geos::SpatialPartition&)
Frame 1: geos::MeshGeneratorBase::generateMesh(geos::dataRepository::Group&, geos::SpatialPartition&)
Frame 2: geos::MeshManager::generateMeshes(geos::DomainPartition&)
Frame 3: geos::ProblemManager::generateMesh()
Frame 4: geos::ProblemManager::problemSetup()
Frame 5: geos::GeosxState::initializeDataRepository()
Frame 6: main
Frame 7: /lib/x86_64-linux-gnu/libc.so.6
Frame 8: __libc_start_main
Frame 9: _start

---

MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD
with errorcode 1.

NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.

[untereiner]

There are missing parts in your message. Try the merge filter to merge points before exporting to a new vtu file. Compare the number of points in your grdecl file versus your vtu file

[Aliznia]

@untereiner Thank you for your hint! The number of converted points was much higher than in the original grid. So, I used the merge filter, and now it is readable by GEOSX.