Eclipse or CMG (Computer Modeling Group) - Numerical Simulators

[TomHampton]

What is your question? On 3D GemPy geological models, can GemPy export into corner point grid files for use in numerical simulators such as Eclipse or CMG?

[Japhiolite]

Hi Tom, different gridding options is currently one point of development. I've personally often used the regular grid of a gempy model as rectilinear grid in numerical simulators.

[TomHampton]

Thanks! Appreciate the response.

Regular grid (corner point) grid is what I’m looking for out of gempy to use in Eclipse or CMG.

Tom

From: Jan Niederau @.> Sent: Tuesday, July 26, 2022 1:37 AM To: cgre-aachen/gempy @.> Cc: TomHampton @.>; Author @.> Subject: Re: [cgre-aachen/gempy] Eclipse or CMG (Computer Modeling Group) - Numerical Simulators (Issue #707)

Hi Tom, different gridding options is currently one point of development. I've personally often used the regular grid of a gempy model as rectilinear grid in numerical simulators.

— Reply to this email directly, view it on GitHub https://github.com/cgre-aachen/gempy/issues/707#issuecomment-1195179918 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AP3UL63KSYY77LJ7RMFUPATVV6PSFANCNFSM53HXNTXA . You are receiving this because you authored the thread. https://github.com/notifications/beacon/AP3UL6YOT5VNNYTFCO5GDWTVV6PSFA5CNFSM53HXNTXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOI46P7DQ.gif Message ID: @.*** @.***> >

[SeyydMojtaba]

Would be nice if some expert can answer this question of Tom. The geomodels are ultimately going to be used in reservoir models. Exporting the grids' corner point locations (x,y,z) is really essential and at the moment it seems we can only export the coordination of the centre of the grids which is of no use. Thanks.

[SeyydMojtaba]

Hi Tom, we can get the number of grids in each direction as well as the dx, dy and dz by:

##model resolution nx, ny, nz = geo_model.grid.regular_grid.resolution

#model extent

xmin, xmax, ymin, ymax, zmin, zmax = geo_model.grid.regular_grid.extent dx = (xmax-xmin)/nx dy = (ymax-ymin)/ny dz = (zmax-zmin)/nz

use this info to define cartesian grids in CMG/Eclipse. Then, use the lithologies id to identify the id of each grid:

#get the litologies ids

ids = geo_model.solutions.lith_block print(ids) units = ids.reshape((nx, ny, nz))

Use the "units" array to define the grid properties based on the lithologies. For example, to define the permeability realization in your reservoir model, you can set all the grids with id of for example 2 to have the k= 100 mD and so on. Then use this permeability realization map in your reservoir model. For CMG you can use include files and copy the data to include files using:

property= [] for k in range (units.shape[1]): for i in range (units.shape[2]): for j in range (units.shape[0]): property.append(units[ i, j, k]) property= np.array(property) property= property.reshape(12500,10)

You need to copy and paste the "property" into your text include file or you can write a code to do it.

Let me know if you have any questions. It worked for me.

I should say this shows there is so much room for improving Gempy. One thing is the grid type. Uniform/regular grids are not as good as non-orthogonal corner point grids. With regular grids, the surfaces can not be defined very smoothly unless we go to a very high resolution.

Cheers Mojtaba

[Japhiolite]

Hi @SeyydMojtaba First off, thank you for your great contribution in this issue to get to corner point grids. I would not say that centered grids are of no use. I've successfully used them in different kinds of reservoir simulators myself. However, I agree that different eligible grid types are a desirable feature.

You hinted at much room for improving GemPy in that direction. Allow me to share my opinion on this: As you identified, the feature for corner point grids is currently not implemented in GemPy up to a level of easily generating it by the call of a function. Alas, you wrote a script to get towards such a grid. As an opens-source project, this code's future also depends on the community using it, i.e. implements features they need, extends the usability of the code.

This project started as a code for a PhD thesis and the main developers now can only maintain it as a side project besides their main work. So distributing the workload on more contributing shoulders is one necessity to shape this code towards ones personal requests (which 100% will also be requests of other users).

Therefore I encourage you to further contribute, e.g. by extending the solutions beyond the center-grid lith_block to also have a corner-point grid. We have guidelines for contributing, which can be found here.

Best, Jan

[AlexanderJuestel]

Is this still an active discussion?