Error loading EGRID file using res2df and resdata

[gaboeperez]

Hello @here, I hope you can help me with this issue while I try to load an EGRID file using res2df and resdata.

ERROR:

`Abort called from: rd_type_create_from_name (/Users/runner/work/resdata/resdata/lib/resdata/rd_type.cpp:115)

Error message: rd_type_create_from_name: unrecognized type name:E7� `

LOG:

-------------------------------------------------------------------------------- Stack trace (most recent call last): #24 Object "python3.12", at 0x1021b4fff, in main + 55 #23 Object "python3.12", at 0x102418be3, in pymain_main + 551 #22 Object "python3.12", at 0x1024178ab, in Py_RunMain + 1123 #21 Object "python3.12", at 0x10241823b, in pymain_run_file + 71 #20 Object "python3.12", at 0x102418877, in pymain_run_file_obj + 179 #19 Object "python3.12", at 0x1023eea8f, in _PyRun_AnyFileObject + 79 #18 Object "python3.12", at 0x1023ef19b, in _PyRun_SimpleFileObject + 287 #17 Object "python3.12", at 0x1023ef7cf, in pyrun_file + 155 #16 Object "python3.12", at 0x1023efa53, in run_mod + 287 #15 Object "python3.12", at 0x10234a643, in PyEval_EvalCode + 259 #14 Object "python3.12", at 0x10237b6b7, in _PyEval_EvalFrameDefault + 192067 #13 Object "python3.12", at 0x1022b6f83, in type_call + 147 #12 Object "python3.12", at 0x1022c1c7b, in slot_tp_init + 543 #11 Object "python3.12", at 0x10237b6b7, in _PyEval_EvalFrameDefault + 192067 #10 Object "python3.12", at 0x1022be22f, in slot_tp_call + 131 #9 Object "python3.12", at 0x10222da37, in _PyObject_Call_Prepend + 155 #8 Object "python3.12", at 0x10237fa17, in _PyEval_EvalFrameDefault + 209315 #7 Object "_ctypes.cpython-312-darwin.so", at 0x1028e5f8b, in PyCFuncPtr_call + 231 #6 Object "_ctypes.cpython-312-darwin.so", at 0x1028ec10f, in _ctypes_callproc + 755 #5 Object "libffi.8.dylib", at 0x102909833, in ffi_call_int + 1403 #4 Object "libffi.8.dylib", at 0x10290c04b, in ffi_call_SYSV + 75 #3 Object "libresdata.dylib", at 0x102fe1c1b, in rd_file_open + 263 #2 Object "libresdata.dylib", at 0x102fc70cf, in rd_kw_fread_header + 503 #1 Object "libresdata.dylib", at 0x102feb99b, in rd_type_create_from_name + 307 #0 Object "libresdata.dylib", at 0x102f8274b, in util_abort__ + 139 --------------------------------------------------------------------------------

I found the error rises in this py,

resdata/lib/resdata
/rd_type.cpp

in the function that tries to read the data type rd_data_type rd_type_create_from_name, and have no clue what could be causing the error and how to solve it.

Hope you can help me.

[berland]

It looks like your EGRID file contains E7� in a place where it should contain CHAR, REAL, INTE, DOUB, LOGI or MESS.

[gaboeperez]

Hello, and thanks for your prompt reply.
@berland might this be an issue while exporting the EGRID from Intersect? Do you know if there is a specific keyword to avoid this issue.

[gaboeperez]

Hello @berland I've continued trying to read the egrid and with the following piece of code I was able to get in to read the data from the egrid, and I cannot find where is this data type E7?

for kw, arr in resfo.read("Sim_533x1000x323_Real-0-GIMAX60.EGRID"): print(kw) print(type(arr)) print(arr.dtype) print(arr.shape) print('\n')

with this result

`
FILEHEAD
<class 'numpy.ndarray'>

i4
(100,)

MAPUNITS
<class 'numpy.ndarray'>
|S8
(1,)

MAPAXES
<class 'numpy.ndarray'>

f4
(6,)

GRIDUNIT
<class 'numpy.ndarray'>
|S8
(2,)

GRIDHEAD
<class 'numpy.ndarray'>

i4
(100,)

COORD
<class 'numpy.ndarray'>

f4
(3207204,)

ZCORN
<class 'numpy.ndarray'>

f4
(1377272000,)

ACTNUM
<class 'numpy.ndarray'>

i4
(172159000,)

ENDGRID
<class 'numpy.ndarray'>

i4
(0,)
`
I haven't been able to find the issue with the egrid

[berland]

I fear that in order to support your Intersect binary output, a replacement for resdata that uses resfo directly must be written, unless someone comes up with a simple bugfix in resdata.

[gaboeperez]

If we convert the model from Intersect to Eclipse and generate the Egrid from Eclipse instead of Intersect. Do you think this might solve the issue?

[berland]

That is a fair hypothesis yes.