Что быстрее: Eclipse (FORTRAN) или INTERSECT (С++)

Последнее сообщение
RomanK. 2161 13
Июн 11

Заметка несколько желтовата.

Как-то давно, на hw в теме "Roxar vs ECL", мы были молоды и горячи и немного посмотрили о том, что быстрее FORTRAN (как пример ECL) или C++ (пример Tempest MORE). Время показывает, что переписав ECLIPSE с FORTRAN на (предположительно) C++ получили великолепный прирост. Конечно, не только это сыграло свою роль. Вот основные звенья успеха intersect:

a) Переход с Fortran на C++ (правда, прозвучал язык C#, но учитывая что intersect работает под linux скорее всего это не шарп)

b) Ревизия старого кода (те, кто уверен, что за 29 лет развития код вылизан - это не так)

c) Применение более развитых средств распаралеливания. На примере, tempest один только выбор более удачного распаралеливающего менеджера увеличило скорость минимум в 2 раза. Здесь прирост намного выше.

Десятикратное увеличение скорости на системах с большим количеством ядер.

Что из себя представляет Intersect? 

Это объединение e100, e300 ... в единый продукт. Ожидать преимуществ от такого решения на скорость работы можно только косвенно. При появлении нового ключевого слова его не нужно дублировать в каждом из eXXX. Решает вопрос несовместимости e300 и e100 друг с другом. Скорее всего, это решение позволяет лучше управлять разработчиками и остановить внутреннюю войну между разными командами.

Математический решатель (solver) остался таким-же как и в ecl. На уровне математики это тот-же самый eclipse. Здесь чудес нет.

intersect научился работать с неструктурированными сетками, такое я видел и у shell. Во внутренних форматах eclipse (egrid) флаг сетки зарегестрирован ооочень давно, но так и не реализован в виде кода.

В итоге:

Старый eclipse, перенесли на более производительный язык (не только чистая скорость выполнения, но и работа с памятью, удобство работы в команде и так далее), пересмотрев внутренний код (в период объединения разроненных модулей в один) и добавив современные возможности паралельных вычеслений, о которых и не мечтали 30 лет назад - получили продукт позволяющий с адекватной скоростью расчитывать модели с милионными количествами ячеек.

 

AlNikS 878 12
Июн 11 #1

Зависит от решаемых задач. Возможно, для разностных методов лучше подходит более "приземленный" С++. ИМХО.

RomanK. 2161 13
Июн 11 #2

Имеется в виду INTERSECT.

voron4m 379 11
Июн 11 #3

INTERSECT это уже не Eclipse. Это как сравнивать внедорожник-Eclipce, который прет без разбора по бездорожью, с легковушкой-Intersect, что едет по шоссе. И спрашивать, что лучше дизель или бензин.

RomanK. 2161 13
Июн 11 #4

Можно немного больше деталей сравнения?

voron4m 379 11
Июн 11 #5

Была презентация месяц назад по Intersect-у. Грубо говоря это новое поколение FrontSim-а или StreamLine из tNavigator-а. Полная совместимость кодинга с Eclipse. Всем понравилось, будем переходить к концу года. Тем более, что обещали простую замену лицензий Eclipsa на Intersect.

AlNikS 878 12
Июн 11 #6

voron4m пишет:

Грубо говоря это новое поколение FrontSim-а или StreamLine из tNavigator-а.

Это очень грубо, правда. Либо я чего-то не знаю про tNavigator. Я так понял, имеются в виду те линии тока, которые рисуются непосредственно в нем, а не какой-то отдельный малоизвестный модуль. Тогда он ничего общего с FrontSim не имеет, т.к. это просто линии градиента поля давления, которые в расчете никак не участвуют.

А мне интересно, быстрота INTERSECT-а на трехфазных моделях проверялась? Насколько я помню, FrontSim на трехфазных моделях по быстроте ничем не отличался от ECLIPSE.

VIT 1123 14
Июн 11 #7

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

RomanK. 2161 13
Июн 11 #8

Я вчера был на презентации, которая к сожаленью имела мало технических подробностей, но о линиях тока разговора не было. Конкретно указали, что intersect это слияние blackoil, композитного, термического и так далее симуляторов в один. Ещё один шаг к Tempest More :)

Второй шаг - это отделение задания скважин и перфораций от данных добычи.

И третий шаг - это бинарные входные файлы - то, что так долго нам обещали в tempest 6.6. Как мне показалось, новый формат intersect, бинарный. Если это так, то это очень и очень крутое решение.

AlNikS 878 12
Июн 11 #9

