Записки океанолога — обработка и визуализация данных

Задача: Заставить работать MITgcm, одну из лучших океанологических моделей на данный момент, под Ubuntu 10.10
Решение: оказалось не таким уж сложным.

Раньше моделирование океана и атмосферы было уделом горстки избранных. Чем-то это напоминало ситуацию с Линуксом конца 90х годов — разобраться было можно, но сложно. Те времена давно прошли, и как Линукс теперь доступен для средних умов, так и заставить работать свою гидродинамическую модель океана может практически каждая домохозяйка, было бы желание.

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

Немного про нашу модель. Полное ее название Massachusetts Institute of Technology General Circulation Model или MITgcm. Разрабатывается она, как не трудно догадаться, в этом уважаемом заведении и является одной из лучших на данный момент в мире. Позволяет моделировать разномасштабные процессы, от, условно, поведения бури в вашем стакане, до крупномасштабной циркуляции океана. На сайте периодически публикуются популярные обзоры исследований, в которых модель используется. По-большому счету она является тем исходным материалом, из которого вы лепите свой собственный сетап, настроенную под свои задачи модель, которая может даже называться вашим именем, или именем вашего института, но ядром ее все равно будет старая добрая MITgcm. Кстати, о возрасте. Если сравнивать с монстрами типа POP, то модель начали разрабатывать сравнительно недавно с середины 1990х годов. Это позволило заложить в нее некоторые новые идеи, витавшие среди людей, занимавшихся вычислительной гидродинамикой в то время.

Разработчики MITgcm хорошо понимают принцип: «Если хочешь, чтобы твоим продуктом пользовались, пиши понятную документацию». Лучше всего пользоваться последней ее pdf версией. В доках много примеров, в самом коде тоже довольно много комментариев, что бывает очень полезно, поскольку, как это не печально, иногда изменения в документации не успевают за изменениями в модели. Я тут собираюсь немного растечься мыслию по древу и описывать процесс в подробностях. Опытные же или нетерпеливые товарищи могут сразу перейти к разделу документации Getting Started with MITgcm, там сжато, но ясно описан весь процесс.

Надеюсь, что я вас убедил в том, что если вы подумываете о занятиях гидродинамическим моделированием океана, то на MITgcm стоит взглянуть хотя бы одним глазком, так что приступим. Ставить модель будем на Ubuntu 10.10. Тем кто ни в зуб ногой в Линуксе, могу посоветовать попробовать мой образ Ubuntu 8.04 для виртуальной машины, но не факт, что установка не будет отличаться в деталях. Предполагается также, что вы не падаете в обморок от слов «терминал» и «командная строка».

Для начала подготовим плацдарм, то есть установим недостающие в стандартной поставке программы:

cvs — система контроля версий, в которой ведется разработка модели, с ее помощью мы получим исходный код,

netcdf — библиотека для создания файлов формата netcdf, в принципе установка ее опциональна,

build-essential — набор утилит для компиляции,

gfortran — компилятор FORTRAN, которым мы нашу модель будем компилировать.

ncview — простейший просмотрщик netCDF файлов

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

тут вводим пароль cvsanon

начнется процесс загрузки. Размер загруженной, в итоге, папки с именем MITgcm будет около 300 мегабайт.
Вариант попроще и понадежнее — скачать последний чекпоинт, вариант модели, который работает и работает правильно отсюда. Тогда вы можете быть уверены, что за пол часа до того как вы скачали код, кто-то из разработчиков не внес в него изменения не совместимые с жизнью.

Зайдя в директорию модели вы увидите 12 поддиректорий, про большинство которых можете пока забыть. �?нтересовать нас будут для начала папки model и pkg. Внутренности MITgcm устроены следующим образом — есть ядро, которое обеспечивает основные функции модели и есть пакеты (packages), которые обеспечивают дополнительный функционал.

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

