Coordinate of the converted model

[leoforeal]

Hallo,

I realized after converting my Petrel/Eclipse model to Exodus, the coodinate of the nodes within the model will a be reset. From my understanding, the model is some how dragged to alingn with the x&y axis.For example, I have a cuboid box model, from the bird view, the (x,y) of the bottom far left node are to be automatically reset to (0,0).

Could you please briefly explain how the coordinate rearranging works in em2ex?

I encounter this problem because I have a well data from Petrel/Eclipse that is exported seperately from my box model, which means a coordinate conversion of should still be done accordingly afterwards.

Thank you very much in advance!

[cpgr]

Oooh, I thought I had this but I can't see it anywhere. The coordinates in the Eclipse file are referenced to the MAPAXES keyword, but I don't seem to have an option to use the origin specified there in the exodus file... I'll add this first thing tomorrow

[leoforeal]

@cpgr that would be perfect!! really appreciate that!!

[cpgr]

I think I have implemented this capability, but just need an example .grdecl file to test on.

[cpgr]

Are you able to check if #38 fixes this?

[leoforeal]

I've tested just now with a old model and got the following error:

line 256, in parseEclipse
xorigin, yorigin = eclipse.mapaxes[2], eclipse.mapaxes[3]
~~~~~~~~~~~~~~~^^^
TypeError: 'NoneType' object is not subscriptable

[cpgr]

Hmmm, can you post the top of the grdecl file that shows the MAPAXES and possibly GRIDUNIT keywords? There might be some format that I haven't tried?

[leoforeal]

I just checked again, there are no key words such as MAPAXES or GRIDUNIT in my GRDECL file.
The ones relevant to the grid structure are:

SPECGRID
100 100 35 1 F /

COORDSYS
1 35 INCOMP /

COORD
20 -0 20 4000 200 0 -0 200 0 4000 400 0 -0 400 0 4000 600 0 -0 600 0 4000 800 0 -0 800 0 4000 1000 0 -0 1000 0 4000 1200 0 -0
..... /

ZCORN
40000*-0 80000300 80000600 80000900 800001200 800001500 800001800 800002100 800002400
... /

ACTNUM
350000*1 /

unfortunately, the .GRDECL couldn't be uploaded here.
does it help providing these information?

[cpgr]

Yep, that was logic error 😄 - thanks for picking it up! Did the one you initially mentioned at the top have a MAPAXES keyword? It should, as this is how it does the coordinate transform unless there is another keyword that I don't know about.

[leoforeal]

okay, i guess i would have to additionally export the keyword MAPAXES in the grid file, let me try to do that in Eclispe.
will get back to you!

[leoforeal]

Hi,
I figured out that, in my model a map coordinate system is not defined at all, that's probably why the keyword MAPAXES does not automatically export in the GRDECL file. The six parameters of MAPAXES can however be entered manually, but I am not sure if it would make sense to do that if the map coordinate system is undefined at first place.

This perhaps leads back to the question, how the coordinate system is altered during the conversion.
I set up an repository under here: https://github.com/leoforeal/GRDECL

There you can find:

1. the GRDECL file of the box model (without manually including MAPAXES)
2. a sketch of the box model from bird view with indication of its coordinate as it is in Petrel

Hopefully these will help with the testing :)

[cpgr]

There must be something missing during the export to .grdecl, as the file you sent generates the following

I don't alter the coordinates at all during this conversion - the values in the grdecl file under COORD are used exactly. In fact, if you take a look at them, you can see that they go from 0 up to 20,000, just like the converted model. There are no negative values (there are lots of -0

Just to be clear - the values that are read from the grdecl file are used without any conversion (apart from the new mapaxes capability in #38, which I believe is the only way that the grdecl file defines a coordinate transformation).

EG:

19600 20000 4000 19800 20000 -0 19800 20000 4000 2*20000 -0 2*20000 4000 /

this is the last line under COORD

[cpgr]

I had never considered the need, but adding a coordinate translation would be trivial. Something like

em2ex.py --translate -10000 -10000 0 Boxmodel.grdecl

to shift the coords would probably work for you?

[leoforeal]

@cpgr you are definitely right! My choice of word wasn't precise enough, translation is for sure a better description in this case.

Exactly as shown in the screenshot, the (x,y)=(0,0) is located at left bottom edge, whereas in Petrel I have defined (x,y)=(0,0) right in the center of the model.

So, I believe, as suggested, adding a coordinate translation would for now work in my case. Although it might not be that straightforward at first sight. This kind of leads back to the problem that it is not very clear to me how the COORD is defined/arranged in a GRDECL file in generel.

[cpgr]

The COORD block looks like this in your example

COORD                                  -- Generated : Petrel
  2*0 -0 2*0 4000 200 0 -0 200 0 4000 400 0 -0 400 0 4000 600 0 -0 600 0 4000 800 0 -0 800 0 4000 1000 0 -0 1000 0 4000 1200 0 -0

It is basically (x,y,z) coordinates of the corners of each cell (but the z isn't used if there is a ZCORN block and the top and bottom x,y coordinates are identical...), so yours is

(0, 0, 0), (0, 0, 4000)
(200, 0, 0), (200, 0, 4000)
(400, 0, 0), (400, 0, 4000)

etc.

So you can see that it is covered to exodus exactly as specified here, ie, the origin is the bottom left corner, not the middle like you see in Petrel.

[cpgr]

Also, 2*0 in the above is identical to 0 0, so the first line is

0 0 0 0 0 4000 etc