PIPESIM, AVOCET IAM - увеличение быстродействия

Последнее сообщение
MironovEP 2019 15
Мар 15

Коллеги в разных темах освещалась тема увеличения быстродействия расчетов. хотел бы собрать все воедино и для новичков (так сказать шкурный интерес). Где в системнике отверточкой покрутить, что бы Пипесим быстрее начал считать?

Eric_Cartman 135 14
Мар 15 #1

а что у системы проблемы со скоростью? Можно подробнее, насколько увеличивается расчет по сравнению с просто расчетом Эклипса?

MironovEP 2019 15
Мар 15 #2

ну конкретно если про Авосет и Eclipse говорить, то я не замерял 1 итерацию, но при учете системы собра модель ищет решения с заданной точностью, от чего соответсвенно увеличивается время. пока это все что я могу сказать, т.к. сам не сравнивал.

меня даже просто время расчета моей модели в пайпе не устраивает. 

WadiAra 162 12
Мар 15 #3

Есть ряд методов для ускорения расчетов в PipeSIM, первую часть можно использовать из графического интерфейса приложения, вторая часть для тех, кто активно балуется Open Link, третья больше для программистов или тех, кто может их озадачить. C PipeSIM+AVOSET IAM почти все эти фокусы не будут доступны.
Общий случай, для тех, кто работает с графическим интерфейсом PipeSIM.
1. Из-за того, что PipeSIM активно работает с жестким диском, генерирует в каталоге модели файлы для движка (.pst, .tnt, .pwi) и сохраняет результаты расчетов (.plt, .rst, .sum, .out, .pns, .pnsx), симулятор тратит много времени на ожидания завершения операций ввода-вывода. Перенос расчетов на RAM диск (диск в памяти) снимет эту проблему. Для еще чуть большей производительности можно сам симулятор перенести на RAM диск, а в модели прописать новый путь до «Network Engine». Это работает только с PS 2012.2 и ниже для PS 2013-2014 «нового поколения» расчет происходит во временном каталоге пользователя «C:\Users\пользователь \AppData\Local\Temp\PIPESIM», а значит, положительного эффекта от переноса модели на RAM диск не будет.
2. Рабочий каталог, где производятся расчеты или RAM диск прописываются в исключения антивируса, причина аналогична предыдущему пункту, только ждать будем антивируса, который пока не проверит, не отдаст симулятору файлы движка и результатов расчета.
3. Если многократно рассчитываем модель сети с добывающими скважинами без изменения их параметров IPR и конструкции, то можно воспользоваться свойством объекта Production Wells - Well Curves, с опцией Create only when necessary. Первый расчет из-за генерации pwi файлов будет медленней обычного вычисления, зато последующие пройдут намного быстрее, если же меняем параметры скважины необходимо удалить pwi файлы в каталоге модели.
4. Для ограничения дебита скважины можно использовать не штуцер, который еще надо подобрать, а разделить шлейф от скважины до манифольда на два и в ближнем к скважине элементе Branch изменить свойство Limits Gas на нужный расход. Теперь Branch не пропустит через себя газа больше чем задано, тем самым мы сможем симулировать уставку регулятора (автоматического штуцера) по максимальному расходу газа.
5. Использование, где это можно и нужно модели флюида Black Oil вместо Composition тоже даст плюс к скорости.
6. Рекомендую использовать только PS 2012 и ниже, не пользоваться PS 2013-2014 «нового поколения». Эти версии отличаются только графическим интерфейсом и генераторам файлов движка (.pst, .tnt, .pwi). Сам генератор файлов математического движка в PS 2013-2014 кроме того, что работает медленней, так еще и при этом кривой, т.к. округляет заданные значения так, что расчеты в разных версиях (если запускать из GUI) не совпадают. Кроме этого при нормальной реализации сложные приложения на WPF работают быстрее (за счет DirectX) и визуально выглядят лучше, чем аналогичные на Windows Forms, но интерфейс «нового поколения» почему-то получился тормозным и глючным.

Добавим Open Link.
1. В 2012 году в PipeSIM наконец была добавлена через Intel MPI поддержка многопроцессорных расчетов, но не все так гладко. Предположим, рассчитываем промысел по заданному давлению на стоке, с 4 шлейфами по 6 скважин на 4 процессорной системе. Параллельный расчет этих 4 шлейфов (1 процессор на шлейф) пройдет быстрее, чем одной большой модели на 4 процессорах, чем больше процессоров и шлейфов, тем преимущество такого подхода выше. Можно комбинировать параллельный расчет шлейфов и использование Intel MPI, на 12 ядерной системе считать 4 шлейфа используя по 3 ядра на один шлейф или если у одного шлейфа существенно больше скважин, чем у остальных выделить ему большее количество расчетных ядер. Заметил, если использую по 2 ядра на модель, происходит замедление расчетов, а не ускорение.
2. Когда мы используем Well Curves в расчетах (жирный газ, задавливание скважин, много расчетов) PS генерирует нам pwi файлы, ни чего нам не мешает также как и в предыдущем методе (параллельно) сгенерировать их. Предварительная генерация pwi файлов с последующим расчетом будет быстрее, чем расчет модели со стандартной генерацией PWI файлов.

