On Mon, 2014-06-30 at 19:28 +0200, Andreas Lauser wrote:
> The TD also says that the cell transmissibility T_j is not necessarily
> the logically-Cartesian neighbor and the figure used for illustration
> purposes also clearly shows a non- conforming grid...
Like I said, fault transmissibilities don't go in TRAN[XYZ]. They
obviously must be calculated, though.
> > What problem are you trying to solve?
>
> the problem is that I want to include the NTG and MULT[XYZ]-? keywords
> in the transmissibility calculations
Is this related to PR 606 in opm-core? I thought I already outlined my
preferred approach in that case. Those modifications should go in
DerivedGeology's constructor. You don't need to do anything to the
low-level transmissibility calculations. Function tpfa_htrans_compute()
calculates one-sided ("half-face") transmissibilities while
tpfa_trans_compute() performs the final harmonic averaging.
Function tpfa_htrans_compute() defines the one-sided transmissibilities
as
T_ij^i = (n_ij^i' K_i c_ij) / (c_ij' c_ij)
with "n_ij^i" being the outward-pointing (with respect to cell "i")
normal vector of interface "ij", "K_i" being the (full) permeability
tensor of cell "i", and "c_ij" denoting the centroid vector from the
centroid of cell "i" to the interface centroid of interface "ij" (and
"x'" denoting the transpose of vector "x"). That's a very traditional
definition of the transmissibilities.
> and that IMHO the C code obscures what it does quite effectively. More
> relevantly though is that I'm not really sure that the C code does the
> right thing in the first place, so even if I go for a modification of
> the existing C functions, I'd like to understand why they do what they
> do and how it relates to the Eclipse documentation...
Don't change the C functions.
Bård
_______________________________________________
Opm mailing list
[email protected]
http://www.opm-project.org/mailman/listinfo/opm
