Размерность модели в симуляторе

Последнее сообщение
VIT 1111 18
Дек 08

Опыт моделирования больших месторождений (в смысле много ячеек). Что делаете если симулятор не тянет ? Какими путями уменьшаете размерность модели ? Используете ли секторные модели ? Какое rule of thumb используете для размерности модели, времени счета и т.д. Интересует в первую очередь практический опыт.

ojakov 131 18
Дек 08 #1

>500 это в тысячах?

DmitryB 458 16
Дек 08 #2

VIT пишет:

Опыт моделирования больших месторождений (в смысле много ячеек). Что делаете если симулятор не тянет ? Какими путями уменьшаете размерность модели ? Используете ли секторные модели ? Какое rule of thumb используете для размерности модели, времени счета и т.д. Интересует в первую очередь практический опыт.


Да вроде Eclipse и CMG все что угодно тянут. Что значит "не тянет"? Неделю считает? Две? На своем скромном опыте не видел моделей, которые бы не потянула парочка Xeon'ов. Другое дело, если в модели серьезные косяки есть...
Недавно был на семинаре CMG. Показали такую классную штуку, как Dynagrid. Динамическое укрупнение/уменьшение ячеек в зависимости от величины перепадов параметра (давление, температура, и. т.д.). Cчитали SAGD в STARS. Двухкратное ускорение. Сам пробовал.

VIT 1111 18
Дек 08 #3

DmitryB пишет:

Да вроде Eclipse и CMG все что угодно тянут. Что значит "не тянет"? Неделю считает? Две? На своем скромном опыте не видел моделей, которые бы не потянула парочка Xeon'ов. Другое дело, если в модели серьезные косяки есть...
Недавно был на семинаре CMG. Показали такую классную штуку, как Dynagrid. Динамическое укрупнение/уменьшение ячеек в зависимости от величины перепадов параметра (давление, температура, и. т.д.). Cчитали SAGD в STARS. Двухкратное ускорение. Сам пробовал.


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

Назовем это путь оптимизации вычислений 1)
Второй путь это оптимизация самих моделей 2).

Интересно было бы сравнить где какой выйгрыш и в чем, основываясь на опыте участников.

VIT 1111 18
Дек 08 #4

ojakov пишет:

>500 это в тысячах?


Вижу что геолог biggrin.gif
Ответ: да.

DmitryB 458 16
Дек 08 #5

VIT пишет:

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

Назовем это путь оптимизации вычислений 1)
Второй путь это оптимизация самих моделей 2).

Интересно было бы сравнить где какой выйгрыш и в чем, основываясь на опыте участников.


Принцип такой: сначала делается модель достаточно высокого разрешения, а потом по заданным параметрам симулятор ее укрупняет и снова измельчает. Вначале все ячейки укрупняются по заданной схеме (например, 10 в одну или 20 в одну). Потом, например, если перепад давления между ячейками выше заданного значения (т.е. значительный) ячейки снова разбиваются. И также обратно.
Наилучшие результаты дает при моделировании фронтальных процессов (тот же SAGD, ISC, и т.п.). Primary production, скорее всего, не удастся ускорить в два раза. Главный недостаток проявляется в очень неоднородном пласте, когда объединение ячеек по сути дела засирает геологическую модель. В принципе, при умной настройке можно приспособиться.
Еще можно упростить fluid model, numerical, и пр.
Тебя, насколько я понял, больше всего интересует upscaling. Это целая наука. Я бы не стал сильно этим заниматься без большой необходимости.

Dorzhi 970 18
Дек 08 #6

до миллиона ячеек 32битная винда тянет. больше уже оперативы не хватит на винде по крайней мере, нужно распараллеливание или 64битную ос

ant 55 16
Дек 08 #7

В чем проблема, давно уже существуют кластера для расчетов. У меня например на работе персоналка не слишком сильная. Да и какая разница, если только результаты просматривать. А скорость расчета даже самых больших моделей настраивается...правда с некоторыми оговорками, уже на раз звучавшими на форуме

