ошибка картопостроения Petrel

Последнее сообщение
k-159 261 16
Май 15

Коллеги, добрый день!

Кто-нибудь сталкивался с некорректным картопостроением в Petrel?

Суть проблемы в следующем. Есть моделька Eclipse - однородный кубик с пятиточкой. Загружаю в Petrel, строю карту средней нефтенасыщенности на последнюю дату расчета - карта несимметрична, распределение смещено на северо-восток. Если построить грид среднего по слоям, то все выглядит логично-симметрично.

Если такая фигня получается на всех картах, построенных в Petrel, то это может привести, например, к неправильному расположению ЗБС на карте остаточных запасов.

В Irap RMS попробовали построить, все ровно получается  - без косяков. В tNavigator, понятно, тоже.

ВложениеРазмер
Иконка изображения Карта среднего97.53 КБ
Иконка изображения Среднее по слоям в гриде43.51 КБ
Иконка простого текстового файла датник8.19 КБ
volvlad 2196 17
Май 15 #1

Хм, не сталкивался с подобным, сейчас ради интереса проверю.

volvlad 2196 17
Май 15 #2

В общем, да действительно так. Но багой это назвать нельзя, скорее это у них такая фишка (правда кривая).

А дело в том, что при картопостроении из грида строится сетка подобная сетке грида, узлы в тех же местах, что и узлы грида, а в качестве знан\чений на узлах берутся средние 2 ячеек (каких именно будет зависеть от MAPAXES). В данном примере 2-х нижних.

В общем если бы осреднялись все 4 соседние ячейки, думаю, что ассиметричность пропала бы.

 

Короче надо им писать, чтобы думали))

 

Вложение: 
volvlad 2196 17
Май 15 #3

И кстати, если нужно вот вариант для исправления,

- делаем копию карты, и сдвигаем на шаг ячейки по оси J (в вышеуказанном примере на 100 метров вниз, т.е. вычитаем 100 м.)

- через калькулятор строим новую карту как среднюю оригинальной и сдвинутой на 100 метров.

k-159 261 16
Май 15 #4

"Это не баг, это фича" - любимая шутка программистов ))

На самом деле, при планировании ЗБС никто не будет размышлять про эту "фишку" и в итоге запланируют ствол на 141 м (точнее на корень из суммы квадратов размеров ячеек в модели по Х и У) в сторону. Понятно, что результаты расчетов ГДМ обладают некоторой неопределенностью, но тут еще вводится дополнительная неточность, которой нет в другом софте.

Вывод: Petrel для картопостроения не годен.

k-159 261 16
Май 15 #5

volvlad пишет:

И кстати, если нужно вот вариант для исправления,

- делаем копию карты, и сдвигаем на шаг ячейки по оси J (в вышеуказанном примере на 100 метров вниз, т.е. вычитаем 100 м.)

- через калькулятор строим новую карту как среднюю оригинальной и сдвинутой на 100 метров.

Этот вариант не даст полного соответствия карты кубу. Просто немного размажет ошибку по площади.

DimA1234 360 16
Май 15 #6

volvlad пишет:

В общем, да действительно так. Но багой это назвать нельзя, скорее это у них такая фишка (правда кривая).

Дело, видимо в том, что в ячеистой сетке берется среднее по ячейке, а 2Д грид оперирует только узлами - точками в углах ячеек.

Может быть, попробовать осреднять сетку с ячейкой 50х50 м на 2Д грид с ячейками 25х25 м (5х5 м)?

k-159 261 16
Май 15 #7

DimA1234 пишет:

Может быть, попробовать осреднять сетку с ячейкой 50х50 м на 2Д грид с ячейками 25х25 м (5х5 м)?

Да, идея норм. Только надо как можно меньше ячейки делать, чтобы смещение было меньше. Правда при этом получается выраженная ячеистая структура, т.е. карта не такая гладкая-красивая получается ))

Можно засмусить потом в принципе

volvlad 2196 17
Май 15 #8

k-159 пишет:

Этот вариант не даст полного соответствия карты кубу. Просто немного размажет ошибку по площади.

А какая разница, контуры карты так и так не на 100% соответствуют кубу, карта это все равно своего рода осреднение. И такой способ все равно лучше, чем вариант по умолчанию. Хотя меня лично и вариант по умолчанию вполне устраивает.

Второй сопособ построения, чтобы избежать сдвигов карты и осреднения, сделать сразу осредненное свойство , например, So=(So+So[i,j+1)/2] а затем по осредненному свойству строить карту. Но это снова осреднение.

Ну и еще вариант, сваять плагин. Есть желающие? :)

DimA1234 360 16
Май 15 #9

Ещё можно попробовать грид 50х50 м сдвинуть на 25 м так, чтобы узлы 2Д сетки оказались точно в центре ячеек 50х50 м.

И потом осреднять 3Д свойство уже на эту сдвинутую 2Д сетку.

FullChaos 834 16
Май 15 #10

Use pillar grid angle при осреднении спасёт вас.

volvlad 2196 17
Май 15 #11

FullChaos пишет:

Use pillar grid angle при осреднении спасёт вас.

Ну вот, а ларчик просто открывался) И кстати результат получился один в один как при осреднении, который я описал выше... 

Вопрос только что конкретно они делают, для меня лично определение "use pilar grid angle" не совсем очевидно.

 

k-159 261 16
Май 15 #12

FullChaos пишет:

Use pillar grid angle при осреднении спасёт вас.

Смещение все-равно остается/

Написал в техподдержку, надеюсь исправят в следующих версиях. Пока написали то же самое - осреднять на сетку с меньшим размером.

Celebrity 1578 16
Май 15 #13

Цитата:
Вопрос только что конкретно они делают, для меня лично определение "use pilar grid angle" не совсем очевидно

видимо просто учитывает угол наклона направляющих сетки по вертикали. Те рассчитывает по направлению IJ, а не XY. 

DimA1234 360 16
Май 15 #14

А таким макаром сетку сдвигали-то?

http://www.petroleumengineers.ru/node/9932#comment-82775

===

Ещё можно попробовать грид 50х50 м сдвинуть на 25 м так, чтобы узлы 2Д сетки оказались точно в центре ячеек 50х50 м.

И потом осреднять 3Д свойство уже на эту сдвинутую 2Д сетку.

===

FullChaos 834 16
Май 15 #15

k-159 пишет:

FullChaos пишет:

Use pillar grid angle при осреднении спасёт вас.

Смещение все-равно остается/

Написал в техподдержку, надеюсь исправят в следующих версиях. Пока написали то же самое - осреднять на сетку с меньшим размером.

у меня всё нормально

 

Вложение: 
Go to top