You are here
Home > BLOG > Petrel > Converting Eclipse Data Deck to Petrel Case (Petrel 2011.1)

Converting Eclipse Data Deck to Petrel Case (Petrel 2011.1)

Figure 2: Case Conversion processing illustration


In order to convert the Eclipse Data Deck to Petrel Case, it is essential to read the below highlighted topic in the Petrel Online manual. In addition, the following material can be very helpful to make sure that case conversion is properly implemented.



Hadi Parvizi

Teesside University

Technical Report

Figure 1: Case Conversion in Petrel Online Manual

Figure 1: Case Conversion in Petrel Online Manual

Case Conversion Methodology

In Petrel, reverse engineering and case conversion are different terms for the same process of converting Eclipse data deck in Petrel case.

Petrel needs .DATA, the associated grid and .INIT files to perform the case conversion.

Petrel distinguishes the GRID|EDIT section properties which are introduced or modified in .DATA, it gets and generates these properties from .INIT and leave the rest of INIT properties as been defaulted in. DATA, because it reduces non-productive efforts of generating all the properties available in .INIT .

Petrel will delete all COPY, ADD, MULTIPLY and … operator keywords; since the final result must be available in .INIT and Petrel does not need those keywords anymore.

Petrel deploys .DATA to create the functions and development strategy and drops them into the expected positions in Define Simulation Case.

Figure 2: Case Conversion processing illustration

Figure 2: Case Conversion processing illustration

Quality Checking of Case Conversion

The following workflow is supposed to help the user to quality check the case conversion more efficiently and leads to a faster understanding of the root cause of any inconsistency in the converted case compared with imported data deck. Especially for the complicated cases, this might be a good track of the process to assure the simulation output resembles.

Figure 3: Case Conversion quality check workflow

Note: Regarding version compatibility, Eclipse 2011.1 onwards is required to run exported case by Petrel 2011.1 if there is inactive cell in the model. Because in case conversion, Petrel 2011.1 onwards does not export the values for inactive cells (and writes 1* which is the default value) whereas Eclipse version until 2010.2 expects to have a not-defaulted value per cell even that cell is inactive. There might be some workarounds such as replacing 1* by 0 (or any other number) that user can apply by Petrel Keyword Editor if Eclipse 2011.1 onwards is not available for him/her.

We expect the converted case to report the same pore volume, and fluid in place of different phases which implies that initialization is acceptable. In case of SCHEDULE section conversion, still there might be some inconsistencies that in next section will be explained.

Note: Petrel is not currently supporting an Eclipse data file which has COARSEN keyword. There is a workaround in SWIFT 2542312.

Note: Petrel 2011.1 is not supporting IMPORT keyword. But, as a workaround, user can introduce those keywords which are defined into IMPORT keywords under a keyword such as EQUALS and give any value such as zero. Make sure that this EQUALS keyword is before the relevant IMPORT. This action will not affect simulation results because the values will be overwritten by IMPORT keyword. On the other hand, it helps Petrel to distinguish the properties that should be extracted from INIT file. After Petrel conversion, please use keyword editor and delete all the IMPORT keywords. (SWIFT 2549822)

Note: In case there is WATER keyword in RUNSPEC of imported data deck and no PVTW, Petrel ignores WATER phase and it may lead to significant oil in place difference. The workaround is just to add PVTW to the imported data deck.

Enumeration Models

Petrel requires time step [0] to generate the initial distribution of saturation and pressure properties of the model. The common mistake is not to have restart file for report step [0]. To generate RESTART file for report step [0], user must have RPTRST in SOLUTION section because the first report step that can be generated by SCHEDULE section would be report step [1].

The technique of reading the keywords and generating the properties is the same technique of using .INIT but from .X000 or .UNRST (if simulation output is unified). Thus, Petrel reads the SOLUTION section and recognizes the introduced enumeration keywords (such as SWAT, PRESS, …) , and then it retrieves those properties from restart file [0] and removes the operator keywords if there is any in SOLUTION section.

Schedule Section Conversion

-By enabling Petrel, to introduce Schedule Keywords in Make development strategy, Petrel is much flexible to cover the more imported keywords by cloning (copy pasting) them into development strategy. On the other hand, Petrel needs to convert some keywords such as WELSPECS, COMPDAT, WELSPECL, COMPDATL, GRUPTREE, WCONHIST, WCONINJH, WELTARG, WELOPEN, WPIMULT, and etc.

Figure 4: Converted Development Strategy