mishgan 122 17
Дек 08 #8

Шкала размерностей немного странноватая. Почему потолок “>500”? Складывается впечатление, что основной путь решение Вашей проблемы – приобретение нормальной 64битной рабочей станции + распараллеливание. Так Вы сможете добиться ускорения примерно 3-6 раз в сравнении со счетом на хорошем ноуте. Все таки это более дешевый и рациональный способ ускорения, нежели возится с абскейлингом.
По поводу Dynagrid в CMG, насколько помню, эта опция была только в STARS, а спрашивают про black oil.

volvlad 2196 18
Дек 08 #9

Ответил 150-250, хотя есть достаточно большое кол-во моделей из категории 50-150. Как правило, у нас это очень мелкие месторождения или средние без истории, для получения первых прикидочных результатов...
На более крупных, делаем модели с бОльшим числом ячеек.

Главные критерии при выборе сетки - разумное время расчета, при сохранении геологических особенностей (гетерогенность, непроницаемые слои и пр)... Для меня разумным временем является - несколько часов...
Хотя могут возникнуть такие задачи, для которых время расчета не столько критично, сколько точность полученных результатов... В общем, все зависит от поставленных целей и задач.

Размеры ячеек по горизонтали, как правило 50*50 метров, для совсем мелких месторождений меньше...
По вертикали при выборе средней тольшины слоя стараемся делать не более чем 1-1.5 метра, если ячеек получается не слишком много и модель считается стабильно, приводим к 0.5 метрам...

В районе горизонтальных скважин, если геометрия достаточно сложная делаем LGR.
Акьюфер максимально обрезаем или делаем coarsening.

Будут более мощные машины и модели станут более детальными...

ant пишет:

В чем проблема, давно уже существуют кластера для расчетов.

Кластеры существуют, но не у всех есть, к сожалению...
У нас например нет, считаем на обычных рабочих станциях с двумя Xeon-ами..

Mishgen 144 17
Дек 08 #10

Пользую 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. Но это ИМХО.

RomanK. 2143 16
Дек 08 #11

Создалось впечатление, что считать на маленьких моделях зазорно и тот кто это делает - невежда.
Рука дрогнула над 50-150 и поставила (сама !!!) галочку на 150-200.
Чтобы на это сказал старикашка Фрейд?

P.S. Динамическое укрупнение было в VIP

ojakov 131 18
Дек 08 #12

У нас вот получилося 200 тысяч ячеек. Dual poro/perm, т.е. умножаем на два. Более полувека добычи. Планируем моделировать DDP.
Ну не жопа ли?

VIT 1111 18
Дек 08 #13

mishgan пишет:

Шкала размерностей немного странноватая. Почему потолок “>500”? Складывается впечатление, что основной путь решение Вашей проблемы – приобретение нормальной 64битной рабочей станции + распараллеливание. Так Вы сможете добиться ускорения примерно 3-6 раз в сравнении со счетом на хорошем ноуте. Все таки это более дешевый и рациональный способ ускорения, нежели возится с абскейлингом.
По поводу Dynagrid в CMG, насколько помню, эта опция была только в STARS, а спрашивают про black oil.


Потолок 500 тыс (это активных, значит всего будет чуть меньше миллиона скорее всего) потому что это примерно столько сколько можно считать на своем компьютере сегодня без использования кластеров, серверов и т.д., как верно подметил Dorzhi.

Хотя согласен, наверное, надо было еще миллион поставить.

VIT 1111 18
Дек 08 #14

Mishgen пишет:

Очень доволен 64-разрядным счетом и не очень happy от параллельного. Если есть много процессоров чаще ставлю много serial вариантов. Parallel использовал для больших задач до появления 64-разрядного ECLIPSE.


