Error with Eclipse GRDECL grid

[wdmhouston]

Francois,

Please find the attached test data set with Eclipse GRDECL grid.

This test dataset is modified from a working simple grid. The only part modified is

the original eclipse grdecl grid has the following size:
x: 0 to 1000, y: 0 to 1000, z: -1000 to -2000

and it's imported into xml file with reverseZ option,

a well is drilled near the xy center with one perforation only.

when run this test case, the following "cellBlocks doesn't have a child all" error reported.

Reading external mesh from /data/test/EclipseGrdecl/3DGrid.GRDECL
0 >>> **********************************************************************
0 >>>                          PAMELA Library Import tool
0 >>> **********************************************************************
0 >>> ECLIPSE GRDECL FORMAT IDENTIFIED
0 >>> *** Importing Eclipse mesh format file 3DGrid
0 >>> ---- Parsing /data/test/EclipseGrdecl/3DGrid.GRDECL
0 >>>      o SPECGRID or DIMENS Found
0 >>>      o COORD Found
0 >>>      o ZCORN Found
0 >>>      o ACTNUM Found
0 >>>      o PORO Found
0 >>> *** Converting into internal mesh format
0 >>> 6000  total GRDECL hexas
0 >>> 6000  initially set as active hexas
0 >>> 0  active but flat hexas (->deactivated)
0 >>> 0  active but ill-shaped hexas (->deactivated)
0 >>> 0  duplicated hexas
0 >>> 6000  will actually be used in the GEOSX mesh
0 >>> *** Filling mesh with imported properties
0 >>> *** Creating Polygons from Polyhedra...
0 >>> 19000 polygons have been created
0 >>> *** Done
0 >>> *** Perform partitioning...
0 >>> TRIVIAL partioning...
0 >>> Ghost elements...
0 >>> Clean mesh...
0 >>> *** Done...
0 >>> Clean Adjacency...
0 >>> *** Done...
Writing into the GEOSX mesh data structure

***** LOCATION: /apps/GEOSX/src/coreComponents/dataRepository/Group.hpp:325
***** Controlling expression (should be false): child == nullptr
***** Rank 0: Group /domain/cellManager/cellBlocks doesn't have a child all

** StackTrace of 7 frames **
Frame 0: geosx::CellElementRegion::generateMesh(geosx::dataRepository::Group&)
Frame 1: geosx::ElementRegionManager::generateMesh(geosx::dataRepository::Group&)
Frame 2: geosx::ProblemManager::generateMesh()
Frame 3: geosx::ProblemManager::problemSetup()
Frame 4: geosx::GeosxState::initializeDataRepository()
Frame 5: main
Frame 6: __libc_start_main
Frame 7: _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.
--------------------------------------------------------------------------

I guess it's something related to cell block region definition, but no sure how to fix it. Any suggestion?

eclgrid.zip

[francoishamon]

Hello @wdmhouston

Here is the updated XML file. Couple of points:

• If you import a mesh from a GRDECL file, the cell block needs to be DEFAULT_HEX

<CellElementRegion 
  cellBlocks="{ DEFAULT_HEX }"
  materialList="{ fluid, rock, relperm, rockPerm, rockPorosity,nullSolid}"
  name="Reservoir"/>

• It was a good idead to use reverseZ to have the GRDECL oriented correctly in GEOSX (depth needs to be converted to elevation). However, I just found a bug in reverseZ that leads to negative volumes, so while this is being fixed, can you please use branch bugfix/hamon/fixReverseZ?

• I removed the pressure initialization from your file because the pressure table was missing. On our side, the work on EQUIL-type initialization has started, it should be ready in one week or two. I will let you know.

eclgrid.txt

[wdmhouston]

Thank you. Sound great! Will try.

[francoishamon]

@wdmhouston The problem has been fixed, you should be able to run the xml file I sent you with develop now.

[wdmhouston]

Thank you. Will try.

[wdmhouston]

Hi @francoishamon ,

I was able to run that example case with GRDECL file. Now, I would like to import Porosity property like this:

<PAMELAMeshGenerator name="mesh"
		                     file="3DGrid2.GRDECL"
							 fieldsToImport="{rockPorosity_referencePorosity}"
		                     reverseZ="1"/>

this porosity data in grdecl file looks this,

rockPorosity_referencePorosity                    
  400*0.1 400*0.2 400*0.3 400*0.4 400*0.5 400*0.6 400*0.7 400*0.8 400*0.9 400*1 400*1.1 400*1.2 400*1.3 400*1.4 400*1.5 /

in GEOSX, I got the following error:

