Исторически сложилось, что гидродинамическая модель представляет из себя набор текстовых файлов, в которых описывается геометрия резервуара, PVT свойства флюидов, данные по начальному равновесию, задаются скважины и режимы их работ. В этом смысле, принципиально один симулятор не сильно отличается от другого. В отечественных программах выбор написания ключевых слов, сильно зависит от пристрастия авторов. Например, tNavigator навеян ключевыми словами ECLIPSE, а МКТ от timezyx.ru написан под впечатлением от Tempest More. Хотя заметим что ECL и Tempest похожи друг на друга как двоюродные братья.

(Может это связано с тем, что единственный разработчик tempest more, в 80х работал над ECLIPSE и при увольнении забрал с собой не только чашку, степлер и фотографию любимой кошки, а кое что и ещё? Кто знает...)

Можно вспомнить и ныне покинувшие нас LAURA и SUTRA, в которых использовался самостоятельный синтаксис.

Большое количество симуляторов оперирует понятием Ключевое Слово (KEYWORD) после которого идет ряд обязательных или необязательных параметров. Например, вот так задается размер модели в ECLIPSE:

DIMENS

24 25 15 /

Здесь ключевое слово "DIMENS". За назначеним дальнейших параметров придется обратится в Большую Документацию.

А вот так задается размер модели в Tempest More:

SIZE

24 25 15 /

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

Что должен сделать симулятор при начале расчета гидродинамической модели?

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

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

В дополнении к ошибкам синтаксиса, есть один экзотический вид "тихой ошибки". Это неуказание ключевого слова.

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

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

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

Итак, о чем это я? О бинарных файлах.

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

Так как вручную править такой файл трудно и практически не интересно, требуется некоторая внешняя программа которая будет совершать за нас сей труд. В компании шлемберже для этого много последних лет идет развитие Petrel - программы которая начиналась как пакет геологического моделирования и сейчас замахивается на полную интеграцию всего процесса моделирования от сейсмики до прогнозных расчетов. В итоге, гидродинамик отучается от текстовых файлов и погружается в абстракции более высокого уровня. Хорошо это или плохо вопрос конечно привычки, но такие попытки уже предпринимались, в пакете под названием Office, который на мой взгляд так и не был доведен до конца.

Итак, за счет использования Petrel сейчас на выходе можно получить работающую гидродинамическую модель в текстовых файлах, которые подаются на вход Eclipse. Можно ожидать, что у разработчиков возникла следующая идея - а зачем нам сохранять информацию в текстовиках и затем проверять её сразу же на правильность при симулировании? Давайте просто объединим eclipse и petrel в один круг доверия.

Понятное дело, что petrel в этом случае должен сам контролировать "правильность" данных за счет взамодействия с пользователем. Учитывая большие возможности интерфейса petrel - он это может.

Мысль о бинарных файлах у меня возникли при упоминании нового формата входных данных используемых в INTERSECT. При расчете модели в формате ECLIPSE, текстовые файлы нужно прогнать через некий конвертатор, чтобы получить на выходе файлы нужного формата. Я обратил внимание, что получаемый файл меньше в размерах чем исходный. Итак. Меньший размер файла и необходимость применения конвертатора наталкивает на мысль о том, что это время наконецто пришло.

Почему мне вообще интересна эта тема?

Бинарные входные файлы это удобный путь для написания разнообразного софта. Если раньше требовалось фактически повторять код eclipse, писав свой собственный анализатор синтаксиса, с унификацией это не становится большой проблемой. Становится возможным самостоятельно создавать свои утилиты. Это очень интересно для меня.

Например, прикольная утилита для "сжатия" исходной текстовой модели в бинарный файл и "разжатие" бинарника в текстовый файл, используя задаваемый стиль форматирования текста. Например, я человек педантичный в моделировании и мне не нравится когда текст выглядит неряшливым. Это сродни стилю форматирования при программировании. О да.

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

У MEPO также как и у EnABLE есть большая проблема. Это ужасный интерфейс и это ужасное задание исходных переменных. Когда все входные данные для модели будут находится на своих местах, процесс "подбора" параметров будет точно соответствовать "черному ящику" - определенные входы и определенные выходы. Это упростит интерфейс и реализацию программ. 

Не так сложно будет и самостоятельно написать аналогичную программу, релизующую один из множества методов. Идея генетических алгоритмов мне нравится. Я бы хотел реализовать это.

Что касается tempest, применение бинарных файлов намного более желаемо, чем в eclipse. Вы конечно знаете, что при начале расчета tempest считывает траектории всех скважин плюс перфорации и переводит их в координаты I J K. Для достаточно крупного фонда это может занимать огромнейшее количество времени. То же касается и начальной инициализации. Хорошая идея, это сгенерировать бинарники из текстовиков один раз. И при дальнейшей работе уже больше не делать длительной инициализации, а просто обновлять ту часть бинарного файла, которая нуждается в обновлении.

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

Доброй ночи.

UPD:

Совсем забыл дописать один важный трюк.

С помощью бинарных файлов намного облегчается задача переноса модели из одного симулятора в другой.