А в чем выйгрыш кроме как можно запустить большую модель из-за памяти ? Или было отмечено увеличения скорости при переходе от 32 к 64 бита ?

volvlad 2196 18
Дек 08 #15

VIT пишет:

А в чем выйгрыш кроме как можно запустить большую модель из-за памяти ? Или было отмечено увеличения скорости при переходе от 32 к 64 бита ?

Правильно выигрыша по производительности нет, только снятие ограничений по памяти... хотя в свое время и 4 гига оперативы казалось недосягаемым пределом)))

VIT 1111 18
Дек 08 #16

V. Volkov пишет:

Добивил пункт более миллиона wink.gif
Правильно выигрыша по производительности нет, только снятие ограничений по памяти... хотя в свое время и 4 гига оперативы казалось недосягаемым пределом)))


Спасибо за правку опроса.

Сейчас пробую запустить модель на кластере с 254 процессорами rolleyes.gif . Как будут результаты отпишу какая разница в скорости и какую модель по размерности он сможет потянуть. Возможно уже после нового года.

Кто нибудь работал с Enable ?

Kolos 197 16
Дек 08 #17

Моделирую в EMpower. Размерности моделей зависят от толшины нефтяной оторочки, чтобы между горизонтальными скважинами и газовым/водяным контактами вмещалось как минимум 5 ячеек. Получается 75х75, 100х100 или 150х150. Слоев 30-50 т.к. нужно моделировать прорывы газа и воды. Площадь 5х25км.
Перемножая вышесказаное получаем 150-500 ячеек. Считаютя модели от 4 часов и до суток. При этом половина времени уходить на well managment, потому что сложная фасилити и много ограничений.

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

RomanK. 2143 16
Дек 08 #18

Kolos пишет:

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


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

Злой 288 18
Дек 08 #19

VIT пишет:

Кто нибудь работал с Enable ?

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

volvlad 2196 18
Дек 08 #20

RomanK. пишет:

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

А если скважин всего с десяток, тогда вполне приемлемое время счета...

VIT 1111 18
Дек 08 #21

Злой пишет:

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


Ну в принципе симулятор тоже можно рассматривать как black box. Но зато есть возможность посмотреть все пространство решений и увидеть насколько HM соотвествует здравому смыслу, а не притянут за уши к P99 варианту. Я думаю Enable намного полезней будет даже для appraisal, прогнозов чем HM.

Kolos 197 16
Дек 08 #22

interesuet mnenie tex kto modeliroval razrabotku tonkix neftyanix otoro4ek. Kak opredelyali minimal'nuyu razmernost' modeli dlya adekvatnogo modelirovaniya prorivov gaza i vodi.

XFactor 267 16
Дек 08 #23

Как правило наши модели до 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.

RomanK. 2143 16
Дек 08 #24

Злой пишет:

но блин, все равно осталось ощущение, что пользуешься black box...


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

Mishgen 144 17
Дек 08 #25

Kolos пишет:

Моделирую в EMpower. Размерности моделей зависят от толшины нефтяной оторочки, чтобы между горизонтальными скважинами и газовым/водяным контактами вмещалось как минимум 5 ячеек. Получается 75х75, 100х100 или 150х150. Слоев 30-50 т.к. нужно моделировать прорывы газа и воды. Площадь 5х25км.
Перемножая вышесказаное получаем 150-500 ячеек. Считаютя модели от 4 часов и до суток. При этом половина времени уходить на well managment, потому что сложная фасилити и много ограничений.

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

Да я и сам улыбался когда писал: "число слоев исходя из правила номер 1 :-)". Слишком часто исключения попадались (BlackOil на 3000 стволов и почти 50лет истории или композиционная для конденсата на E300) ... но как известно исключения подтверждают правило. Извините, к мировому опыту не обращаюсь (Прудо Бай), а если не говорить о Самотлорах и сложных газоконденсатных месторождениях ( или газовых оторочках, упомянутых Вами), то Российские месторождения просто BlackOil с длинной историей.

