On the other hand, if 'MULTFLT' is used in *EDIT* (or, shudder, *SCHEDULE*),
then it modifies the trans values directly.
The SCHEDULE section I think is unrealistic to support initially; as for the
EDIT section my understanding of the situation is that it is mostly relevant if
the TRAN[XYZ] keywords are used to supply transmissibilities directly. So for
MULTFLT in EDIT section:
1. If the TRAN[XYZ] keywords have not been used – MULTFLT in EDIT section
and MULTFLT in GRID section is 100% equivalent in our two pass parse and
process setup.
2. If the TRAN[XYZ] keywords have been used we should multiply the
supplied TRANX vector with the MULTX multiplier – and completely bypass the
internal grid processing calculations. It is not clear to how – if at all –
FAULT connections are supported with the TRANX keyword?
So – all in all I would say that we should be able to support MULTFLT also in
the EDIT section; the only hiccup as I see it is that the use of MULTX- is not
really well defined in that case. At least not if TRANX has been supplied in
the deck. This is exotic stuff anyway.
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'.
OK – you might call me dim; but I have finally understood why both MULTX and
MULTX- are provided; I have always thought that to be a superfluous.
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).
I agree – we will need to hold on the all six arrays: {MULTX, MULTX-, MULTZ,
MULTZ-, MULTY, MULTY-}
Joakim
-------------------------------------------------------------------
The information contained in this message may be CONFIDENTIAL and is
intended for the addressee only. Any unauthorised use, dissemination of the
information or copying of this message is prohibited. If you are not the
addressee, please notify the sender immediately by return e-mail and delete
this message.
Thank you
_______________________________________________
Opm mailing list
Opm@opm-project.org
http://www.opm-project.org/mailman/listinfo/opm
