TRANX=0

Последнее сообщение
Dorzhi 894 12
Апр 13

Увидел, что в модели TRANX = 0 в последних ячейках по оси X (I). Никаких явных заданий TRANX нет. Это баг или так и нужно?

AGA 752 7
Апр 13 #1

А по Y также?

Dorzhi 894 12
Апр 13 #2

ага, так же

RomanK. 2158 11
Апр 13 #3

The presence of the COORD keyword implies corner point geometry and the automatic generation of fault transmissibilities.

Край модели это разлом, который автоматически обрамляется TRANS=0
Любой разрыв в координатной сетке приводит к такому поведению:

Dorzhi 894 12
Апр 13 #4

а если аквифер подцепить к этим ячейкам? или это только в одну сторону работает?

RomanK. 2158 11
Апр 13 #5

Судя по тому, что Аква срабатывала, транс ноль не влияет. Так же описано, что не повлияет и на NNC. Для примера, в этой модели мне нужно было сшить пласт с двух сторон разлома структуры. Хотя и в начале и конце NNC tranx=0 соединение работает. В tempest поведение было не такое, там при геометрическом разрыве структуры, не возникало препятствия для течения и мы уже руками прописывали trans=0 иначе эффекты потрясают воображение. Надеюсь сейчас roxar исправил этот деффект

AGA 752 7
Апр 13 #6

Не знаю прав я или нет. Но похоже, что делали апскейлинг проницаемости с использованием опции Flow-based.
Получется, что у потока не возможности пойти за грань, поэтому проницаемость там скорее всего нулевая. Соответственно и проводимость. ИМХО.

AGA 752 7
Апр 13 #7

Dorzhi, покажи картинку, пожалуйста =)

RomanK. 2158 11
Апр 13 #8

Конечно это не так, я в здравой памяти апсейлить проницаемость не стану :) Там где TRANX=0 проницаемость больше нуля.
А картинка показана же, по краю модели видно обрамление из нулевой проводимости.

EmptyEye13 101 12
Апр 13 #9

RomanK. пишет:
Конечно это не так, я в здравой памяти апсейлить проницаемость не стану :)

это как? то есть по апскейленным ячейкам заново с логов заполнять ?

RomanK. 2158 11
Апр 13 #10

Логов проницаемости? Используют хреновую зависимости проницаемости от пористости и далее в процессе адаптации приходят (или нет) к некоторой общей зависимости (возможно и с локальными изменениями) позволяющей скорее более, чем менее повторить продуктивность скважин.

Dorzhi 894 12
Апр 13 #11

апскейлинга не было, картинка в целом такая же как Романк нарисовал

panchik 209 8
Апр 13 #12

Dorzhi пишет:

TRANX=0Увидел, что в модели TRANX = 0 в последних ячейках по оси X (I). Никаких явных заданий TRANX нет. Это баг или так и нужно?

Так нужно. TRANX - свойство поверхности между ячейками. Поверхностей всегда по крайней мере на одну меньше, чем ячеек. У крайних ячеек с "этой" стороны просто нет соседей.

RomanK. 2158 11
Апр 13 #13

Развернутое описание есть в Техническом Описании: Transmissibility Calculations

The third form is based upon the use of cell corner points, which are available to ECLIPSE when
the COORD/ZCORN form of grid definition is used. In this case, it is possible to distinguish
unambiguously between cell dip and fault displacement, and this option allows fault
transmissibilities to be generated automatically.

For ECLIPSE 100 use, this third type of transmissibility calculation is specified by the
use of the NEWTRAN keyword in the GRID section. This is the default calculation when
COORD/ZCORN are specified.

Упоминается, что такой подход приводит к несовместимости с другими симуляторами, которые делают расчет проводимости только исходя из свойств ячеек, но не учитывают их геометрическое взаимное положение. Для возвращения к "обычному" методу используется слово OLDTRAN и OLDTRANR
 

Dorzhi 894 12
Апр 13 #14

я собсна так и понял, но что меня смутило, то что свойства TRANX- явно нет, а TRANX=0 только на последних ячейках. Получается , что TRANX зависит от направления. Почему же тогда TRANX- явно не задается?

The values specified overwrite the X-direction transmissibilities calculated by ECLIPSE for the 
+X face of each grid block. Thus, a value specified for block (I, J, K) is the transmissibility 
between blocks (I, J, K) and (I+1, J, K). 

AGA 752 7
Апр 13 #15

Есть TRANy есть TRANx и TRANz... соответственно по направлениям если нет связи, то и обнуляются они.

Dorzhi 894 12
Апр 13 #16

нет, я об обратном направлении между I и I-1, аналогично и  J, J-1

RomanK. 2158 11
Апр 13 #17

Dorzhi это выглядит как некритичная "неточность" алгоритма. Мне кажется, толку от зануления краевых нет, да и видимо так оно и есть, потому как не объяснимо почему по возрастанию зануляется, а по убыванию нет. Бесполезная фишка :)

Dorzhi 894 12
Апр 13 #18

вово, я и говорю баг какой-то. ну да фиг с ним раз некритично

Go to top