Тут главное стремление - ставим цель 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х и последних процессоров не решаемых проблем не было давно. Скорость анализа и подготовки новых вариантов у меня на сегодняшний день ниже скорости счета. Чистое ИМХО.

Гоша 1202 18
Дек 08 #26

Много развернули в теме - не успел к началу... )

Mishgen пишет:

P.S. Enable не юзал. К МЕРО претензия одна - стоит наверное выделять несколько наборов "суммарных ошибок" для адаптации нескольких наборов "переменных". Когда МЕРО предлагает мне анализировать ОДНУ суммарную ошибку, то честно говоря становится понятно, что математики опять победили физиков, ну или наука победила здравый смысл. В любом случае соотношение цена/качество не позволит мне ее рекомендовать начальству для покупки.

ЗЫ "For unsertainty studies we are using COUGAR, for quick model's parameter validation and interaction - SimOpt" от XFactor - подпишусь, хотя софтинки немного другие, но алгоритмы использую те же.


А как можно одновременно анализировать 10 ошибок? wacko.gif Может надо для этого обитать в 10-мерном пространстве? laugh.gif Это ли здравый смысл? ph34r.gif
Чего реально нехватает, так это каких-нибудь "пользовательских переменных",
типа величины запасов. Потому как поменял в модели кучу параметров, и не видно,
как при этом меняются запасы.

Для быстроты и при малом количестве параметров - согласен, вряд ли MEPO и Enable будут нужны, SimOpt-ом можно будет обойтись.

DmitryB 458 16
Дек 08 #27

Не надо комментировать только для того чтобы прокомментировать. Я же не говорил, что Dynagrid это что-то новое. Это я про него только что узнал. Да и то, что это все в STARS тоже вроде упомянул. Может это и не практично, но можно попробовать посчитать то же самое в STARS с простой blackoil-моделью.

Гоша пишет:

Много развернули в теме - не успел к началу... )
Dynagrid был в CMG еще в 2006 году.
Действительно так
Прогнозы и appraisal с помощью набора моделей - это следствие проделанного HM.
Если этого не делается, то и HM вместе с Enabl-ом или MEPO был не нужен
А как можно одновременно анализировать 10 ошибок? wacko.gif Может надо для этого обитать в 10-мерном пространстве? laugh.gif Это ли здравый смысл? ph34r.gif
Чего реально нехватает, так это каких-нибудь "пользовательских переменных",
типа величины запасов. Потому как поменял в модели кучу параметров, и не видно,
как при этом меняются запасы.

Для быстроты и при малом количестве параметров - согласен, вряд ли MEPO и Enable будут нужны, SimOpt-ом можно будет обойтись.

Гоша 1202 18
Дек 08 #28

Дима, ничего личного.
Напротив, с 2006-го инструмент в симуляторе вполне могли развить и оптимизировать!

VIT 1111 18
Янв 09 #29

Гоша пишет:

Прогнозы и appraisal с помощью набора моделей - это следствие проделанного HM.
Если этого не делается, то и HM вместе с Enabl-ом или MEPO был не нужен


Не обязательно, есть же и новые месторождения. Хотя в целом не спорю что для HM очень удобно.

VIT 1111 18
Янв 09 #30

Есть некоторые результаты по расчетам на кластере:
общее кол-во ячеек (активных) в млн
прогноз на 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 процессов сразу на все варианты.

EmptyEye13 102 17
Янв 09 #31

Гоша пишет:

Чего реально нехватает, так это каких-нибудь "пользовательских переменных",
типа величины запасов. Потому как поменял в модели кучу параметров, и не видно,
как при этом меняются запасы.


А разве там нельзя сохранять запасы и т.п. для каждой итерации?
(я не работал с Enable)

mishgan 122 17
Янв 09 #32

А когда считали на ноуте core duo и на кластере, использовали ли Вы параллельный счет? Каким симулятором пользовались?