Как не сложно догадаться основное ядро лежит в папке model, а пакеты в папке pkg. Вы можете по ним побродить ради любопытства, но для запуска модели там ничего изменять не нужно. Наш путь лежит в папку verification. Здесь расположены уже подготовленные «эксперименты», то есть сконфигурированные особым образом наборы файлов, которые при компиляции и запуске модели будут обеспечивать ее работу в различных режимах, при различных условия и т. д. Тут и простейший океан в виде бокса на вращающейся сфере, отдельные моря и даже отдельные склоны. Описание того в какой папке какой эксперимент находится можно найти здесь. Предлагаю не размениваться на боксы и сразу начать с чего-нибудь более-менее реалистичного. Эксперимент в папке tutorial_global_oce_latlon будет моделировать океан на сетке 4×4 градуса, включает в себя реалистичную топографию и 15 уровней по глубине. Скромненько и со вкусом. Его подробное описание тут.

Перейдя в папку tutorial_global_oce_latlon мы снова увидим несколько поддиректорий, назначение которых следующее:

build — в данный момент пуста, в ней мы будем компилировать наш код

code — содержит файлы, которые необходимы для настройки базовых параметров модели перед ее компиляцией. То какие пакеты будут включены в модель, какие опции этих пакетов будут использоваться, каков будет размер сетки на которой мы будем считать и т.д.

CVS — служебная папка cvs, забудьте про нее.

diags_matlab — папка со служебными матлабовскими скриптами, позволяющими анализировать вывод модели

input — папка, в которой содержатся файлы с настройками для которых не нужна перекомпиляция модели, также там находятся файлы с батиметрией, файлы описывающие сетку модели, файлы с внешним форсингом (например атмосферными параметрами).

results — в папке служебный вывод модели для сравнения с вашим выводом

run — пустая папка, в которой мы, впоследствии, будем запускать модель.

Тут в общем ничего обязательного и заданного нет, если вы понимаете, что делаете то можете и модель в папке input запускать и компилировать в code. Однако такая структура и разделение на практике довольно удобна и лучше её придерживаться.

Перейдем в папку code. Здесь мы будем придавать форму нашей будущей модели, то есть определять, какие пакеты в нее будут включены, и как эти пакеты будут настроены. Первым файлом, представляющим для нас интерес будет packages.conf. Это простой текстовый файл, в котором один за одним перечислены пакеты, которые мы будем включать в модель. В нашем случае это:

много думать над ними не надо, просто посмотрите что они там есть. Набор не особо примечательный, и все параметры пакетов настроены по умолчанию. Откуда это видно? Дело в том, что у каждого уважающего себя пакета есть файл NAME_OPTIONS.h, где NAME — название пакета заглавными буквами. Расположен этот файл в директории пакета (…./MITgcm/pkg/name). В этом файле задаются основные настройки для пакета. Если вы хотите изменить эти настройки, то копируете этот файл в папку code (на самом деле в любую папку где будет происходить компиляция) и изменяете его параметры. Перед компиляцией, в папку где будет проводится компиляция, копируются все необходимые файлы (из папок model и pkg), но если файл с таким именем в папке уже присутствует, то он не заменяется. Таким образом при компиляции будет использован не файл из исходных текстов, а измененный вами файл.

Это используется не только для настройки пакетов, но и для хаков, хакнутый файл не заменяется на файл из исходников и используется при компиляции. Это произойдет, например, с файлами ptracers_forcing.F и ptracers_forcing_surf.F, которые были изменены для данного эксперимента, и оригиналы которых находятся в папке пакета ptracers. К счастью обычно хакать фортрановские файлы не нужно и все о чем вам нужно беспокоиться это NAME_OPTIONS.h.

Отсутствие файлов вида NAME_OPTIONS.h в папке code значит, что использоваться будут значения по умолчанию. Вообще такая ситуация не очень характерна для «взрослых» экспериментов, поскольку там присутствует по крайней мере файл определяющий основные настройки модели CPP_OPTIONS.h . Оригинал его находится в …../MITgcm//model/inc . Давайте скопируем его в нашу папку code