Дожмем PipeSIM.
1. Берем сервер (чем больше ядер, тем лучше), делаем RAM диск, пишем сервис расчета моделей PS. Его задача получить от клиента файлы движка PS (.pst, .tnt, .pwi), рассчитать у себя на RAM диске, а клиенту вернуть результаты расчетов (.plt, .pns, .pnsx). Весь обмен данными пакуем на лету. Файлы математического движка получаем через Open Link, через него же читаем результаты. Если у нас больше чем одной лицензии PS делаем кластер, где на одном сервере крутится сервер распределения нагрузки, на остальных расчетные сервера. Плюшек от таких решений три, кроме скорости, мы минимизируем количество лицензий, количество рассчитываемых задач и пользователей их установивших может быть больше чем количество лицензий, клиентский же ПК можно подбирать по остаточному принципу, ведь расчеты будут идти удаленно.
2. Если есть БД, где содержится конструкция скважин, сети сбора, состав газа, продуктивные характеристики, мы можем создать файлы математического движка на лету. Значит, пишем сервис генерации моделей, который получает задачу от клиентов, считывает необходимые данные из БД, генерирует на их основе файлы математического движка PS и передает их на расчет выше описанному серверу, получает файлы результатов, парсит их и возвращает клиенту структурированный ответ. Т.к. PipeSIM в фалы движка сует все, даже не активные ветви сети и скважины, то ваши модели еще и рассчитываться будут чуть быстрее, а если на стороне сервера задействовать кеширование часто запрашиваемых данных (данные скважин и сети сбора), то и генерация моделей будет быстрее. А самый главный плюс в том, что мы можем параллельно рассчитывать один объект (в случае OL для этого пришлось бы копировать модель по каталогам) на куче режимов, больше не зависим от файлов моделей, нам не требуется их обновлять и вообще держать на пользовательских ПК, как модели, так и PS.

На этом все, дальнейший ощутимый прирост производительности возможен либо с наращиванием мощности используемой аппаратной части, либо после изменения расчетного движка PipeSIM.

MironovEP 2019 15
Мар 15 #4

исчерпывающе.. видимо вы больше программист чем разработчик)) потому что я кроме слова "компьютер" мало что понял))))

надо умные книги почитать. 

спасибо... надо переварить

volvlad 2196 17
Мар 15 #5

Зачастую ответ очень рядом. Из своей практики могу сказать, что для увеличения быстродействия расчетов в системе сбора, иногда достаточно переключиться на использованием более простых эмпирических корреляций, т.е. заменить сложные механистические модели. Если это возможно. (Это правда из опыта использования PETEX IPM)

WadiAra 162 12
Мар 15 #6

Тогда ещё стоит проверить при композитной модели флюида параметры Branch ей. Везде ли выставлен Always Interpolare (fast) в Temperature Energy Balance и Physical Property вкладки Compositional Flashing. Если не считаешь переохлажденные гидраты необходимо отключить Enable Hydrate Subcooling Calculation вкладки Heat Transfer Options.

WadiAra 162 12
Мар 15 #7

Рекомендую иметь на всей модели одну и туже корреляцию течения флюида.

MironovEP 2019 15
Мар 15 #8

мне вот инетересно про RAM. где что надо нажать/прописать?

Максим Шинкарёв 2 8
Мар 16 #9

В качестве промежуточного средства можно добавить минимизацию использования интерфейса при множестве расчётов.
Так как симуляторы пайпсима работают отдельно от интерфейсной части, то имеет смысл создавать очередь расчётов.
На примере генерации VFP по куче скважин - открыть диалог, выставить настройки, нажать "Run model" и тут же погасить открывшееся окно консоли. Все нужные файлы, включая файлы моделей и запускные bat-ники, будут сгенерированы.
После этого перейти к другой скважине, точно так же получить расчёт, остановить его и т.д.
После этого можно вообще закрыть пайпсим, собрать все имена bat-ников, сложить их в отдельный файл вида
call run1.bat
call run2.bat
...
где run1, run2 и т.д., после чего запустить уже его.
Профит в том, что такую очередь можно оставить считаться на ночь, и не надо дежурить у приложения, чтобы начать новый расчёт, когда один закончится.

Понятно, что самым правильным было бы написание макроса с опенлинком, чтобы всё само собой генерировалось и запускалось, но иногда это бывает быстрее, если операция одноразовая.

Просто приходилось наблюдать, как люди сидят прикованные к машине, ждут окончания одного и начала другого расчёта, чтобы перещёлкнуться от одной скважины к другой и нажать кнопку запуска.

Кроме того, полученный массив расчётов (файл с call run) можно просто распараллелить - разбить его на нужное количество частей и запустить их независимо.

Go to top