№17 Суперкомпьютерное моделирование в геотехнике: когда оно нужно и сколько ресурсов заказывать

Где это вообще возникает

В повседневных изысканиях суперкомпьютер не нужен — рабочей станции хватает с запасом. Но есть класс задач, где расчёт быстро вырастает до размеров, которые обычный ПК уже не тянет:

крупные 3D-модели теплового режима мерзлоты под сооружением с прогнозом на десятки лет; связанные термо-гидро-механические задачи (промерзание–оттаивание с деформациями); фильтрация и устойчивость больших грунтовых плотин и хвостохранилищ; сейсмический отклик площадки в полной 3D-постановке; взаимодействие «тоннель–массив» на протяжённых участках. Общее у них одно: мелкая сетка, много элементов, длинный счёт по времени — и всё это в одной модели.

Признаем честно: в практике большинства изыскателей такое встречается редко. Но когда встречается — задача из «посчитаем за ночь» превращается в «это не влезает в память и считается неделю».

Почему это упирается в железо

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

Но аренда ставит конкретный вопрос: сколько узлов и памяти заказывать? Возьмёшь с запасом — переплатишь за простаивающие ядра. Возьмёшь впритык — задача не влезет или будет считаться неприемлемо долго. Ниже — методика прикидки «на салфетке», чтобы прийти к провайдеру с обоснованной цифрой, а не наугад. Сразу оговорюсь: это не замена нагрузочному тесту, а способ получить стартовое число для первого разговора.

Две вещи, которые надо понять до формул

Первое. При решении задач сплошной среды неявными конечно-объёмными методами львиную долю времени занимает решение системы линейных уравнений (СЛАУ). А её ресурсоёмкость определяется в первую очередь количеством граней сетки, а не числом ячеек. Поэтому оценивать задачу только по ячейкам — ошибка: одинаковое число ячеек при разном типе элементов даёт разную нагрузку. Всегда дополняйте число ячеек числом граней.

Второе. Скорость счёта зависит прежде всего от эффективности работы с памятью — кэшей ядер, частоты и числа каналов ОЗУ, то есть от эффективной пропускной способности памяти, а не от «голых гигагерц». Узкое место — почти всегда память, а не FLOPS.

Идея методики простая: у вас есть небольшая задача, уже посчитанная на известном железе (хоть на своей станции), и большая, которую надо посчитать на кластере. Масштабируем от известного к желаемому по двум критериям — по памяти и по пропускной способности — и берём худший случай.

Критерий 1. По объёму оперативной памяти

Nodes_m = 1.333 × M_smol × (F_big / F_smol) / M_node

где M_smol — пиковое потребление памяти на маленькой задаче, M_node — объём ОЗУ на узле кластера, F_smol и F_big — число граней в маленькой и большой задачах. Коэффициент 1.333 (запас ~33%) закрывает рост потребления памяти при декомпозиции сетки на много MPI-процессов и автоматическое поведение AMG-решателя.

Критерий 2. По пропускной способности памяти

Для стационарной постановки с постоянным шагом по времени (pseudo-transient):

Nodes_bw = 1.333 × BW_smol × (F_big / F_smol) × (TS_smol / TS_big) × (T_smol / T_big) / BW_node

Для постановки с постоянным числом Куранта:

Nodes_bw = 1.333 × BW_smol × (F_big / F_smol) × (C_big / C_smol)^(1/3) × (CFL_smol / CFL_big) × (T_smol / T_big) / BW_node

где BW_smol и BW_node — пропускная способность памяти системы на маленькой задаче и на одном узле кластера; TS — шаг по времени; T_smol — фактическое время счёта маленькой задачи, T_big — желаемое время счёта большой; C — число ячеек; CFL — число Куранта.

Итог: Nodes = max(Nodes_m, Nodes_bw).

Пример: тепловой режим мерзлоты под свайным полем

Пусть небольшую задачу мы уже посчитали на рабочей станции:

• ячеек — 2 млн, граней (F_smol) — 6 млн;
• пиковая память (M_smol) — 60 ГБ;
• время счёта (T_smol) — 10 часов;
• пропускная способность памяти станции (BW_smol) — 100 ГБ/с.

Теперь нужна детальная модель того же объекта — мельче сетка, больше зона, прогноз на десятки лет:

• ячеек — 20 млн, граней (F_big) — 60 млн (в 10 раз больше);
• желаемое время счёта (T_big) — 24 часа.

Узел арендуемого кластера: память M_node — 256 ГБ, пропускная способность BW_node — 400 ГБ/с. Постановка — pseudo-transient, шаг по времени тот же (TS_smol/TS_big = 1).

По памяти:
Nodes_m = 1.333 × 60 × (60/6) / 256 = 1.333 × 600 / 256 ≈ 3.1 → 4 узла.

По пропускной способности:
Nodes_bw = 1.333 × 100 × 10 × 1 × (10/24) / 400 = 1.333 × 416.7 / 400 ≈ 1.4 → 2 узла.

Итог: max(4, 2) = 4 узла. В этом сценарии задача упирается в память, а не в скорость.

Но обратите внимание, как всё меняется от вашего дедлайна. Если тот же расчёт нужен не за сутки, а за 6 часов, критерий по пропускной способности даёт уже ≈ 6 узлов — и теперь он становится ограничивающим, а не память. То есть срок счёта напрямую превращается в деньги за узлы: чем жёстче дедлайн, тем больше ресурсов надо заказать.

Одно честное ограничение

Снижением удельной производительности узлов из-за накладных расходов на межпроцессорные и межузловые обмены здесь в первом приближении пренебрегаем — это допустимо, пока удельный объём кэшей на фиксированное число граней растёт. На очень больших разбиениях обмены начнут съедать эффективность, и линейная прикидка «поедет». Тогда без реального масштабного теста уже не обойтись — но для первого разговора с провайдером этой оценки достаточно.

Вопрос к аудитории

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