On Tue, 2014-06-17 at 15:16 +0000, Joakim Hove wrote:
> Following the closed PR: https://github.com/OPM/opm-parser/pull/241 I
> have tried to read and understand how the MULT([XYZ])-? and
> FAULTS/MULTFLT keywords interact.
Much appreciated. This is intricate material.
> MULTX: This keyword is a multiplier for the transmissibility on the
> x-face between cells (i,j,k) and (i+1,j,k).
> MULTX-: This keyword is a multiplier for the transmissibility on the
> x-face between cells (i-1,j,k) and (i,j,k).
With the additional provision that we use cell (i,j,k) as the reference
cell, then yes. That's correct. MULTX modifies trans in positive 'X'
(strictly speaking 'i') direction, MULTX- modifies trans in negative 'X'
direction.
> Faults: The geometric concept of faults and the resulting NNCs is
> inferred automatically by inspecting the COORDS and ZCORN keywords.
> The FAULTS keyword is not related fault geometry in any way, it is
> only a convenient way to group many cell faces under a common name.
Correct.
> The MULTFLT keyword is used to manipulate the transmissibilities for
> all the faces in a fault.
Yes.
> The MULTFLT keyword works by manipulating the MULT([XY])-? keyword
> directly.
Sadly, that's only partially true. I wish it were that simple. The
*actual* specification says that if 'MULTFLT' is used in the *GRID*
section, then it acts as if keywords MULT[XYZ]-\{0,1\} are specified in
the appropriate manner. On the other hand, if 'MULTFLT' is used in
*EDIT* (or, shudder, *SCHEDULE*), then it modifies the trans values
directly. Basically, the processing model of 'MULTFLT' is tightly
coupled to the internal state machine of the ECL simulator in which the
complete graph exists, with associate connection strengths, the moment
we finish reading (and processing) GRID.
The best approximation we can implement in separate read/process passes
is probably to always modify the MULT[XYZ]-\{0,1\} arrays, however.
> Well – what about the NNCs created by the faults? I find it quite
> difficult to read this from the manual but my interpretation is as
> follows:
> 1. Assume that cells (i,j,k1) and (i+1,j,k2) have become
> connected via a fault induced NNC. Normal transmissibility
> calculations involving the permeabilities in the two cells and the
> face area overlap will give an initial transmissibility T0 between the
> two cells.
> 2. Through the MULTFLT keyword the MULTX/MULTX- arrays have been
> updated.
> 3. Depending on how the face between (i,j,k1) and (i+1,j,k2) is
> specified in the FAULTS keyword we will either look in MULTX(i,j,k1)
> or MULTX-(i+1,j,k2) for a transmissibility multiplier:
Actually, you need both. The 'correct' (major caveats) multiplier value
is the product of the two (*if* directional multipliers are used--item 1
of keyword GRIDOPTS).
From the point of view of a simulator, if there is an X-connection
between (active) cells c1 and c2, then the corresponding multiplier
value is
M = getMult(ijk(c1), X+) * getMult(ijk(c2), X-)
with ijk(c) denoting the (i,j,k) tuple of (active) cell 'c'.
> 1. The full support of MULTFLT behavior requires geometric NNC
> relations when assembling the grid.
Yeah... Strictly speaking it requires the complete simulation graph. I
don't think that's a useful pathway though as it will couple the parser
and simulator components too tightly together.
> Actually calculating the final transmissibilities mainly involves
> inspecting the FAULTS keyword and then looking up in the correct
> MULT([XYZ])-? array.
No, that's not correct. The direction specification in 'FAULTS' "only"
dictates which MULT array to modify. It doesn't say anything about
which array to use because we always use both. At least in the GRID
section. Treating MULTFLT according to the letter of the specification
in EDIT and SCHEDULE will have to be "best effort" in my opinion.
> 2. Got to think more about a good way to internalize this in the
> parser code; a pointer to the FAULT/NNC related callsites in opm-core
> would be good. I am moderately optimistic that the approach suggested
> in the original PR can still be used?
I don't think we'll be able to get away with a connection-based data
structure for multipliers. I really do think we need to preserve the
per-cell nature of the multiplier arrays (and, generally, to store six
values per cell).
Bård
_______________________________________________
Opm mailing list
[email protected]
http://www.opm-project.org/mailman/listinfo/opm
