Corner-point grid: reader

[VikingScientist]

This needs to be finished by Tuesday.

Currently the model builds 3 geometries:

• C⁰, linear, which is an approximation (average of 4 corners)
• C^-1, linear, exact representation, but unusable for IFEM analysis
• C^0,0,-1, linear, compact exact representation, since all jumps appear in the depth (z-) direction

It should (but does not currently yet) build the corresponding textures to a given model. This is done by sampling the exact geometry and figuring out which cell any given evaluation point is located at.

• Note that this is done at suboptimal performance, by using scipy.spatial.ConvexHull for cell inclusion tests

It should (but does not currently yet) build three different high-order (high continuity) geometries:

• 8 corners - linear interpolation between the 8 corners (or maybe based on the bounding box?)
• 2 faces - degree p-approximation of top and bottom face, linear interpolation between these
• 6 faces - degree p-approximation of all 6 sides and coons patch interpolation between these

[VikingScientist]

This model has diagonal meshlines and a great many degenerate (disabled) cells. Trying to do a 6-side coons patch fit on this will fail. The correct approach is to do a 2-side fit to the top and bottom side, and linear interpolation between these.

The geometry can be found that the OPM repository: PeriodicTilted.grdecl

The same geometry when converted directly from grdecl to vtu (grdecl2vtu from opm-grid )

[VikingScientist]

LocalGridGeometry.grdecl (not available online). Left: (perspective view) exact geometry Right: (perspective view) cubic spline approximation

This geometry has a non-linear distribution of the layers through the z-direction. We need to fit all 6 sides to correctly capture this geometric feature.

Same mesh when viewed in paraview.

Details from the mesh boundary. Notice that jumps ever only appear in the z-direction, hence any geometry would be C^0,0-1

[TheBB]

I have a commit on my own grdecl branch on top of this PR with my own suggested changes.

https://github.com/TheBB/Splipy/commit/4920dfec1fb93efbf727be0797de2d09561aefe7

• more pythonic code
• slightly better but by no means fast inverse lookup
• two methods of fit: six-sided and two-sided (z-direction)
• flattens the first two dimensions in a three-dimensional world
• rescales the images to ensure everything fits in [0,255] (todo: communicate the ranges or something)

Here's the textures for actnum and poro in the diagonal lines model with two evaluation points per knotspan. I guess the latter would look cooler if the model were oriented differently.

https://user-images.githubusercontent.com/619375/47659932-45f40f00-db96-11e8-9b3b-cc91ed463199.png https://user-images.githubusercontent.com/619375/47660021-750a8080-db96-11e8-95f7-822ec0c9f42c.png

Edit: removed the inline images since they are really tall.

Also note that I added a dependency on tqdm in that commit that hasn't been accounted for yet in setup.py.

[VikingScientist]

I did not see you make any changes to setup.py

[TheBB]

Also note that I added a dependency on tqdm in that commit that hasn't been accounted for yet in setup.py.

Exactly. I'm always unsure as a library developer whether I should be writing progress bars to stdout without being asked to do so, so I left that out for the time being.

[VikingScientist]

Oooh. So that's what the tqdm does. Have it dump progress bar as default, with the silent=False argument in the function signature.

[VikingScientist]

In addition to the comments above, make some really simplistic alteration to grdecl_test.py and make an internal grdecl_to_ifem.py-script locally which does the rescaling and dumping of material properties. The syntax for textures in xinp files is:

  <elasticity>                                                                 
    <texturematerial set="Model" file="material.png">                          
      <range min="0.00" max="0.25"  E="1.0" nu="0.4" rho="1"/>                 
      <range min="0.25" max="0.50"  E="2" nu="0.4" rho="1"/>                   
      <range min="0.50" max="0.75"  E="3" nu="0.4" rho="1"/>                   
      <range min="0.75" max="1.00"  E="4" nu="0.4" rho="1"/>                   
    </texturematerial>                                                         
  </elasticity>                                                                

This is how it's done in 2D. For 3D textures we would need to provide one or more of the dimensional size: n1, n2 and/or n3 so IFEM can reassemble the 2D-image into a 3D texture, for instance

    <texturematerial set="Model" file="material.png" ny="512">

if you tile the image vertical by z-direction-slices and x-direction is horizontal.

[VikingScientist]

I think this is ready to merge

[VikingScientist]

No objections to this pull request. Shameless self-merge ensuing.