VIT пишет:

Есть некоторые результаты по расчетам на кластере:
общее кол-во ячеек (активных) в млн
прогноз на 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 процессов сразу на все варианты.

www 209 18
Янв 09 #33

По личному опыту, время расчёта модели зависит не только от размерности грида. Я обычно говорю геологу, чтобы количество ячеек было не более 200 тыс, далее смотрю по обстоятельствам, если же модель получилась простая (считает быстро), то прошу геолога ещё более детализировать модель! Во всём нужен баланс, а так для относительно качественного хистори матчинга время расчёта 1 час считаю максимальным!

volvlad 2196 18
Янв 09 #34

mishgan пишет:

А когда считали на ноуте core duo и на кластере, использовали ли Вы параллельный счет? Каким симулятором пользовались?

Очевидно, что было использовано распараллеливание

VIT 1111 18
Янв 09 #35

www пишет:

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


Это факт biggrin.gif

Модель использовалась одна и та же с небольшими вариациями, менялась размерность. Иначе сравнивать было бы бессмысленно.

VIT 1111 18
Янв 09 #36

mishgan пишет:

А когда считали на ноуте core duo и на кластере, использовали ли Вы параллельный счет? Каким симулятором пользовались?


Eclipse, паралельный счет только в том смысле что одна модель один процессор. Опцию "parallel" для распараллеливания вычислений пока задействовать не удается. Что-то не хочет кластер или Eclipse так считать.

mishgan 122 17
Янв 09 #37

VIT пишет:

Eclipse, паралельный счет только в том смысле что одна модель один процессор. Опцию "parallel" для распараллеливания вычислений пока задействовать не удается. Что-то не хочет кластер или Eclipse так считать.


Ну если так использовать кластер, то можно сделать вывод, что ноутбук не слабее...
Несмотря на то, что не особо силен в eclipse (те кто на нем работает поправьте) слышал, что параллельный счет для версии Win64 не работает. Во всяком случае в версии 2007 вроде так было. И единственная возможность такого счета - использовать версию под linux.

volvlad 2196 18
Янв 09 #38

VIT пишет:

Eclipse, паралельный счет только в том смысле что одна модель один процессор. Опцию "parallel" для распараллеливания вычислений пока задействовать не удается. Что-то не хочет кластер или Eclipse так считать.

Модель интегральная? или просто одновременный расчет нескольких независимых друг от друга объектов?

Mishgen 144 17
Янв 09 #39

V. Volkov пишет:

ну да, реализовано через MPI, не очень эффективно, прирост с ростом процессоров далеко нелинейный, к сожалению.
Об этом не слышал, у меня на 32-х битной архитектуре параллельный счет работает нормально, использую распараллеливание почти на всех моделях, считаю на рабочей станции с 2-мя Хeon-ами.
Кто еще пробовал?
Модель интегральная? или просто одновременный расчет нескольких независимых друг от друга объектов?

Считаю и на 32-х и на 64-х разрядных. Под eclipse - 2007. WinXP 64 (просто в задачах не только считать).
Используется уже не стандартный гнусавый MPI и даже не MPIPro, а Microsoft HPC ... ну как бы "продвинутый MPI от Microsoft" :-)

Правда другой не весь софт под WinXP64 бегает - я имею в виду не SLB-шный, а вообще. Но eclipse, cпасибо поддержке, после их ковыряний летает как миленький.

С уважением,
Инженер.
2mishgan - У нас тоже не сразу пошло. Мы не знали, что MPIPro уже не нужен и надо ставить MS-HPС потому и не работало ... мне это потом SIS-ники объяснили, когда под их веселыми ручками всё заработало.

VIT 1111 18
Янв 09 #40

У нас кластер+eclipse под Linux 64 работает. При задействовании параллельного счета, опция parallel и 8 процессов имеем прирост скорости расчета модели с 5 часов до 1ч20минут (2.2 мл ячеек, 1 млн активных). Не так плохо. Насчет разницы между ноутбуком и кластером в Single process run я до этого погорячился и прирост все таки есть. Думаю это будет зависить от конкретных конфигураций машин, в моем случае где-то >40%.

