CPR: “Новый” линейный солвер в Eclipse

Я всего неделю назад узнал о том, что в Eclipse начиная с версии 2014.1 реализован новый линейный солвер – CPR (этот метод конечно же далеко не новый, я бы даже сказал, что он с бородой, просто в Эклипс он появился совсем недавно). Солвер этот на деле оказался очень шустрым и помог мне справиться со проблемами сходимости в расчетах, с которыми старый добрый “ортомин” справлялся мягко говоря с трудом. Если бы я узнал о нем всего пару месяцев назад, то это помогло бы мне сэкономить уйму рабочего времени и потратить оставшееся на что-то более продуктивное, чем попытки стабилизировать и сократить время выполнения расчетов.

Собственно, во многих крупных компаниях установка нового софта происходит с некоторой задержкой по времени, наша компания также не является исключением. К примеру, только на прошлой неделе на моем локальном компьютере был установлен Eclipse 2014.1 (а на дворе конец 2015), на кластере обновление произошло несколько раньше, около полугода назад. Причины такого отставания, в том, что IT-специалисты должны убедиться, что новые версии стабильны, не имеют багов (точнее не имеют очевидных багов, все быги они выявить все равно не в состоянии), ну и чтобы ненароком не были потеряны проекты, над которыми специалисты трудились не один месяц.

Ну да ладно, речь не об этом. Я хотел привести сравнение времени выполнения расчетов с использованием нового солвера CPR и стандартного ORTHOMIN. Возможно, кому-то это также поможет сократить время расчетов и сэкономить бесценное время.

Итак немного информации, в наличии имеется не очень большая по современным меркам, но достаточно сложная модель месторождения V, с продолжительной историей, которое находится в разработке с 1982 года. Желающие могут почитать о месторождении тут (статья старая, но представление о месторождении дает). Ну и вот еще тут (тоже старое). Более свежие данные на сайте npd.no

Модель содержит около 800 тыс. активных ячеек. К данному моменту пробурено более 170 скважин. Месторождение истыкано разбурено вдоль и поперек. Из них на текущий момент в добыче меньше трети. Дальнейшая разработка, также предполагает разбуривание уплотняющими скважинами и “перебурами” преждевременно вышедших из строя скважин. Собственно в некоторых вариантах расчетов и возникали проблемы со сходимостью, причем зачастую варианты с большим числом скважин работали стабильно. Сначала мы пытались вылечить проблемы настраивая параметры сходимости в TUNING. Но проблемы все равно возникали, причем в разные даты и в разных скважинах. К слову сказать, траектории пробуренных скважин заданы несколько замысловатым способом, которые скорее всего и приводят к этим проблемам, но пока приходится работать с тем, что есть. Модель сматчена и передана, как есть. И на новый матчинг времени пока нет.

Стандартно расчет прогноза модели мы осуществляли на 16 процессорах на Linux кластере. Если при расчете модели не возникало существенных проблем со сходимостью, то расчет с добавлением новых скважин занимал около 4-5 часов. При этом если проблемы возникали, то расчеты могли идти до 48 часов, а зачастую и не завершались вовсе.

Использование солвера CPR позволило существенно сократить время расчета. К примеру прогноз на 30 с копейками лет, который при отсутствии существенных проблем со сходимостью обычно занимал 4-5 часов на 16 процессорах, а при наличии проблем до 24-48 часов, стал считаться около 1-2 часов на 8 процессорах.cpr

К слову сказать, что на модели, где полностью отсутствуют проблемы со сходимостью CPR по производительности был сравним со стандартным ORTHOMIN-ом.

На графике снизу сравнение солверов при отсутствии проблем со сходимостью (вариант расчета на 4 CPUs). На графиках видны замедления расчетов для обоих вариантов во время включения новых скважин:

cpr2

Для использования этого солвера достаточно в секции RUNSPEC прописать:

CPR
/

Подробности в мануале.

Share

Leave a Comment


NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>