Заметка несколько желтовата.
Как-то давно, на 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 лет назад - получили продукт позволяющий с адекватной скоростью расчитывать модели с милионными количествами ячеек.
Зависит от решаемых задач. Возможно, для разностных методов лучше подходит более "приземленный" С++. ИМХО.
Имеется в виду INTERSECT.
INTERSECT это уже не Eclipse. Это как сравнивать внедорожник-Eclipce, который прет без разбора по бездорожью, с легковушкой-Intersect, что едет по шоссе. И спрашивать, что лучше дизель или бензин.
Можно немного больше деталей сравнения?
Была презентация месяц назад по Intersect-у. Грубо говоря это новое поколение FrontSim-а или StreamLine из tNavigator-а. Полная совместимость кодинга с Eclipse. Всем понравилось, будем переходить к концу года. Тем более, что обещали простую замену лицензий Eclipsa на Intersect.
Это очень грубо, правда. Либо я чего-то не знаю про tNavigator. Я так понял, имеются в виду те линии тока, которые рисуются непосредственно в нем, а не какой-то отдельный малоизвестный модуль. Тогда он ничего общего с FrontSim не имеет, т.к. это просто линии градиента поля давления, которые в расчете никак не участвуют.
А мне интересно, быстрота INTERSECT-а на трехфазных моделях проверялась? Насколько я помню, FrontSim на трехфазных моделях по быстроте ничем не отличался от ECLIPSE.
Я думаю основная проблема с Eclipse в том что изначальный код очень старый. Со временем Eclipse разрастался и добавлялись разные примочки. В программировании всегда проще добавить что-то новое к уже существующему чем переписывать все заново с новой архитектурой. Со временем прекрасный дом превращается в нагромождение построек кое-как к нему прикрученных и соединенных переходами, лазами, веревками и т.д. К тому же алгоритмы которые работали отлично на небольших моделях могут потребовать модификации для более сложных и больших моделей которые сейчас запускают. Я так думаю язык тут имеет второстепенную роль по сравнению со сменой архитектуры и модификацией кода.
Я вчера был на презентации, которая к сожаленью имела мало технических подробностей, но о линиях тока разговора не было. Конкретно указали, что intersect это слияние blackoil, композитного, термического и так далее симуляторов в один. Ещё один шаг к Tempest More :)
Второй шаг - это отделение задания скважин и перфораций от данных добычи.
И третий шаг - это бинарные входные файлы - то, что так долго нам обещали в tempest 6.6. Как мне показалось, новый формат intersect, бинарный. Если это так, то это очень и очень крутое решение.
Написал в поддержку Шлюма, может вышлют какой-нибудь внятный обзор этого Intersect-а, тогда поделюсь с вами )
А в чем плюс бинарных входных файлов? Меньше места занимают?
1. С# мог использоваться только для интерфейса, это язык высокого уровня в нем нет низкоуровневых инструментов работы с памятью. Самые быстрые программы на класическом структурном С (желательно с компилятором от производителя процессора), но на нем уже такие проги не пишут, поэтому скорее всего объектно ориентированный С++
2. Физические модели не поменялись, поменялись алгоритмы их решения
3. Если поддерживаются бинарники то это круто, думаю ковырянии в текстовом файле должно уйти в прошлое ))
Спешу вас огорчить
, новый формат входных файлов INTERSECT по прежнему текстовый, не бинарный, больше похож на скриптовый язык, и выглядит вот так:
Вот еще что я узнал про INTERSECT от службы поддержки (если кратко):
Ах да, самое вкусное забыл, у него будет свой API!!!
ПОПРАВОЧКА:
Да, неприкольно. Вот что означала фраза про скрипты пользователя.
Про трубки тока, я писал, что это точно нет. Вообще говорили что и считатель остался старый.
Алгебраический мультисолвер появился несколько лет назад в tempest - считается что на больших моделях дает прирост, но негарантирован. В качестве примера приводили тесты SPE10 (?) сильно неоднородная громадная модель. Свой API, значит будет доступен через Ocean. Ocean написан на C#, следовательно язык программирования похоже что C#.
Строгое упорядочение по датам - этого отстоя тоже нет в tempest, в котором используется система event (событий). Намного гибче и удобней. Приветствую отказ от DATES.
Вот и сближаются родные братья друг к другу. Если критична цена - можно заказать evolution версию INTERSECT и сравнить по скорости Tempest. Я думаю второй, при видимом схожем использовании AMG и MPI будет более бюджетен. Первый симулятор как первая девушка - запоминается на всю жизнь :)
Что-то похожее на скрипт было у Landmark с ООП подходом. Поправьте меня, кто использовал.
Может быть обернута в C#, а корневая библиотека может быть на другом языке, на том же CPP. А свой API я понимаю так, что не обязательно Ocean, а вообще при большом желании можно свою стороннюю оболочку написать.
Имелось в виду evaluation?
мне кажется, что чистка древнего кода Eclipse от кучи лишних циклов и модулей, конечно важен, вот только переход от Fortran на C++ не гарантирует ускорение программы, или нет? И ещё, думается, что разделение на разные модули (E100, E300, E500 и т.п.) всётаки дает возможность урпросить модель и ускорить расчёт. А вот переход в бинарный или скриптовый вод данных - издевательство над пользователями, т.к. фактически принуждают нас работать с кривым пре-пост процессингом petrel.
algebraic multi-grid или многосеточный метод в темпесте уже несколько лет назад реализован. Когда разговаривали с поддержкой на презентации возможностей пару лет назад - сказали, что не оправдал ожиданий.
А не появилась ли возможность пилить и клеить модели? Типа того, что сделано у RFD?
INTERSECT позиционируется как дорогая система для параллельных вычислительных систем. Что-то типа одной параллельной лицензии на проектный институт и хватит - на остальное есть Eclipse. Он призван не заменить Eclipse, а расширить круг задач, решаемых на моделях (там где Eclipse отдыхает).
я не работал с intersect, не знаком с ним. Т.е. - это некая параллельная версия, обновленная. Тогда не понятно, где же "отдыхает" Eclipse ?? и что же такого нового в intersect, чего нет в Eclipse ? Eclipse - parrallel имеется, в чем же суть ?
Параллельный расчет в Eclipse сделан криво (модель пилится на прямоугольные бруски). В Intersect пилятся произвольно указанные регионы и сам алгоритм параллельного расчета оптимизирован. Как именно оптимизирован конечно тайна, но существенный прирост достигается на многомилионных количествах ячеек, т.е. для полномасштабных но при этом детальных моделей. Еще там что-то нашаманили так что теперь соседство ячеек существенно разного объема не проблема для сходимости алгоритма. Вообще в России одна лицензия только продана, по-моему в Новатэк, если я ничего не путаю, вот их надо порасспрашивать :)
Примерно так и показывали на презентациях. если вывести в эклипсе регионы "домены", которые показывают какие области на каком процессе висели, с грустью вы отметите что домены нарезаются безмозгов, чисто ровно. можно поискать презентацию timezyx, где есть хороший скрин нарезки "доменов" пропорционально нагрузке процессорного времени, tnavi от большеголовых парней, которые занимаются паралельными вычеслениями следовало ожидать (так и есть!) отличного прироста. Сейчас время многопроцессорности и надо пошевеливатся как-то. Вот, с лагом наверное в пятилетку, что-то вылезло и из slb
В эклипсе можно самому домены нарезать. На реальных моделях разницы я не заметил, хотя были гениальные идеи как можно правильно разделить. А вы друзья как не садитесь...
Нам тоже показывали Intersect и как я понял это нишевый продукт, к сожалению. Обычно у Шлюмов очень грамотный маркетинг, но тут они что-то попутали и как мне кажется пролетят с ним. В своем узком сегменте ему придется конкурировать с другими продуктами которые дешевле и возможно что лучше.
В эклипсе домены самому - только по одной оси, в е300 - по 2м, но все-равно прямоугольники. В INTERSECT 3х мерные домены. Вообще - софт серьезный - скриптовый язык явно сделан для расширяемости т.е. концепция надолго. Симулятор для кластеров заточен - на 128 и больше ядер. Есть связка pipesim - INTERSECT без AVOCET. Petrel под него затачивается т.е. много работы делается. Из улучшений основных
1) алгоритмы распараллеливания - прирост хороший
2) на вход только активные ячейки приходят
3) Ячейки сложных форм, измельчения сетки не так сильно расчет тормозят, как LGR. Неструктурированные сетки поддерживаются, только делать их пока нормально не в чем...
4) софт активно дополняется.
Короче - пока аналогов для интегрированных расчетов композиционки с наземкой для больших моделей не вижу...
По параллельным кластерным вычислениям BlackOil аналоги есть )
Всем спасибо за ваше мнение и опыт. Мало технической информации, тем более свободной по новым симуляторам.
Когда я спросил у поддержки, у вас есть техдокументация по Intersect, они ответили "А вам зачем?" и замяли вопрос в общем. Не хотят почему-то давать, мол, вы его у себя все равно использовать не будете...
или сами напишите свой по ихней документации
каждый будет писать сам, под каждое месторождение.. ))) помню у кого-то такие мысли были