cpgr / em2ex Goto Github PK

For some models with a large number of blocks, conversion can take minutes. In these cases, there is no output after the input file has been parsed, so the user doesn't know if the conversion is still continuing.

It would be useful to add a progress note every n seconds to alert the user that the conversion is running, it is just taking time.

Hi Chris,
I am trying to use this fantisitc code to convert eclipse into exodus. after add python path to my bashrc file i run the code but i got the following error (as the attached images)

<ImportError: No module named ExodusMode>
thanks so much for your help to fix to point in advance
Cheers, mahmoud

Try and reduce code duplication in the readers by factoring out common functionality. This will make it easier to fix bugs/add features

@rpodgorney has alerted me to a bug in the way that the elements in each block are being written out that is due to misunderstanding of the exodus element numbering. This is showing up as sidesets being incorrectly written when block restriction is used.

Consider the following simple 2x2x1 example. If there is only one block id, then the element ids (green numbers) and node numbers (yellow numbers) are

which is what I expected. If we make element 4 part of a different block, then we have

ie: nothing has changed. However, if element 3 is now part of block 2 instead of element 4, the exodus file is now

In this case, the element ids have changed from the expected order. It appears that the exodus format internally numbers elements sequentially by block id. So all elements in block 1 (the blue blocks) are numbered sequentially, then all elements in block 2 etc.

I've checked and the node sets are correct in all cases, which makes sense as the nodes are always numbered in the expected order. The sidesets in the last case are wrong, though, as they are created assuming the element ordering in the first image.

Hallo!

While using this code I successfully converted a Petel/Eclipse (.grdecl files) to Exodus II (.e),
but as I opened the model with Paraview, I realized the sign of z-coordinate is automatically reversed to positive values.
for example:
x: 100 y: 100 z: -100 in Petrel model becomes
x: 100 y: 100 z: +100 after the conversion.

Does anyone know what could be the reason behind this or more specifically how i could retain the negative z value after the conversion?

Eclipse data sets can represent faults through a vertical offset in the grid. At the moment, this is not properly dealt with, but we can implement this functionality.

@MickyDroid is doing this for me

Hi,
As Petrel export eclipse file that mostly contains some shorthand notation (N*data ) in many block with the grdecl file. I am trying to use the function processData that was provided in ecilpse reader for expansion, but it doesn't work well. Can you provide more explantion about this point.
if you would like, I can share some of the grdecl file.
Thanks so much for helping to figure this issue out.

Dear Chris,
As em2ex keep reservoir model material properties like porosity/permeability when it converts from eclipse format into exodus format. I am kindly wondering about the best way to get these material properties of the elements from exodus file when we read in moose [porousflow M.], instead of typing one single value for porosity/ permeability,..etc within the input file.
Thanks so much
Sam

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!