Уважаемые коллеги!
В настоящее время для различных добывающих компаний остро встал вопрос как об оптимизации, так и ограничении добычи с месторождений. Особенно это актуально для компаний, добывающий газ, газоконденсат, нефть (на фонтане). Потому что, не секрет, что скважины, работая на энергии пласта активно взаимодействуют между собой как на устьях, так и в кустах, и могут "пережимать" друг друга. Для нахождения оптимальных тех режимов (с учетом различных ограничений) требуется большое количество времени и опыта и не факт, что данное решение будет оптимальным.
Компания Шлюмберже заботится о своих клиентах 
и, поэтому, мы не смогли стоять в стороне и смотреть, как мучаются наши клиенты, решая эти задачи.
Предлагаю вашему вниманию наше практическое решение, по расчету оптимальных тех. режимов скважин с учетом ограничений по каждой скважине.
Для расчета используются две программы - это PIPESIM и AVOCET IAM. Программный комплекс PIPESIM предназначен для моделирование физических процессов в системе сбора. Программный комплекс AVOCET IAM предназначен (в решении данной задачи) для оптимизации системы сбора.
Идея решения данной задачи проста как велосипед.
Изменяя диаметры суживающих устройств (штуцеров) мы можем видеть, как скважины взаимодействуют друг с другом и, соответственно, мы подбираем оптимальные диаметры суживающих устройств с учетом, как взаимодействия скважин друг с другом, так и ограничений по самой скважине.
Таким образом, возможно решать такие задачи, как ограничение общей добычи, так и расчета максимально возможной добычи с учетом давлений на входе в УКПГ/ДКС с учетом работы всех скважин.
Во вложенном файле находится более широкое описание решения данной задачи с примером.___________________Pipesim___Avocet_IAM.pdf
Блин, каким упоротым параноиком надо быть, что бы блокировать распечатку этой шняги... В топку такое заботливое SLB, проще GAP через RESOLVE к кейсам цеплять и оптимизировать систему.
Ну если проги сами выдают решение - то вещь отличная, особенно для цехов добычи...загнал всё в проги, они сказали, где что закрыть/открыть, чтобы максимум по нефти получить. Это так?
Кстати, подобное позволяет делать ещё и программа ReO - тоже сама может не только штуцеры, но и по всей системе задвижки зажимать/разжимать
Вопрос, в случае связки eclipse-avocet-pipesim для газового месторождения, как лучше связывать subsurface+surface network - по забою или устью?
И, если можно - подробнее о односторонней связи и обратной (я так понимаю).
Avers, исправил файлик. Зачем я его так засекьюрил - сам уже не помню. Теперь его можно печатать
Односторонней я называю связь, когда нет влияния инфраструктуры на пласт. То есть сколько из гидродинамической модели газа идет, то и такое количество поступает в трубопроводы. Обычно так работает связь на устье.Двухсторонняя или обратная, называйте как хотите, это когда мы видим эффект противодавления инфраструктуры на пласт. Например, на скважине закрутили штуцер, следовательно мы видим снижение добычи по этой скважине, также снижение забойного давления, влияние этого на дренируемую зону и перетоки в зону пониженного давления. То есть то, что мы и должны увидеть в реальности.PIPESIM_AVOCET_IAM.pdf
RESOLVE+GAP обещают, что это единственный в индустрии non-linear solver, в отличии от PIPESIM. На газе меня это привлекает.
Вообще, что больше всего напрягло в оффере PETEX, что для ECL+RESOLVE+GAP надо будет покупать Open Eclipse, о чем они молчали до последнего....
А нас счет связки ECL+AVOCET+PIPESIM со связью на забое - я так понимаю что это тот же ECL run просто с офигенно навороченными VFP...
P.S. Странно, если у PETEX все так круто, то почему газовики в России (Газпром, Новатек) активно используют AVOCET IAM для решения своих практических задач?
Ну это не серьезно, ссылаться на газпром как на авторитет...
А вообще - за инфу спасибо.
Идти далеко. Я на слово поверю.
Про Petex В России, на мой взгляд знают и используют его компании со значительным западным капиталом. К тому же у них нет своего офиса в России, да и по миру их всего 2 - в Эдинбурге и Хьюстоне. С поддержкой на русском языке у них не так как у вас - совсем никак.
Вот и делаем выводы почему Газпром выбрал Шлюм.
Далее. У Шлюмов вся разработка софта ведется за бугром, где и первоначально проходит проверку. Штаб-квартира разработчиков находится в Хьюстоне, разработчики софта все там друг друга знают
Здесь другой нюанс. PETEX, видимо, только сейчас увидел большую нишу и решил сделать попытку взять часть развивающегося рынка интегрированного моделирования. Поэтому и начинается пиар, а именно - "RESOLVE+GAP обещают, что это единственный в индустрии non-linear solver, в отличии от PIPESIM (не PIPESIM, a AVOCET IAM, видимо ошибочка).", как написал ранее Avers. Но, если AVOCET и его солвер в своем явном виде присутствует уже 5 лет (в виде FPT уже лет 10 или больше), то новому солверу PETEX совсем не так много
неленейный солвер для интегрированного моделирования не единственный это точно, например у эксона их симулятор сам имеет возможность интегрировать скажинны и поверхностную обвязку и решать всю эту систему вместе с пластом при граничном условии на пункте сбора, а не на скважинах. Из личного опыта: интегрированная система и ее оптимизация будут давать полезные результаты только тогда, когда каждая скважина будет замэтчина идеально и по газовому фактору и по обводненности и по давлению, плюс VLP таблицы должны соответствывать действительности во всех диапозонах упомянутых параметров. Короче, больше времени будет уходить на хистори матчинг. А то получится так - даже если не бъется одна скважина, будет не биться куст, далее будет не биться месторождение и вся система сбора с нескольких месторождений.
Такой подход (интегрирование пласта и системы сбора) более оправдано на морских месторождениях где скважин мало, дебиты большие и система сбора имеет обычно одну точку сбора (FPSO). В "газпромовской" же действительности где куча скважин, где скважины с одного пласта могут быть подключины к разным системам сбора (разные ГПшки), где VLP таблицы расчитываются еще только при планировании и не калибруются потом, где нет адекватных замеров на индивидуальных скважинах (в лучшем случае с куста), где часто нет даже манометров на головах (не говорю уже про забойные) навязывание этого продукта видется как способ срубить денег.
Вообще интегрированное моделирование это уже следующий этап моделирования, где больше входных параметров в разы, которые еще более усложняют процесс моделирования и прогнозирования. И поэтому переход к этому этапу целесообразен только когда предыдущий этап (простая гидродинамическая модель) выполнена на 5+, что в большенстве своем unreal.
Ты совершенно прав. Ни разу не видел и не слышал, чтобы кто-нить связывал 30 кустов (5-10 скважин на каждом) с наземкой...Причины:
1. ППЦ какая недостоверность данных по скважинам
2. Постоянное беЗконечное изменение на скважинах+изменение наземки+полуприкрытые задвижки+человеческий фактор...Следовательно модель сделать невозможно...
Блин, просто получить данные по существующим наземным трубам - ОГРОМНАЯ проблема, а тут еще и правдивые данные по скважинам, правдивые, а не то, что называется техрежимом и делается так "размазанно", подогнанно...
В общем в нашей действительности - чушь и не будет работать, как и попытки ТНК-ВР сделать интегрированную модель актива...делал-делал энтузиазист один, так и ничего не пошло, и не пойдет...
Кроме этого единственного продукта есть еще связка Welflo+ReO своими глазами видел как эта связка работает на нефтегазоконденсатном месторождении с 200 скважин. Время расчета меньше 30 минут, на выходе техрежим по скважинам + техрежим УПН
Скорее всего pevgen здесь приводит пример с 30 минутами где рассчитывается и оптимизируется система на один определенный момент времени и эта система не имеет связи с гидродинамическим симулятором. Возможно роль ГД симулятора здесь выполняет прога для материального баланса - тогда еще верится в 30 минут, но это не то о чем говорилось в начале топика как я понял. Если же сама ГД модель считается на прогноз скажем 6 часов, то со связью с объвязкой время расчета будет всегда >6 часов.
Роль ГД симулятора здесь выполняют ИД по скважинам и заданный тренд изменения Рпл. Для коротких времен вполне допустимая вещь, ГД модель пересчитывается раз в месяц по итогам эксплуатации.
Пока разбирался с форумом воткнул пост не в ту тему. Товарищи админы воткните пост в PipeSim - обмен опытом работы или сделайте кнопку удалить пост или снесите пост.
Хочу поделиться своим опытом работы с PipeSIM, возможно это кому-то пригодится, а возможно это баян.
Сейчас пробую просчитать интегрированную модель в Avocet, не получается задать расход как граничное условие на стоке сети. Пишет, что не задан конечный узел (No terminal node for task...). Если поставить минимально возможное давление то о крайней мере связка eclipse-pipesim-avocet аботает, но я считаю, что это не правильно.
а есть какой-то русский материал по этой мегапроге, чтобы ясно стало, где какие данные нужны? :)
To karakurt2
Граничные условия в Пайпсимовской модели с давления на расход поменяйте.
To Nike
Проще подъехать и показать. Из русских материалов - только рекламные брошюры на сайте Шлюма.
Рекламные брошюры само собой смотрели:)
Интересно, как думает этот продукт.
Например, взять простенькй вариант, когда управление идёт по групповому отбору, есть ограничение по забойному давлению и задано давление на БВН.
Какова сама последовательность его вычислений?
Пробую Avocet для газового месторождения. Возникает та же проблема, что и у karakurt2.
Ограничения на скважинах - давления. Задаю расход как граничное условие на стоке сети, и запускаю совместный с Eclipse расчет, пишет: No terminal node for task....
В качестве опции балансировки поставил Full IPR.
Как я понял, на стоке необходимо поставить ограничение в виде давления, а перед ним штуцер. И на каждой итерации подбирать диаметр этого штуцера, чтобы сеть сходилась (что-то типа автоматического штуцера в опции Network в Eclipse). Но прописать этот штуцер никак не получается?
Может быть у кого-нибудь есть пример? Можно и на английском...
NET32COMLib.INetModel на 64разрядной системе выдает ошибку (понятное дело). как быть? OPenLink на 64bit работает?
второй вопрос как просмотреть по всем скважинам чоки в табличном виде.
OpenLink работает на 64 битной ОС, но не работает обращение к нему средствами VBA из 64 битного MS Office.
По второму, средствами PipeSIM это не сделать никак, только самаму из своей программы.
т.е. никак эту зад..цу не побороть?
Установи 32 битный офис, либо напиши приложение на каком нибуть языке программирования, либо создай библиотеку которая будет обращаться к OpenLink и подключить её в своих VBA макросах.
ок. офис 32 бита стоит. винда 64 бита. запускаю макрос Опенлинк и ошибка на строке Dim NetModel As New NET32COMLib.INetModel
что это может быть?
1. Установлена ли "олдскульная" версия PS 2012.2 ?
2. В VBA в меню Tools->References стоит ли галочка на Net32COM.
Текст ошибки тоже не помешает увидеть.
что то произошло, но ошибка пропала. шайтан блин. спасибо