Negative well index calculated and problem with Actnum in GRDECL processing

[Bertrand Cuesta]

Dear MRST users and support,

I encounter some issues to read a grdecl grid and then to process the grid. The grid was exported with TNaviagtor. Some cells are inactive (same situation as the Norne grid). After reading the grid (readGRDECL keyword), I get, a grdecl structure.

The cartDims are 108*43*55=255420. As you can see porosity (PORO) and permeability matrices are properly read since there are 255420 values – undefined cells are set the value 99999. However not all actnum values are read (254897 values). Is there something that could prevent a proper reading of the GRDECL file? Or is it the GRDECL file which is corrupted.

Of course, when processing the grid the following error message pops-up:

 error: reshape: can't reshape 254897x1 array to 108x43x55 array

To overcome this issue, I have deleted the actnum values, and reiterated the process. GRDECL is processed and constructed as follow:

G_c2=processGRDECL(GRD_,'Verbose',true,'CheckGrid',false,'SplitDisconnected',false);
G_c2=computeGeometry(G_c2);

Rock is built as follow:

rock=grdecl2Rock(GRD_,G_c2.cells.indexMap);

 There are 162884 cells with a defined values.

An array of transmissibility is successfully built

Trans_mat = computeTrans(G_c2, rock);

BUT whenever I try to add a vertical well:

W=[];

W=verticalWell(W, G_c2, rock, 20, 25, 30, 'Type', 'rate', ...

                    'Val', 1000*meter^3/day, 'Radius', 0.1, 'Comp_i', 1, ...

                    'name', ['toto'],'Sign',1)

I get an error message specifying a negative well index:

error: Large negative skin factor causing negative well index.
error: called from
    computeWellIndex at line 110 column 7
    addWell at line 275 column 20
    verticalWell at line 170 column 3

The cell which is connected to the well (20,25,30), does exist, and there is no skin specified (I guess it is defaulted to 0). I don’t understand why negative well index is calculated. Do you have any idea what could be the cause of such problem?

Many thanks for your reply.

Bertrand

[Bård Skaflestad]

Hi,

 

Just out of curiosity, are you running MATLAB or Octave?  This distinction normally does not matter too much, but I'm also aware that input file reading is one of the areas of MRST where the MATLAB support is better/more well behaved than the Octave support.  This is partially due to fundamental differences in the low-level functions we call to read a text stream.

I think the "large negative skin" diagnostic is misleading here since it fails to take one other possibility into account.  If PERMX = PERMY = 0 in one or more cells intersected by your well you might also get a negative connection transmissibility factor ("well index").  You might at least wish to ensure that the permeability values are positive in that cell.

 

Other than this, I don't think I can give more general advice.  If you're able (and willing) to share the input file then please feel free to do so by private e-mail and I'll have a look at it.

 

 

Best Regards,

 

Bård Skaflestad

SINTEF Digital, Mathematics & Cybernetics

Computational Geosciences group

--
You received this message because you are subscribed to the Google Groups "MRST-users: The Matlab Reservoir Simulation Toolbox User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sintef-mrst...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sintef-mrst/654acc28-b0a9-4ae5-8629-126fa6a8d3e8n%40googlegroups.com.

[Bård Skaflestad]

Hi Bertrand,

 

Thanks a lot for sharing the model.  I have looked into the problem and identified both the direct cause of the misleading diagnostic ("large negative skin…") and the underlying issue that explains everything.  Since your model uses the sentinel value "PORO = 99999" to signal "cell deactivated" I first added an "ACTNUM" field to the grdecl structure using

 

grdecl = readGRDECL(fullfile('path', 'to', 'MODEL.GRDECL'))

grdecl.ACTNUM = grdecl.PORO ~= 99999;

 

Having the ACTNUM field means that the subsequent grid generation using 'processGRDECL' has more information about which cells are active and can adapt its processing accordingly.  With this additional information in place I was able to form an MRST grid structure.  This in turn allowed me to determine the direct cause of the "large negative skin…" diagnostic which turned out to be entirely different from what I expected.  We calculate the cell extents in a way that preserves the cell volumes and in your model, our check for right-handed vs. left-handed coordinate systems did not return a conclusive result (link to live sources that will be part of the MRST 2022a release).  The model however uses a left-handed coordinate system so in the end we fail to run one of the crucial steps required to compute positive cell volumes in this case.

 

In other words, all of your model's (active) cells have a negative cell volume and that means that the cell extent/dimension calculation thinks that all cells have a negative thickness. Lateral extents are plausible however and this is the direct cause of the negative connection transmissibility factor.

 

There is one really ugly hack you can make in order to process this model.  If you replace the if is_lefthanded check in 'processGRDECL' with

 

if true % is_lefthanded(X, Y, Z)

 

then you'll get a fully working grid into which you can place wells.  This hack is obviously not tenable long term and will probably break all other models you may have.  We (the MRST team) need to make the "is_lefthanded" function more robust, but employing this hack will allow you to get on with your work.

 

 

Thank you, again, for sharing the model and I apologise for the poor diagnostic quality that lead us down the wrong path.

 

Best Regards,

 

Bård