***** LOCATION: /apps/GEOSX/src/coreComponents/mesh/generators/PAMELAMeshGenerator.cpp:61
***** Controlling expression (should be false): m_fieldsToImport.size() != m_fieldNamesInGEOSX.size()
***** Rank 0: Mismatch between number of values in fieldsToImport and fieldNamesInGEOSX attrabutes
Expected m_fieldsToImport.size() == m_fieldNamesInGEOSX.size()
  m_fieldsToImport.size() = 1
  m_fieldNamesInGEOSX.size() = 0

Here is the test case: EclipseGrdecl_geosx.zip

Any advice? Thanks.

[francoishamon]

Hello @wdmhouston,

Please find attached a working case:

In the XML file, the mesh input should look like:

<PAMELAMeshGenerator 
  name="mesh"
  file="3DGrid.GRDECL"
  fieldsToImport="{ PORO }"
  fieldNamesInGEOSX="{ rockPorosity_referencePorosity }"
  reverseZ="1"/>

and in the GRDECL file you should have the PORO keyword:

PORO                    
  400*0.1 400*0.2 400*0.3 400*0.4 400*0.5 400*0.6 400*0.7 400*0.8 400*0.9 400*1 400*1.1 400*1.2 400*1.3 400*1.4 400*1.5 /

An example for the import of permeability is here.

Warning! You will need to use a recent develop version to make this work (after this commit).

EclipseGrdecl_geosx_working.zip

[wdmhouston]

@francoishamon I see! that's easy. I will try feature/hamon/CPGReader. In my case, I am trying to give an initial pressure for each cell(enumeration) in a complicated grid. I can add pressure data using tablefunction, but it will need x/y/z.geos for each cell, and that takes time to generate.

Here are two questions,

1. For pressure initialization using tablefunction, can I give pressures for 8 corner points of the whole grid, then using 'interpolation="linear"' to let GEOSX calculation grid pressure based on z depth?
2. Does the feature/hamon/CPGReader include capillary pressure function? I am planning to try capillary pressure soon.

[francoishamon]

1. Yes, you can do what you suggest, GEOSX is going to interpolate in the pressure table using the cell center coordinates in each cell of the mesh. Let me just mention here that there is a PR in the pipeline that implements the EQUIL keyword with TEMPVD and XMFVD options. The PR is ready, matches well the initial pressures computed with IX, and will be merged in the next weeks. Currently, it has capillary pressure (but no aquifer, sorry). You can view it here, and its documentation is here.
2. Yes, the branch feature/hamon/CPGReader has capillary pressure in it, no aquifer. Let me just send you an example to illustrate how to use it so you don't waste time

I sent you a meeting request to help you navigate all these unmerged branches. Everything should come together soon!

[wdmhouston]

@francoishamon,

Thanks for all the update. Good to know more and more nice features are going be merged into develop version.

Per our discussion, I created a test case with large Grdecl grid. I have already add some information about grid and wellbore  in xml file. 
[LargeEclGrid.zip](https://github.com/GEOSX/GEOSX/files/7350694/LargeEclGrid.zip) 

Can you take a look and help me figure out two issue/question first?
1. I have actnum in grdecl file to simulate fault, what is the right syntax for fieldsToImport and fieldNamesInGEOSX in PAMELAMeshGenerator tag in xml file?
2. I didn't find enough time to fix the perforation error in this case:

***** LOCATION: /apps/GEOSX/src/coreComponents/mesh/WellElementRegion.cpp:67
***** Controlling expression (should be false): matchedPerforations != numPerforationsGlobal
***** Rank 0: Invalid mapping perforation-to-element in well wellInjector1. This happens when GEOSX cannot match a perforation with a reservoir element. The most common reason for this error is that a perforation is on a section of  the well polyline located outside the domain.

Maybe it's related to reversed Y coordinates. Can you take a look and make any modification to fix this error?

After all fixed, we can test capillary pressure and grdecl import in parallel mode. If you have any questions, please let me know.

[francoishamon]

@wdmhouston I can have a look at the error. Would you mind reposting the mesh? Something went wrong and it was not uploaded to github (maybe it is too large?)

[wdmhouston]

@francoishamon
Here is the link

LargeEclGrid.zip

[wdmhouston]

@francoishamon,

Can you show me how to import Actnum from grdecl ?  I would like to use this to simulate a fault.

Here is what I would like add to mesh generator,
<PAMELAMeshGenerator name="mesh"
	                     file="grid.GRDECL"
	                     fieldsToImport="{ PORO, PERM, ACTNUM }"
	                     fieldNamesInGEOSX="{ rockPorosity_referencePorosity, rockPerm_permeability, ??}"
	                     reverseZ="1"/>

[wdmhouston]

thanks. I updated grdecl file and please use this dataset
LargeEclGrid.zip

[wdmhouston]

I tested in feature/hamon/CPGReader branch with one perforation in the same case, and it failed with the following message,

LargeEclGrid_simpleperf.zip

Number of perforations = 1
Perforation #0
Coordinates of the perforation: { 666850, -7.7305e+06, -2003.42 }
Transmissibility computed internally
Is connected to well element #0

  Reservoir/DEFAULT_HEX/fluid is allocated with 1 quadrature points.
  Reservoir/DEFAULT_HEX/rock is allocated with 1 quadrature points.
  Reservoir/DEFAULT_HEX/relperm is allocated with 1 quadrature points.
***** ERROR
***** LOCATION: /apps/GEOSX/src/coreComponents/constitutive/ConstitutiveManager.cpp:72
***** Controlling expression (should be false): constitutiveGroup->hasGroup( constitutiveRelationInstanceName )
***** Rank 0: Error! The constitutive relation rockPerm has already been registered on the subRegion DEFAULT_HEX. Make sure that the same constitutive model is not listed as a material on a region both as a stand-alone one and as part of a compound constitutive model.

** StackTrace of 7 frames **
Frame 0: geosx
Frame 1: geosx::ProblemManager::setRegionQuadrature(geosx::dataRepository::Group&, geosx::constitutive::ConstitutiveManager const&, geosx::mapBase<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, long, std::integral_constant<bool, true> > const&)
Frame 2: geosx::ProblemManager::applyNumericalMethods()
Frame 3: geosx::ProblemManager::problemSetup()
Frame 4: geosx::GeosxState::initializeDataRepository()
Frame 5: main
Frame 6: __libc_start_main
Frame 7: _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.
--------------------------------------------

[francoishamon]

@wdmhouston Sorry I am just getting to this now. Ok I see your error, there is an easy fix in the xml for that. I am going to make sure that things work properly both in develop and feature/hamon/CPGReader and then I will send you an update (hopefully today)

[francoishamon]

@wdmhouston I attach the xml file for your simulation with the GRDECL file.

To circumvent the issues that PAMELA currently has to load properties in parallel, I suggest the following:

• Checkout feature/hamon/CPGReader
• Do git submodule update
• Reconfigure GEOSX
• Run the simulation in parallel: srun -n 64 ./bin/geosx --input LargeEclGrid_cpgreader.xml where the number of MPI ranks (here 64), should be the square of a whole number.

The issue in the well setting was in the y coordinate of the trajectory (-7730500 instead of 7730500)

I tested up to 64 MPI ranks and it seems to work well. The MPI partitioning is Cartesian. You can add capillary pressure tables if you need to.

I have a question of your GRDECL file: are the coordinates in meter or in foot? GEOSX expects them in meter. So if there are in foot, modify the input file as follows:

<ExternalCornerPointMesh                                                                                                                                                       
    name="mesh"                                                                                                                                                                
    permeabilityUnitInInputFile="Millidarcy"                                                                                                                                   
    coordinatesUnitInInputFile="Foot"                                                                                                                                         
    file="grid.GRDECL"/>

and then adjust the position of the perforations accordingly.

filesForDeming.tar.gz

[wdmhouston]

@francoishamon
Thanks. will try. If I use the default develop branch, is it possible to disable cells using actnum in FieldSpecification?

[wdmhouston]

@francoishamon,

I noticed that the initial pressure distribution is not correct, so I adjusted pressure.geos and now initial pressure is OK.
but no CO2 is observed in reservoir after injection. any idea? I guess it's small issue, please take a look.

You can find the test file here:
eclgrid_cpgreader.zip

[francoishamon]

@wdmhouston Yes I can have a look. Do you confirm that the units of the coordinates of your GRDECL are in meters?

[wdmhouston]

@francoishamon,

Yes, the coordinates in GRDECL are in meters.  I double checked ZCORN/well path in xml, and didn't find anything wrong.  Actually, the grid y coordinates are reversed(should be positive, not negative), but it's not a critical issue to me now and maybe get it fixed(or add a reverse y option) in  future. Thanks.

[wdmhouston]

@francoishamon,
The exported COORD/MAPAXES values in GRDECL file may change depending on the export option. just FYI. as I mentioned, we can ignore this now and fix/improve the GRCECL reader in future.

[tayebel]

Hello, I have a problem with importing GRDECL file using ExternalCornerPointMesh or PAMELAMeshGenerator, how to use those two keyword? because this is the error that I am having:
Rank 0: Could not find keyword "PAMELAMeshGenerator" in this context. Please be sure that all your keywords are properly spelled or that input file parameters have not changed.

All available keys are: [

InternalMesh,

InternalWell,

InternalWellbore,

VTKMesh

]

[TotoGaz]

Hello, PAMELA has been removed from geos and we do not support eclipse grids anymore: it has to be converted to a vtk mesh as a pre-processing step.

[tayebel]

thanks

[cl8909]

Thanks