Problem with Radial Grids

[gawilliamsbgs]

Good Morning,

I have a problem with the radial grid in OPM flow. I have converted an ECLIPSE case. I cannot see any problems in my input deck. The simulation runs in ECLIPSE. However, the pressure ramps up very quickly to the BHP cut-off in OPM-FLOW and the wells cannot inject. I noticed that the transmissibility in the I, J and K direction properties calculated by FLOW have very low values, basically zero, in the FLOW simulation. All other parameters output by FLOW (permeability, cell volume, viscosity etc) match the ECLIPSE model. My question is, do these values output by flow represent the inter-cell transmissibility in a radial grid (converted into corner-point geometry)? If so, there may be a bug in the way flow calculates the radial transmissibility. If not, is there a way to output radial transmissibility to the restart file so that I can check it?

To test this, I exported the Transmissibility in the radial and Z directions as calculated by ECLIPSE and read them into flow as TRANI, TRANJ and TRANZ respectively. I know this is not correct, but it allowed the simulation to run, albeit incorrectly. The wells injected with no pressure build-up.

All the Best and thanks for your help,

Gareth Williams

[atgeirr]

@goncalvesmachadoc have you or your colleagues looked at transmissibilities in the radial grid case?

[goncalvesmachadoc]

The radial model in opm is not fully completed and uses adapted corner-point grid. We did derive some "conversion factors" for the transmissivities from corner point grid to radial grid, but we didn't finalize implementing them. By correcting only the volume of the cells, we could already match "real" radial grid case for cake slices very well. For that we compared the spider grid (pure cp grid), against opm radial (cp grid with corrected volumes) and radial cases from reference simulator. Note, depending on the case, WPIMULT may be needed to be used to make sure the BHP's match. In a real radial grid (cylindrical coordinates), the well is in the center of the grid (not being part of the grid). In opm radial (cp grid), the well is inside the first cells in the r-direction; the issue reported here might be coming from this way of modelling the well. More work needs to be done to have the well acting as a boundary instead of a sink. @gawilliamsbgs How is the first cells' dimensions compared to well diameter? Is this a cake slice or a full disk case? Would be possible to share the case for us to take a look?

[gawilliamsbgs]

Good Afternoon,

Thanks for your response.

I set the inner radius of the grid to the wellbore diameter. It is a full disk case. What you say below makes some sense and it may be the problem, but the case runs if I manually set the TRANX, TRANY, TRANZ with the values calculated by ECLIPSE. It also gives good agreement with the ECLIPSE case.

When I look at the TRANX, TRANY, TRANZ arrays output by OPM flow they contain very low (essentially zero) values.

I have attached the input data to this email.

All the Best and thanks for your help,

Gareth

From: Cíntia Gonçalves Machado @.> Sent: Thursday, July 27, 2023 10:50 AM To: OPM/opm-simulators @.> Cc: Gareth Williams - BGS @.>; Mention @.> Subject: Re: [OPM/opm-simulators] Problem with Radial Grids (Issue #4755)

You don't often get email from @.**@.>. Learn why this is importanthttps://aka.ms/LearnAboutSenderIdentification

The radial model in opm is not fully completed and uses adapted corner-point grid. We did derive some "conversion factors" for the transmissivities from corner point grid to radial grid, but we didn't finalize implementing them. By correcting only the volume of the cells, we could already match "real" radial grid case for cake slices very well. For that we compared the spider grid (pure cp grid), against opm radial (cp grid with corrected volumes) and radial cases from reference simulator. Note, depending on the case, WPIMULT may be needed to be used to make sure the BHP's match. In a real radial grid (cylindrical coordinates), the well is in the center of the grid (not being part of the grid). In opm radial (cp grid), the well is inside the first cells in the r-direction; the issue reported here might be coming from this way of modelling the well. More work needs to be done to have the well acting as a boundary instead of a sink. @gawilliamsbgshttps://github.com/gawilliamsbgs How is the first cells' dimensions compared to well diameter? Is this a cake slice or a full disk case? Would be possible to share the case for us to take a look?

— Reply to this email directly, view it on GitHubhttps://github.com/OPM/opm-simulators/issues/4755#issuecomment-1653277614, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKUKK2PQKNLWJH2ZDN6XDWLXSI2THANCNFSM6AAAAAA2W44SJA. You are receiving this because you were mentioned.Message ID: @.**@.>>

This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses.

[goncalvesmachadoc]

@gawilliamsbgs Could you send the case to cintia.machado@tno.nl ?

[goncalvesmachadoc]

@gawilliamsbgs Thank you for sending the case. If you change in your OPM data file

DTHETAV
1*360
/

to

DTHETAV
1*60
/

you can get a match between your two models:

Note, considering OPM-Flow uses corner-point grid, it's not possible to create a full ring (360 disk) with only one cell (DTHETA=1). In most cases (if you have no heterogeneities or flux in theta-direction), it should be ok to model with just a slice.

[gawilliamsbgs]

Thanks For Your Help Cintia,

I just assumed that the radial option altered the inter-cell transmissibility and pore volume to account for the radial geometry and then used a cell centred finite difference scheme, my mistake.

All the Best,

Gareth

From: Cíntia Gonçalves Machado @.> Sent: Tuesday, August 1, 2023 4:30 PM To: OPM/opm-simulators @.> Cc: Gareth Williams - BGS @.>; Mention @.> Subject: Re: [OPM/opm-simulators] Problem with Radial Grids (Issue #4755)

You don't often get email from @.**@.>. Learn why this is importanthttps://aka.ms/LearnAboutSenderIdentification

@gawilliamsbgshttps://github.com/gawilliamsbgs Thank you for sending the case. If you change in your OPM data file

DTHETAV

1*360

/

to

DTHETAV

1*60

/

you can get a match between your two models:

[image]https://user-images.githubusercontent.com/54812829/257561750-9f898660-c215-44c8-b613-24f71872f064.png

Note, considering OPM-Flow uses corner-point grid, it's not possible to create a full ring (360 disk) with only one cell (DTHETA=1). In most cases (if you have no heterogeneities or flux in theta-direction), it should be ok to model with just a slice.

— Reply to this email directly, view it on GitHubhttps://github.com/OPM/opm-simulators/issues/4755#issuecomment-1660563466, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKUKK2LZWSEWJPRS3E67HXDXTEOJJANCNFSM6AAAAAA2W44SJA. You are receiving this because you were mentioned.Message ID: @.**@.>>

This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses.