On Wed, 2014-06-18 at 10:16 +0000, Joakim Hove wrote:
> > 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;
Agreed.
> 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.
Good point.
> 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.
Again, agreed.
>
> 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?
Keywords TRAN[XYZ] do not affect transmissibilities across faults. In
other words, we do not need to worry about that case.
>
> So – all in all I would say that we should be able to support MULTFLT
> also in the EDIT section;
I think you're right. You've outlined a very pragmatic approach. I
think we should run with suggestion.
> 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.
Yeah, that's too scary to think about.
> > 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
> >
> > [ ... elided ... ]
>
> OK – you might call me dim;
I'll do no such thing. As I said before, this is highly non-obvious
material.
> but I have finally understood why both MULTX and MULTX- are provided;
> I have always thought that to be a superfluous.
I'd personally like to indent the entire multiplier business six feet
downwards and cover it in dirt because it is so specific to the TPFA
method. Until we're able to do that, though, we have to implement the
protocol as defined by the input format.
> > 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-}
We may even want to make a slight modification to that scheme and to
keep the multipliers in a single array of arrays, indexed by direction,
so that references look like
mult_[dir][globix]
within the 'TransMult' methods. That way we will at least remove the
need for an if-else-based implementation of multiplier retrieval. We
may also consider supporting a calling interface like
getMultiplier(globix, dir)
in which 'globix' is the global cell index of an active cell rather than
"only" supporting the interface
getMultiplier(i, j, k, dir)
The reason is that, most of the time, within the simulator we don't have
the (I,J,K) tuple of each cell (that's derived/computable information),
but we *do* have easy access to the 'globix' through struct
UnstructuredGrid's 'global_cell' mapping. The implementation of the
latter would then be something along the lines of
double
TransMult::getMultiplier(const std::size_t i,
const std::size_t j,
const std::size_t k,
const Direction dir)
{
return getMultiplier(getGlobalIndex(i, j, k), dir);
}
I think using the two-argument version of getMultiplier will bypass a
certain amount of arithmetic (global->(i,j,k)->global index conversion)
and *may* be easier to use. At least from the point of view of the
current simulator facilities.
Bård
_______________________________________________
Opm mailing list
Opm@opm-project.org
http://www.opm-project.org/mailman/listinfo/opm