В принципе никакого влияния на будущую компиляцию модели это наше действие не окажет, поскольку изменять CPP_OPTIONS.h мы не собираемся, вы можете поэкспериментировать с этим в будущем. Сейчас просто предлагаю на него посмотреть в вашем любимом текстовом редакторе. Внутри вы видите кучу параметров, которые по умолчанию включены (стоит флаг #define) или отключены (#undef). Включать и выключать их вы можете меняя один флаг на другой. Есть еще параметры, которые включаются в зависимости от того включен (#ifdef) или отключен (#ifndef) другой параметр. Ели вы не знаете, что делаете, то, как обычно, лучше оставлять умолчальные настройки.

Примерно также выглядят NAME_OPTIONS.h файлы пакетов, и, повторюсь, для их настройки вы копируете NAME_OPTIONS.h в ту папку где будет производиться компиляция и изменяете их.

Последний файл, который нам нужно обсудить в папке code — SIZE.h. Здесь вы задаете размеры вашей сетки, то как вы ее разобьете на квадратики и скольким процессорам отдадите на съедение. Когда дойдете до компиляции на многопроцессорных машинах можете помедитировать на эту полезную картинку до полного просветления:

Пока же, поскольку процессор у нас один, то сильно выпендриваться мы не будем, и даже уберем разделение на тайлы, заменив nSx = 2, на nSx = 1. В этом случае нам нужно также заменить sNx = 45, на sNx = 90. На будущее, всегда проверяйте, что общее количество точек по «горизонтали» Nx = sNx*nSx*nPx и по «вертикали» Ny = sNy*nSy*nPy. �?менно по этой причине изменив nSx на 1 нужно поменять sNx на 90, чтобы баланс сошелся 🙂 То, что Nr = 15 значит, что у нас 15 уровней глубины. Все сходится, поехали дальше.

Почему я все время твержу, что нужно копировать файлы в папку, в которой будет производиться компиляция, а копирую их в code, компилировать, в котором ничего не планируется? Потому что папочка code служит своеобразным бекапом и напоминанием о том, что мы поменяли, а что нет. Саму же компиляцию будем проводить в папке build. Перейдите в папку build и наберите:

все что вы наворотили в папке code скопируется в build.

Комментарий от Сергея Семина: Место, где вы копируете доплненный исходный код в папку build. Это делать не очень удобно, так как в случае исправления исходного кода придется все еще раз копировать. Тут есть два выхода либо создать символьные ссылки, либо воспользоваться ключем утилиты genmake2 -mods=’/path/to/code/directory’. Путь может быть как абсолютный, так и относительный. Я обычно пользуюсь последним вариантом.

Теперь нам нужно подготовиться к компиляции. Для этого служит утилита genmake2. У нее много разных полезных опций, но мы воспользуемся только одной «-of«, задающей путь до файла, в котором прописаны флаги компилятора, пути к библиотеками и другая полезная муть. Выглядит это будет так:

Можете заглянуть в директорию ../../../tools/build_options/ , чтобы полюбоваться на то для скольких возможных комбинаций систем и компиляторов добрые люди понаписали файлов. Если linux_ia32_gfortran не сработает (например вы используете архитектуру отличную от ia32) можете попробовать что-нибудь более подходящее для вашего случая.

Комментарий от Сергея Семина: Ключ -of /path/to/optfile во многих случаях не обязательный, утилита genmake2 как правило сама умеет определять архитектуру, компилятор и задавать нужные пути до библиотек netcdf.

Если в результате работы genmake2 не возникло проблем, то можно продолжать. Сначала сделаем

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

и наслаждаемся бегущими по экрану значками. Если компиляция пройдет успешно, в директории build должен будет появиться файл mitgcmuv — это и есть ваша скомпилированная модель.

О том как заставить эту модель работать в следующей серии.