Видение будущего. 
СFD (ComputationalFlowDynamic) системы и их использование

Ханна и Парри (2011) описали их видение будущего следующим образом: «По мнению авторов „Святой Грааль“ ВГД выглядит следующим образом: в режиме реального времени, только нажмите на кнопку, автоматизированное, простое в использовании, двунаправленное, с поддержкой мультифизичности ВГД. Сегодня некоторые ВГД продукты находятся ближе к этим идеалам, некоторые дальше, но еще многое должно быть сделано, чтобы достичь этой нирваны в ближайшие 20 лет, в том числе со стороны аппаратного обеспечения, алгоритмического, физического моделирования и достижений в промышленности». Такая долгосрочная цель, однако, может быть достигнута лишь постепенно. Как замечают сами авторы, на пути предстоит решить еще множество проблем. Возможно эту конечную цель потребуется периодически обновлять, ведь окружающие факторы процесса проектирования также подвержены изменениям — ВГД это итерационный процесс! В следующем разделе рассматриваются некоторые вехи, стоящие на пути к «Святому Граалю».

Мультифизичность

Важный аспект «Святого Грааля» ВГД — более реалистичное представление сложной физической реальности, без искуственных «ограничений», которые существуют сегодня, сформировавшихся по мере истории развития ВГД: вычислительной строительной механики, многотельной динамики, кинематики и т. д. как отдельных дисциплин, использующих различные численные техники. Первые признаки этого уже проявляются в том, что стало широко известно как мультифизичное моделирование. Однако это часто означает немного большее, чем подстановка результатов одного моделирования (например, термического анализа) в качестве начальных или граничных условий для другой модели (например, термо-механической напряженности). Некоторые поставщики ПО, такие как ANSYS и COMSOL выбрали мультифизичность основным аспектом философии своих продуктов и предоставляют широкий спектр возможностей моделирования. Тем не менее, сегодня в центре внимания мультифизичных приложений освоение функций и решение технических проблем, которые возникают при совместной работе отдельных компонентов из-за их исторически сложившихся или технических различий, которые могут стать причиной несовместимости. На помощь в решении этой проблемы приходят фреймворки, которые предоставляют необходимую инфраструктуру для совместной работы. Эти фреймворки могут быть результатом работы поставщика мультифизичного приложения или предоставляться независимыми сторонними разработчиками как промежуточное ПО (middleware). Одним из таких примеров является FraunhoferMpCCIFramework.

Рисунок 9. MpCCIVizualizer от Fraunhofer SCAI (Fraunhofer SCAI, 2012).

Другим ограничивающим фактором сегодняшних мультифизичных подходов является корректное представление фактической физической ситуации для отдельных модулей решателя, необходимое для данного проекта моделирования. Для того, чтобы гарантировать, что результаты одного моделирования можно использовать в качестве входных данных для следующего, часто необходимо иметь модель в стиле «белого ящика», которая принимает исходную геометрию без каких либо упрощений и требует моделирования всех соответствующих физических эффектов со всеми деталями, с дополнительными вычислительными расходами. Модели «черного ящика», которые могут обеспечить значительный прирост эффективности моделирования, но ограничиваются лишь одним из аспектов проблемы (например, тепловая модель электронного компонента), не подходят под эту парадигму. Сегодня, выбор подходящих модулей, их конфигурация и расположение в рабочем процессе моделирования — за все отвечает пользователь, актуальный рабочий процесс определяется комбинированными требованиями к модулям решателя, а не физикой технического задания. Поэтому данной ситуации скорее всего более подходит название «мультивычисления». Необходимым условием для будущего успеха такого подхода будет не просто связь, а скорее объединение отдельных решателей в единую, последовательную методологию решения, которая позволит пользователю сосредоточиться на физике (возможно только на одном разделе физики) и получить среду моделирования, в которую можно подставить любые необходимые численные методы, которые не будут противоречить друг другу. Эта среда должна быть дополнена подходом проектирования на основе опыта взаимодействия (UX), что сместит внимание с «просто осуществить проект» на «эффективно решить поставленную инженерную задачу» как на более важный критерий.