Figure 4: Converted Development Strategy

-Be aware if connection transmissibility factor (COMPDAT item 8) would be provided for Eclipse simulator, it eliminates the rest of items of 9, 10, 11, and 14 of COMPDAT keyword in connection transmissibility factor calculation. It shows the importance of connection transmissibility factor compared with Effective Kh. Thus, in case conversion, if honoring the imported Effective Kh by COMPDAT (item10) will result in a different connection transmissibility factor; Petrel is supposed to ignore the imported Effective Kh and try to have the correct connection transmissibility factor instead by modifying effective Kh. That might lead to an inconsistency between imported and converted COMPDAT (item 10); but it must not result in a significant output difference for well productivity index.

-If in imported data deck for COMPDAT keyword, there is higher connection transmissibility factor (item 8) than what Petrel is calculating based on the imported permeability and grid properties of the data deck; Petrel generates the same value of connection transmissibility factor by generating corrected Net Perm log for each well and reporting modified Effective Kh (COMPDAT item10). This modified Kh is supposed to be such values versus depth in which generates the same connection transmissibility factor.

-By this approach, quality checking the data would be much easier; because user can open a well section window and compare the generated Net Perm log with Permeability of the Grid to get an idea where inconsistencies between the imported properties and transmissibility factor makes Petrel to report different Net Perm log values; And then Net Perm Log will be automatically introduced to Define Simulation Case of the converted case. One can also generate Permeability logs extracted from the Grid data; and compare it with the Net Perm Log in the same track of well section window. This might be applicable for vertical wells having isotropic permeability.

Figure 5: QC of Net Perm log vs. grid permeability

Figure 5: QC of Net Perm log vs. grid permeability

Figure 6: Net Perm introduction to Define simulation case window

Figure 6: Net Perm introduction to Define simulation case window

Petrel ignores items 13 and 14 of COMPDAT keyword in case conversion; and re-calculates these items based on the extracted well trajectory and the imported grid data to suppress any possibility of inconsistency in imported data. This might result in well productivity index difference between imported case and the converted one.

Auto Flag of COMPDAT is treated as OPEN flag in Petrel 2011.1 and needs manual correction by keyword Editor. (Swift 2534670)

If in Eclipse data deck, there are some PVT or Rock functions which are not introduced for any cell in the model but used for well modeling, say, WELSPECS item 11, Petrel 2011.1 is not supporting the issue and user needs to follow the Export functions for regions with no cells workaround in Petrel on line manual.

Figure 7: Workaround of Export functions for regions with no cells

Figure 7: Workaround of Export functions for regions with no cells

Dual Porosity Models

In dual porosity models, special care should be taken as strange input into the data deck can mislead Petrel in case conversion. The following is an example:

In case, user defines well completion in matrix, in Petrel case conversion, it would be considered for the Fracture as well. Suppose NZ=5 for a DUALPORO model (i.e. there are 5 layers in the model), then the following will happen in case conversion:


PROD 2* 1 7 …/ (5 Matrix plus 2 Fracture layers are completed)

Would be converted to:


PROD 2* 6 10 …/ (5 Fracture layers are completed)

This conversion action might be justifiable as the user has no reason for defining the first 5 layers of completion in matrix of a dual porosity model and that leads to such a difference.

On the other hand, in DUALPERM model, the side effect might be more important as this time, user might have a reason to define COMPDAT as mentioned.



PROD 2* 1 7 …/

Would be converted to


PROD 2* 1 10 …/

Thus, with this in mind if you have perforation interval, Petrel considers that for fracture layers in DUALPORO and for both of matrix and fracture layers in DUALPERM. If you expect other behavior, you may edit the exported data deck manually.


Although Petrel 2011.1 has some enhancements regarding case conversion, which results in handling this issue much easier, quality checking the converted case is still essential. A workflow is introduced to do this task more efficiently.

Regarding case conversion, more attention is required for Schedule section as there are still some items of some Keywords not converted and might be some difference in calculated Well Productivity Index. Besides, the imported eclipse data deck might have some inconsistent data in SCHEDULE section such as cell penetration direction determination in COMPDAT keyword. This also might lead to PI difference in converted case and needs quality checking.

Emanuel Martin
Emanuel Martin is a Petroleum Engineer graduate from the Faculty of Engineering and a musician educate in the Arts Faculty at National University of Cuyo. In an independent way he’s researching about shale gas & tight oil and building this website to spread the scientist knowledge of the shale industry.

Leave a Reply

one × three =