на прошлой неделе я впервые за долгое время вспомнил, что я вообще-то дипломированный специалист по механике жидкости и газа и впервые хотя бы понял, какую именно задачу решали OpenAI. и уравнения Навье-Стокса вообще дают очень красивую лестницу сложности. от школьного f=ma до сложных разделов математики: гильбертовы пространства, функциональный анализ, теория меры. плюс ты всё ещё остаёшься в каком-то осязаемом физическом поле. для твёрдого тела всё относительно понятно: есть масса и ускорение. а жидкость в каждой точке в один момент времени может двигаться с разной скоростью и в разном направлении. поэтому вместо одной координаты `x(t`) мы описываем поле скорости `u(x,y,z,t)` то есть скорость жидкости в каждой точке пространства в каждый момент времени. дальше в уравнении появляются давление, вязкость, внешние силы, условие несжимаемости и одна особенно неприятная штука, это конвективный член `(u·∇)u.` жидкость сама переносит собственное поле скорости. то есть состояние потока влияет на то, как поток будет меняться дальше. эта нелинейность и есть источник огромной части сложности. вокруг взаимодействия нелинейности и вязкости появляется вся богатая динамика турбулентного течения. всё, что поток делает с маленьким кусочком жидкости, сводится к двум вещам: он его переносит и он его деформирует. вращение этого кусочка и есть вихрь. а турбулентность это просто вихри всех масштабов сразу. но у жидкости есть свойство несжимаемости. объём кусочка постоянный, поэтому если поток вытянул его вдоль одной оси, он обязан стать тоньше по двум другим. а вращающийся объект, который стал тоньше, начинает крутиться быстрее. вот это и есть машинка, которая гонит энергию вниз по масштабам. поток растянул вихрь, вихрь стал тоньше и быстрее, рядом появились вихри помельче, и с ними происходит то же самое. а сама задача давно живёт в мире функциональных пространств. скорость это не число, а точка в бесконечномерном пространстве. в инженерии всё это решают численно. пространство режется на миллионы маленьких ячеек, время на маленькие шаги, и компьютер последовательно приближённо считает давление и скорость. проблема в том, что в турбулентном потоке ячейка должна быть мельче самого мелкого вихря. честный расчёт, до последнего вихря и без единой модели турбулентности, называется DNS (direct numerical simulation ака численные методы). звучит как единственно правильный подход, но цена растёт нелинейно - удвоил скорость потока счёт подорожал в восемь раз. поэтому DNS живёт в исследовательских задачах с простой геометрией, вроде течения в канале, а до крыла или кузова не доезжает вообще. а инженеру нужны крыло и лопатка, поэтому в реальных расчётах считают не всё: либо усредняют турбулентные пульсации и моделируют их влияние на средний поток (RANS), либо считают крупные вихри напрямую, а мелкие моделируют (LES). в какой-то момент deep learning тоже дошёл до этой области. логика простая: если у тебя уже лежит архив из тысяч посчитанных продувок, почему бы не научить сетку сразу выдавать ответ, минуя солвер. это называется суррогатной моделью, быстрая приближённая замена дорогого расчёта. допустим, обычный расчёт крыла занимает часы. ты много раз гоняешь настоящий солвер для разных форм, углов атаки и скоростей, получаешь датасет из геометрии, условий и характеристик течения, и дальше учишь модель отображать геометрию сразу в поле давления и скорости. у такой модели есть очевидная слабость: она знает только то семейство задач, на котором её учили. поэтому идею довели до двух более амбициозных версий. neural operators вроде FNO учат не одно решение, а сам оператор перехода «условия задачи → решение», чтобы модель работала на всём классе, а не на виденном. самый заметный подход в этой области за последние годы, PINN, physics-informed neural network, устроен принципиально иначе: он вообще обходится без датасета. сетка там не аппроксимирует чужие ответы, она сама является решением. на вход ей подают координаты` x, y, z, t,` а на выходе она отдаёт скорость и давление в этой точке. то есть сетка и есть то самое поле u(x,y,z,t), просто записанное весами вместо формулы. функция потерь задизайнена так: суррогат штрафуют за расстояние до ответов солвера, а PINN за то, что его выход не удовлетворяет Навье-Стоксу: невязка уравнения и есть лосс. производные для неё берутся бесплатно, тем же автоматическим дифференцированием, которым при обучении считают градиенты. начальные и граничные условия идут отдельными слагаемыми. идея красивая, и в 2019-2021 на ней был настоящий хайп, все лабы делали свой PINN. но один обученный PINN решает одну конкретную задачу. поменял геометрию крыла или скорость на входе — переобучай с нуля. обычный численный солвер за полвека отполирован так, что на той же задаче он просто быстрее и точнее. вся конструкция упирается в одну вещь. суррогат не отменяет солвер, он его амортизирует, чтобы обучить сетку, кто-то сначала должен посчитать корпус обычным численным методом. публичный DrivAerNet++, на котором учится половина этой области, это 8150 геометрий, около 3 миллионов процессорных часов и 39 терабайт, посчитанных на OpenFOAM