Написал в поддержку Шлюма, может вышлют какой-нибудь внятный обзор этого Intersect-а, тогда поделюсь с вами )

А в чем плюс бинарных входных файлов? Меньше места занимают?

DmitryI 29 11
Июн 11 #10

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

 

2. Физические модели не поменялись, поменялись алгоритмы их решения

 

3. Если поддерживаются бинарники то это круто, думаю ковырянии в текстовом файле должно уйти в прошлое ))

AlNikS 878 12
Июн 11 #11

Спешу вас огорчить Frown, новый формат входных файлов INTERSECT по прежнему текстовый, не бинарный, больше похож на скриптовый язык, и выглядит вот так:

Вот еще что я узнал про INTERSECT от службы поддержки (если кратко):

  • Основное предназначение - параллельный многоядерный расчет больших моделей на геологической сетке, с LGR-ами, с 1000 и более скважин со сложным управлением разработкой (с ACTIONX, UDQ, UDA и т.п.), т.е. такие задачи, на которых ECLIPSE захлёбывается.
  • Шедуль уже больше похож на программу (скрипт), а не на шедуль. Строгое упорядочение по датам отменяется (в новом формате входных данных).
  • Blackoil, композиционная модель, термическая модель - все в одном модуле, в зависимости от входных параметров.
  • Ускорение расчета по сравнению с ECLIPSE зависит от конкретной модели (есть примеры, когда наоборот наблюдаются замедление). Следовательно, дело не в выбранной программной платформе.
  • Новый решатель основан на методе AMG (algebraic multi-grid или многосеточный метод), что за зверь не знаю, но сказали что известный метод. Короче, это точно не трубки тока Smile
  • При распараллеливании можно просчитывать куски сетки произвольной формы.
  • По своим функциям INTERSECT пока отстает от ECLIPSE (не все перенесено), но уже намного превосходит в плане гибкости шедуля.
  • INTERSECT более требователен к системным ресурсам, результаты расчета его занимают больше чем ECLIPS-овские.
  • Собственных пре- и постпроцессоров у INTERSECT не будет, предполагается использование Petrel.

Ах да, самое вкусное забыл, у него будет свой API!!!

ПОПРАВОЧКА:

  • Входные файлы параметров модели, шедуля, параметров флюидов и породы текстовые, а входные файлы сетки и ее свойств - бинарные.
  • Независимость от дат условная - в пределах одного файла стратегии всё должно быть упорядочено как и раньше, но можно автоматически накладывать друг на друга несколько файлов, и они не обязательно должны следовать в хронологическом порядке. (Т.е. это не как в event-ах Tempest-а, где даты событий вообще можно перемешивать как захочется).
RomanK. 2161 13
Июн 11 #12

Да, неприкольно. Вот что означала фраза про скрипты пользователя.

Про трубки тока, я писал, что это точно нет. Вообще говорили что и считатель остался старый.

Алгебраический мультисолвер появился несколько лет назад в tempest - считается что на больших моделях дает прирост, но негарантирован. В качестве примера приводили тесты SPE10 (?) сильно неоднородная громадная модель. Свой API, значит будет доступен через Ocean. Ocean написан на C#, следовательно язык программирования похоже что C#.

Строгое упорядочение по датам - этого отстоя тоже нет в tempest, в котором используется система event (событий). Намного гибче и удобней. Приветствую отказ от DATES.

Вот и сближаются родные братья друг к другу. Если критична цена - можно заказать evolution версию INTERSECT и сравнить по скорости Tempest. Я думаю второй, при видимом схожем использовании AMG и MPI будет более бюджетен. Первый симулятор как первая девушка - запоминается на всю жизнь :)

RomanK. 2161 13
Июн 11 #13

Что-то похожее на скрипт было у Landmark с ООП подходом. Поправьте меня, кто использовал.

AlNikS 878 12
Июн 11 #14

RomanK. пишет:

Свой API, значит будет доступен через Ocean. Ocean написан на C#, следовательно язык программирования похоже что C#.

Может быть обернута в C#, а корневая библиотека может быть на другом языке, на том же CPP. А свой API я понимаю так, что не обязательно Ocean, а вообще при большом желании можно свою стороннюю оболочку написать.

RomanK. пишет:

Если критична цена - можно заказать evolution версию INTERSECT и сравнить по скорости Tempest.

Имелось в виду evaluation?

Вар 391 14
Мар 13 #15

