Дек 08
Опыт моделирования больших месторождений (в смысле много ячеек). Что делаете если симулятор не тянет ? Какими путями уменьшаете размерность модели ? Используете ли секторные модели ? Какое rule of thumb используете для размерности модели, времени счета и т.д. Интересует в первую очередь практический опыт.
Опубликовано
16 Дек 2008
Активность
47
ответов
5690
просмотров
15
участников
0
Рейтинг
>500 это в тысячах?
Да вроде Eclipse и CMG все что угодно тянут. Что значит "не тянет"? Неделю считает? Две? На своем скромном опыте не видел моделей, которые бы не потянула парочка Xeon'ов. Другое дело, если в модели серьезные косяки есть...
Недавно был на семинаре CMG. Показали такую классную штуку, как Dynagrid. Динамическое укрупнение/уменьшение ячеек в зависимости от величины перепадов параметра (давление, температура, и. т.д.). Cчитали SAGD в STARS. Двухкратное ускорение. Сам пробовал.
Не тянут в смысле тебя, как инженера, не устраивает производительность имеющейся системы или вообще модель не может быть запущена. Для каждой конфигурации есть свой потолок, просто он разный. Динамическое укрупнение это как один из вариант оптимизации проблемы. Ни разу не встречал этого, интересно какие есть ограничения плюсы минусы и выйгрыш данной технологии ?
Назовем это путь оптимизации вычислений 1)
Второй путь это оптимизация самих моделей 2).
Интересно было бы сравнить где какой выйгрыш и в чем, основываясь на опыте участников.
Вижу что геолог
Ответ: да.
Принцип такой: сначала делается модель достаточно высокого разрешения, а потом по заданным параметрам симулятор ее укрупняет и снова измельчает. Вначале все ячейки укрупняются по заданной схеме (например, 10 в одну или 20 в одну). Потом, например, если перепад давления между ячейками выше заданного значения (т.е. значительный) ячейки снова разбиваются. И также обратно.
Наилучшие результаты дает при моделировании фронтальных процессов (тот же SAGD, ISC, и т.п.). Primary production, скорее всего, не удастся ускорить в два раза. Главный недостаток проявляется в очень неоднородном пласте, когда объединение ячеек по сути дела засирает геологическую модель. В принципе, при умной настройке можно приспособиться.
Еще можно упростить fluid model, numerical, и пр.
Тебя, насколько я понял, больше всего интересует upscaling. Это целая наука. Я бы не стал сильно этим заниматься без большой необходимости.
до миллиона ячеек 32битная винда тянет. больше уже оперативы не хватит на винде по крайней мере, нужно распараллеливание или 64битную ос
В чем проблема, давно уже существуют кластера для расчетов. У меня например на работе персоналка не слишком сильная. Да и какая разница, если только результаты просматривать. А скорость расчета даже самых больших моделей настраивается...правда с некоторыми оговорками, уже на раз звучавшими на форуме
Шкала размерностей немного странноватая. Почему потолок “>500”? Складывается впечатление, что основной путь решение Вашей проблемы – приобретение нормальной 64битной рабочей станции + распараллеливание. Так Вы сможете добиться ускорения примерно 3-6 раз в сравнении со счетом на хорошем ноуте. Все таки это более дешевый и рациональный способ ускорения, нежели возится с абскейлингом.
По поводу Dynagrid в CMG, насколько помню, эта опция была только в STARS, а спрашивают про black oil.
Ответил 150-250, хотя есть достаточно большое кол-во моделей из категории 50-150. Как правило, у нас это очень мелкие месторождения или средние без истории, для получения первых прикидочных результатов...
На более крупных, делаем модели с бОльшим числом ячеек.
Главные критерии при выборе сетки - разумное время расчета, при сохранении геологических особенностей (гетерогенность, непроницаемые слои и пр)... Для меня разумным временем является - несколько часов...
Хотя могут возникнуть такие задачи, для которых время расчета не столько критично, сколько точность полученных результатов... В общем, все зависит от поставленных целей и задач.
Размеры ячеек по горизонтали, как правило 50*50 метров, для совсем мелких месторождений меньше...
По вертикали при выборе средней тольшины слоя стараемся делать не более чем 1-1.5 метра, если ячеек получается не слишком много и модель считается стабильно, приводим к 0.5 метрам...
В районе горизонтальных скважин, если геометрия достаточно сложная делаем LGR.
Акьюфер максимально обрезаем или делаем coarsening.
Будут более мощные машины и модели станут более детальными...
Кластеры существуют, но не у всех есть, к сожалению...У нас например нет, считаем на обычных рабочих станциях с двумя Xeon-ами..
Пользую ECLIPSE. Правила использую простые:
1. Если модель считается больше часа ... значит неправильная модель.
2. Ограничение площади по внешнему контуру ВНК + 2-3 ячейки и акъюфер.
3. MINPV (очень помогает - чем меньше в модели маленьких ячеек тем реже предстоит дробить шаг из-за того, что объем флюида проходящего через ячейку за один тайм степ сравним с объемом ячейки).
4. Укрупнение по Z.
Из не прозвучавшего - контроль "адекватности" работы скважин и переменный временной шаг. Вначале по годам, потом по пол года, по три месяца ... и лишь последние 3-5 лет по месяцу. Под "адекватностью" подразумеваю ограничения по BHP как для нагнетательных, так и для добывающих.
Очень доволен 64-разрядным счетом и не очень happy от параллельного. Если есть много процессоров чаще ставлю много serial вариантов. Parallel использовал для больших задач до появления 64-разрядного ECLIPSE.
В среднем после "доводки" модель считается быстрее в 3-5 раз, но к финалу НМ почему-то обычно скорость падает в 1.5-2.0 раза ... но может это только у меня, не знаю. Предпочитаю 100х100 по горизонтали (чтобы скина для моделирования ГРП хватало, хотя бы не большеобъемных), число слоев исходя из правила номер 1 :-)
С уважением,
Инженер
P.S. LGR и COARSE недолюбливаю. Уж лучше разделять и властвовать - FLUX option. Но это ИМХО.
Создалось впечатление, что считать на маленьких моделях зазорно и тот кто это делает - невежда.
Рука дрогнула над 50-150 и поставила (сама !!!) галочку на 150-200.
Чтобы на это сказал старикашка Фрейд?
P.S. Динамическое укрупнение было в VIP
У нас вот получилося 200 тысяч ячеек. Dual poro/perm, т.е. умножаем на два. Более полувека добычи. Планируем моделировать DDP.
Ну не жопа ли?
Потолок 500 тыс (это активных, значит всего будет чуть меньше миллиона скорее всего) потому что это примерно столько сколько можно считать на своем компьютере сегодня без использования кластеров, серверов и т.д., как верно подметил Dorzhi.
Хотя согласен, наверное, надо было еще миллион поставить.
А в чем выйгрыш кроме как можно запустить большую модель из-за памяти ? Или было отмечено увеличения скорости при переходе от 32 к 64 бита ?
Спасибо за правку опроса.
Сейчас пробую запустить модель на кластере с 254 процессорами
. Как будут результаты отпишу какая разница в скорости и какую модель по размерности он сможет потянуть. Возможно уже после нового года.
Кто нибудь работал с Enable ?
Моделирую в EMpower. Размерности моделей зависят от толшины нефтяной оторочки, чтобы между горизонтальными скважинами и газовым/водяным контактами вмещалось как минимум 5 ячеек. Получается 75х75, 100х100 или 150х150. Слоев 30-50 т.к. нужно моделировать прорывы газа и воды. Площадь 5х25км.
Перемножая вышесказаное получаем 150-500 ячеек. Считаютя модели от 4 часов и до суток. При этом половина времени уходить на well managment, потому что сложная фасилити и много ограничений.
Улыбнулся, когда прочитал, что если модель считает больше часа - то это неправильная модель!!! Для примера месторождение Прудо Бай считается около 2 недель.
Если модель считает больше часа - двух, адаптацию может выполнить только очень терпеливый человек у которого есть два-три года в запасе и результаты полученные в итоге никого не интересуют.
но блин, все равно осталось ощущение, что пользуешься black box...
Надо быть на адвансд уровне, чтобы был адекватный результат.
Ну в принципе симулятор тоже можно рассматривать как black box. Но зато есть возможность посмотреть все пространство решений и увидеть насколько HM соотвествует здравому смыслу, а не притянут за уши к P99 варианту. Я думаю Enable намного полезней будет даже для appraisal, прогнозов чем HM.
interesuet mnenie tex kto modeliroval razrabotku tonkix neftyanix otoro4ek. Kak opredelyali minimal'nuyu razmernost' modeli dlya adekvatnogo modelirovaniya prorivov gaza i vodi.
Как правило наши модели до 200 тыс. оптимальное время счета - до 4 часов, так чтоб за рабочий день прогнать 2 варианта и пустить 3 на ночь. Для больших моделей под 1 млн. счет может быть и более суток, и дело тут не в карявости модели, а ее сложности чем больше скважин и NNC, соответственно и времени будет больше.
Enable все таки позиционируеться как HM tool.
For unsertainty studies we are using COUGAR, for quick model's parameter validation and interaction - SimOpt.
в том виде в каком их предлагают использовать это получение цифр ради цифр,
задачи должны быть скромнее и проще
сейчас это выглядит как если накрыть черный ящик черным покрывалом.
двойной черный ящик.
хорошо что кто-то это понимает (пока ещё)
Тут главное стремление - ставим цель 30мин, считаем час. Если принять "нормой" 4 часа ... то получим 8 часов счета и успокоимся. И будем считать по 3 расчета за сутки :-(
Текущую задачу свою посмотрел: считаю за 50 мин, 300 тыс. активных ячеек, 15 лет, первые 5 лет считаю с шагом по-годам (меня всегда умиляет, когда Российскую историю 30-летней давности воспроизводят помесячно :-).
Можно и 8 часов считать и 16. Но за сутки необходимо перепробовать не менее 4 (а лучше много больше) вариантов, иначе работу и за год не выполнить, а за месяц-два и подавно.
Если серьезно про производительность, то имея под боком рабочую станцию с 4 реально независимыми ядрами ставлю считать 4 варианта за раз. За ночь считаю ~ 16 вариантов. Днем анализирую/готовлю новые варианты. Когда воспроизводил "монстров" - резал на блоки и воспроизводил (моделировал) блоками с FLUX. В субботу-воскресенье сшивал (обновлял условия на границах с учетом сделанных изменений в каждом блоке). Сами понимаете, с ростом числа ячеек время расчета возрастает нелинейно. Посчитать 8 восьмушек зачастую быстрее чем целую модель (по крайней мере так было раньше:-)
С уважением,
Инженер.
P.S. Enable не юзал. К МЕРО претензия одна - стоит наверное выделять несколько наборов "суммарных ошибок" для адаптации нескольких наборов "переменных". Когда МЕРО предлагает мне анализировать ОДНУ суммарную ошибку, то честно говоря становится понятно, что математики опять победили физиков, ну или наука победила здравый смысл. В любом случае соотношение цена/качество не позволит мне ее рекомендовать начальству для покупки.
ЗЫ "For unsertainty studies we are using COUGAR, for quick model's parameter validation and interaction - SimOpt" от XFactor - подпишусь, хотя софтинки немного другие, но алгоритмы использую те же. Кстати и подход к "скорости счета" моделей (от 5 за сутки) у нас с XFactor совпадает. Честно говоря, очень не хватает хорошего инструмента для анализа рассчитанных вариантов. Со скоростью после появления параллели, 64х и последних процессоров не решаемых проблем не было давно. Скорость анализа и подготовки новых вариантов у меня на сегодняшний день ниже скорости счета. Чистое ИМХО.
Много развернули в теме - не успел к началу... )
А как можно одновременно анализировать 10 ошибок?
Чего реально нехватает, так это каких-нибудь "пользовательских переменных",
типа величины запасов. Потому как поменял в модели кучу параметров, и не видно,
как при этом меняются запасы.
Для быстроты и при малом количестве параметров - согласен, вряд ли MEPO и Enable будут нужны, SimOpt-ом можно будет обойтись.
Не надо комментировать только для того чтобы прокомментировать. Я же не говорил, что Dynagrid это что-то новое. Это я про него только что узнал. Да и то, что это все в STARS тоже вроде упомянул. Может это и не практично, но можно попробовать посчитать то же самое в STARS с простой blackoil-моделью.
Дима, ничего личного.
Напротив, с 2006-го инструмент в симуляторе вполне могли развить и оптимизировать!
Не обязательно, есть же и новые месторождения. Хотя в целом не спорю что для HM очень удобно.
Есть некоторые результаты по расчетам на кластере:
общее кол-во ячеек (активных) в млн
прогноз на 30 лет black oil
- 1 (0.6) считается 25 минут на обычном ноутбуке core duo
- 1.3 (0.75) на обычном ноуте, не помню точных данных, часа полтора где-то
- 5.7 (3.3) на кластере, 21 час и только 6 лет просчиталось, решил не мучить лошадку и остановил, было много "problems" под конец
- 2.34 (1.34) на кластере, 6.5 часов, 22 года, дальше остановил
- 2.4 (1) на кластере, 4 часа. Убавил немного tuning и сделал maxstep 12 дней. "problems" больше не было
В общем особого прироста производительности я не заметил между обычным ноутбуком и кластером (нет сейчас точных данных под рукой для одной и той же небольшой модели которая считалась и там и там). Т.е. на обычных системах 64 бит и достаточной памяти можно считать все тоже самое и за меньшие деньги. Единственно, что понравилось, это в Enable можно было запустить 50 процессов сразу на все варианты.
А разве там нельзя сохранять запасы и т.п. для каждой итерации?
(я не работал с Enable)
А когда считали на ноуте core duo и на кластере, использовали ли Вы параллельный счет? Каким симулятором пользовались?
По личному опыту, время расчёта модели зависит не только от размерности грида. Я обычно говорю геологу, чтобы количество ячеек было не более 200 тыс, далее смотрю по обстоятельствам, если же модель получилась простая (считает быстро), то прошу геолога ещё более детализировать модель! Во всём нужен баланс, а так для относительно качественного хистори матчинга время расчёта 1 час считаю максимальным!
Это факт
Модель использовалась одна и та же с небольшими вариациями, менялась размерность. Иначе сравнивать было бы бессмысленно.
Eclipse, паралельный счет только в том смысле что одна модель один процессор. Опцию "parallel" для распараллеливания вычислений пока задействовать не удается. Что-то не хочет кластер или Eclipse так считать.
Ну если так использовать кластер, то можно сделать вывод, что ноутбук не слабее...
Несмотря на то, что не особо силен в eclipse (те кто на нем работает поправьте) слышал, что параллельный счет для версии Win64 не работает. Во всяком случае в версии 2007 вроде так было. И единственная возможность такого счета - использовать версию под linux.
Используется уже не стандартный гнусавый MPI и даже не MPIPro, а Microsoft HPC ... ну как бы "продвинутый MPI от Microsoft" :-)
Правда другой не весь софт под WinXP64 бегает - я имею в виду не SLB-шный, а вообще. Но eclipse, cпасибо поддержке, после их ковыряний летает как миленький.
С уважением,
Инженер.
2mishgan - У нас тоже не сразу пошло. Мы не знали, что MPIPro уже не нужен и надо ставить MS-HPС потому и не работало ... мне это потом SIS-ники объяснили, когда под их веселыми ручками всё заработало.
У нас кластер+eclipse под Linux 64 работает. При задействовании параллельного счета, опция parallel и 8 процессов имеем прирост скорости расчета модели с 5 часов до 1ч20минут (2.2 мл ячеек, 1 млн активных). Не так плохо. Насчет разницы между ноутбуком и кластером в Single process run я до этого погорячился и прирост все таки есть. Думаю это будет зависить от конкретных конфигураций машин, в моем случае где-то >40%.
to Volkov:
"Модель интегральная? или просто одновременный расчет нескольких независимых друг от друга объектов?"
- был одновременный расчет независимых объектов, как сказал без опции parallel для Enable.
Удалось сократить время одного расчета со 170-180 до 50-60 мин (опция parallel 2)
не менялась размерность, но убрали численный аквифер, и всякую хрень в schedule-секции. Хотя поставили endscale.
В итоге правда, непонятно от чего конкретно так выросла скорость.
Причем изначально время счета (около 3 ч) не зависело от количества ядер.
После причесывания один вариант стал считаться минут 20-30 на 16 ядрах.
Модель 0,5 млн яч. 2 фазы: газ+вода. 40 лет истории.
Тоже поделюсь цифрами ))
Несколько месяцев назад прогонял задачи на разных компах.
Моя текущая задача (двойная пористость) считалась на хорошем двухъядерном ноуте с параллельной опцией (одновременно 2 ядра) за 82 минуты . На 8 ядерной рабочей станции счет занял 33 минуты, на 16-ти ядерном сервере счет занимал 29 минут. Сравнение между ними не совсем корректное, т.к. процессоры и т.д. везде разные, но тем не менее.
Для интереса прогонял тестовую задачу на 16 ядерном сервере с разным количеством работающих ядер. Время счета (минуты) - в аттаче.serv.jpg
А на графике от 8.5 минут до двух минут
"Для интереса прогонял тестовую задачу на 16 ядерном сервере с разным количеством работающих ядер." Ключевое слово здесь "ТЕСТОВУЮ". У меня времени не было гонять полноценную модель на разном сочетании работающих ядер. Слепил простую задачу, ее и просчитал
Это я так несерьезно заметил, что
в тексте говорится с 82 до 29 минут, а на графике представлено с 8 до 2 минут.
Без претензий к поставленной задаче и всё такое.
Или (скорее всего) рисунок не относится к тексту, я недопонял.
У меня на mored прирост от одного процессора до четырех процессоров процентов 15% вместо обещанных 2-3 раз.
Тоже видимо на тестовых задачах гоняют.
В тексте была мысль, что переход с двухъядерного ноута (даже при условии, что при расчете на нем используется 2 ядра) на рабочие станции имеет смысл (с 82 до 29 минут). Что же касается сарказма по поводу "тестовых задач", то до того, как появилась рабочая станция я считал на ноуте и на одном ядре и, используя параллельную опцию, на двух. Прирост на "реальных задачах" при таком переходе как правило составлял 1.3 - 1.6 раз.