to Volkov:
"Модель интегральная? или просто одновременный расчет нескольких независимых друг от друга объектов?"
- был одновременный расчет независимых объектов, как сказал без опции parallel для Enable.

volvlad 2196 18
Янв 09 #41

VIT пишет:

"Модель интегральная? или просто одновременный расчет нескольких независимых друг от друга объектов?"
- был одновременный расчет независимых объектов, как сказал без опции parallel для Enable.

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

Гоша 1202 18
Янв 09 #42

VIT пишет:

Это факт biggrin.gif


Удалось сократить время одного расчета со 170-180 до 50-60 мин (опция parallel 2)
не менялась размерность, но убрали численный аквифер, и всякую хрень в schedule-секции. Хотя поставили endscale.

В итоге правда, непонятно от чего конкретно так выросла скорость.
Причем изначально время счета (около 3 ч) не зависело от количества ядер.
После причесывания один вариант стал считаться минут 20-30 на 16 ядрах.
Модель 0,5 млн яч. 2 фазы: газ+вода. 40 лет истории.

mishgan 122 17
Янв 09 #43

Тоже поделюсь цифрами ))

Несколько месяцев назад прогонял задачи на разных компах.
Моя текущая задача (двойная пористость) считалась на хорошем двухъядерном ноуте с параллельной опцией (одновременно 2 ядра) за 82 минуты . На 8 ядерной рабочей станции счет занял 33 минуты, на 16-ти ядерном сервере счет занимал 29 минут. Сравнение между ними не совсем корректное, т.к. процессоры и т.д. везде разные, но тем не менее.
Для интереса прогонял тестовую задачу на 16 ядерном сервере с разным количеством работающих ядер. Время счета (минуты) - в аттаче.serv.jpg

RomanK. 2143 16
Янв 09 #44

А на графике от 8.5 минут до двух минут smile.gif

mishgan 122 17
Янв 09 #45

RomanK. пишет:

А на графике от 8.5 минут до двух минут smile.gif


"Для интереса прогонял тестовую задачу на 16 ядерном сервере с разным количеством работающих ядер." Ключевое слово здесь "ТЕСТОВУЮ". У меня времени не было гонять полноценную модель на разном сочетании работающих ядер. Слепил простую задачу, ее и просчитал

RomanK. 2143 16
Янв 09 #46

Это я так несерьезно заметил, что
в тексте говорится с 82 до 29 минут, а на графике представлено с 8 до 2 минут.
Без претензий к поставленной задаче и всё такое.
Или (скорее всего) рисунок не относится к тексту, я недопонял.
У меня на mored прирост от одного процессора до четырех процессоров процентов 15% вместо обещанных 2-3 раз.
Тоже видимо на тестовых задачах гоняют.

mishgan 122 17
Янв 09 #47

RomanK. пишет:

Это я так несерьезно заметил, что
в тексте говорится с 82 до 29 минут, а на графике представлено с 8 до 2 минут.
Без претензий к поставленной задаче и всё такое.
Или (скорее всего) рисунок не относится к тексту, я недопонял.
У меня на mored прирост от одного процессора до четырех процессоров процентов 15% вместо обещанных 2-3 раз.
Тоже видимо на тестовых задачах гоняют.

В тексте была мысль, что переход с двухъядерного ноута (даже при условии, что при расчете на нем используется 2 ядра) на рабочие станции имеет смысл (с 82 до 29 минут). Что же касается сарказма по поводу "тестовых задач", то до того, как появилась рабочая станция я считал на ноуте и на одном ядре и, используя параллельную опцию, на двух. Прирост на "реальных задачах" при таком переходе как правило составлял 1.3 - 1.6 раз.

Go to top