мне кажется, что чистка древнего кода Eclipse от кучи лишних циклов и модулей, конечно важен, вот только переход от Fortran на C++ не гарантирует ускорение программы, или нет? И ещё, думается, что разделение на разные модули (E100, E300, E500 и т.п.) всётаки дает возможность урпросить модель и ускорить расчёт. А вот переход в бинарный или скриптовый вод данных - издевательство над пользователями, т.к. фактически принуждают нас работать с кривым пре-пост процессингом petrel. 

helgibh 62 8
Мар 13 #16

algebraic multi-grid или многосеточный метод в темпесте уже несколько лет назад реализован. Когда разговаривали с поддержкой на презентации возможностей пару лет назад - сказали, что не оправдал ожиданий.
А не появилась ли возможность пилить и клеить модели? Типа того, что сделано у RFD?

AlNikS 878 12
Мар 13 #17

INTERSECT позиционируется как дорогая система для параллельных вычислительных систем. Что-то типа одной параллельной лицензии на проектный институт и хватит - на остальное есть Eclipse. Он призван не заменить Eclipse, а расширить круг задач, решаемых на моделях (там где Eclipse отдыхает).

Вар 391 14
Мар 13 #18

я не работал с intersect, не знаком с ним. Т.е. - это некая параллельная версия, обновленная. Тогда не понятно, где же "отдыхает" Eclipse ?? и что же такого нового в intersect, чего нет в Eclipse ? Eclipse - parrallel имеется, в чем же суть ?

AlNikS 878 12
Мар 13 #19

Параллельный расчет в Eclipse сделан криво (модель пилится на прямоугольные бруски). В Intersect пилятся произвольно указанные регионы и сам алгоритм параллельного расчета оптимизирован. Как именно оптимизирован конечно тайна, но существенный прирост достигается на многомилионных количествах ячеек, т.е. для полномасштабных но при этом детальных моделей. Еще там что-то нашаманили так что теперь соседство ячеек существенно разного объема не проблема для сходимости алгоритма. Вообще в России одна лицензия только продана, по-моему в Новатэк, если я ничего не путаю, вот их надо порасспрашивать :)

RomanK. 2161 13
Мар 13 #20

Примерно так и показывали на презентациях. если вывести в эклипсе регионы "домены", которые показывают какие области на каком процессе висели, с грустью вы отметите что домены нарезаются безмозгов, чисто ровно. можно поискать презентацию timezyx, где есть хороший скрин нарезки "доменов" пропорционально нагрузке процессорного времени, tnavi от большеголовых парней, которые занимаются паралельными вычеслениями следовало ожидать (так и есть!) отличного прироста. Сейчас время многопроцессорности и надо пошевеливатся как-то. Вот, с лагом наверное в пятилетку, что-то вылезло и из slb

VIT 1123 14
Мар 13 #21

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

Нам тоже показывали Intersect и как я понял это нишевый продукт, к сожалению. Обычно у Шлюмов очень грамотный маркетинг, но тут они что-то попутали и как мне кажется пролетят с ним. В своем узком сегменте ему придется конкурировать с другими продуктами которые дешевле и возможно что лучше.

TimTTT 156 14
Мар 13 #22

В эклипсе домены самому - только по одной оси, в е300 - по 2м, но все-равно прямоугольники. В INTERSECT 3х мерные домены. Вообще - софт серьезный - скриптовый язык явно сделан для расширяемости т.е. концепция надолго. Симулятор для кластеров заточен - на 128 и больше ядер. Есть связка pipesim - INTERSECT без AVOCET. Petrel под него затачивается т.е. много работы делается. Из улучшений основных
1) алгоритмы распараллеливания - прирост хороший
2) на вход только активные ячейки приходят
3) Ячейки сложных форм, измельчения сетки не так сильно расчет тормозят, как LGR. Неструктурированные сетки поддерживаются, только делать их пока нормально не в чем...
4) софт активно дополняется.
Короче - пока аналогов для интегрированных расчетов композиционки с наземкой для больших моделей не вижу...
По параллельным кластерным вычислениям BlackOil аналоги есть )

Вар 391 14
Мар 13 #23

Всем спасибо за ваше мнение и опыт. Мало технической информации, тем более свободной по новым симуляторам.

AlNikS 878 12
Мар 13 #24

Когда я спросил у поддержки, у вас есть техдокументация по Intersect, они ответили "А вам зачем?" и замяли вопрос в общем. Не хотят почему-то давать, мол, вы его у себя все равно использовать не будете...

asher forever 524 13
Мар 13 #25

или сами напишите свой по ихней документации

Вар 391 14
Мар 13 #26

каждый будет писать сам, под каждое месторождение.. ))) помню у кого-то такие мысли были

Go to top