Введение
В данной статье описывается история развития инструментов моделирования потока, переноса тепла, массы: появление первых коммерческих программ в 1960-1980-х, последующая эра методов, основанных на неструктурированной сетке, начавшаяся приблизительно в 1990-х и закончившаяся в середине 2000-х. Эта эра характеризовалась появлением вычислительной гидродинамики (ВГД или CFD — Computational Fluid Dynamics) в научных и конструкторских отделах крупных компаний. После этих двух больших периодов-волн в разработке коммерческого ВГД программного обеспечения (ПО), наблюдается третья волна.
Рисунок 1. Моделирование потока воздуха в 1980-х, Ханна и Парри (2011).
Она характеризуется обновленной парадигмой использования ВГД моделирования в процессе проектирования промышленного продукта. Новшества в парадигме коснулись процессов разработки, их направленность на проектирование на основе результатов моделирования, что повышает общую ответственность инженеров-расчетчиков, а также делает результаты моделирования единственной основой для принятия решений, которые затем могут иметь серьезные финансовые последствия. Такой перенос ответственности, в свою очередь, затрагивает и производителей ВГД ПО, которые должны не только улучшать существующие физические модели и увеличивать производительность решателей, но также быстро реагировать на изменяющиеся промышленные требования, новые подходы к внедрению ВГД моделирования в процесс проектирования продукта, новые бизнес модели покупки лицензий, инновационные концепции юзабилити.
Такие критерии как простота внедрения, надежность, безопасность моделирования и воспроизводимость становятся более важными при промышленном использовании ВГД, и со временем будут и дальше вытеснять исторически сложившиеся критерии — точность результата, повышение производительности, являвшиеся основными для разработчиков ВГД ПО. Превосходное и стабильное качество результатов моделирования, полученных с помощью новейших вычислительных аппаратных средств, ПО и математических алгоритмов, теперь рассматривается как данность. Новая “третья волна” в развитии коммерческого ВГД ПО подпитывается продолжающимся ростом производительности вычислительных и графических аппаратных средств, что ведет к более выгодному соотношению цена-качество. Это развитие, в дополнение к новшествам в технологии ВГД и новым требованиям к знаниям пользователя, характеризуют “третью волну”.
В данной статье проанализированы три фазы развития коммерческого ВГД ПО для проектирования, описаны в историческом контексте, рассмотрены возможные направления дальнейшего развития.
1. Три волны коммерческой ВГД
В настоящее время опубликовано много работ об истории моделирования потока. Ранее на эту тему выступали и писали такие пионеры ВГД как Брайан Сполдинг, Дэвид Тэтчелл, Ферит Бойсан, Майкл Энгелман. Собранный набор исторических фактов, технических данных и личных впечатлений авторов дают подробное представление о развитии инженерного моделирования от научных разработок до современных ВГД продуктов, которые мы знаем сегодня, которые разрабатываются и поддерживаются в промышленных масштабах многонациональными крупными компаниями. Из-за привязанности к существующим вычислительным аппаратным средствам, это развитие, в частности, на раннем этапе, происходило в основном за счет научно-исследовательских проектов для аэрокосмической и оборонной промышленности, но позднее все больше интереса проявлялось и со стороны гражданской промышленности. Оглядываясь назад, можно выделить три основные периода развития ВГД ПО:
- Первая волна: начало коммерческого ВГД ПО в 70-х и 80-х.
- Вторая волна: в 90-х, появление ВГД в научно-исследовательских и конструкторских отделах больших промышленных компаний.
Хороший обзор с обширной биографией содержится в работах Ханна и Парри (2011). Интересные доклады делались Рунчалом (2008) и Тотчеллом (2009).
1.1 Первая волна: Начало коммерческого ВГД ПО
Первые ВГД коды уходят корнями в работы Группы Вычислительной Гидродинамики T-3, работающей в Национальной Лаборатории Лос-Аламоса (США) с 1958, и исследовательские проекты под руководством профессора Сполдинга, Имперский колледж Лондона, в 1960-х и 1970-х.
В конце 1960-х, профессор Сполдинг, основал консалтинговую компанию CHAM Ltd. (Concentracion, Heat and Momentum — концентрация тепла и моментов), находившуюся в Имперском колледже Лондона. Эпоха коммерческого ВГД ПО началась в 1974 году, когда CHAM Ltd. переехала в собственный офис в Нью Мадлен, пригород Лондона. Изначально, разработка ВГД программ под нужды заказчика являлась основной деятельностью CHAM. Затем это стало слишком затратным по времени и неэффективным, поэтому в CHAM решили разработать ВГД пакет общего назначения для внутренней консалтинговой работы, затем выпустили его как коммерческий продукт PHOENICS в 1981. Этот факт можно рассматривать как рождение индустрии ВГД ПО (см. CHAM Ltd, 2008). Другие быстро последовали их примеру. Fluid Dynamics International (США) в 1982 выпустили FIDAP, ВГД пакет на основе метода конечных элементов (МКЭ), а Create Inc (США), в 1983 выпустила ВГД пакет на основе метода конечных объемов (МКО) Fluent. В 1980, доктор Хирт основал Flow Science (США) как филиал Национальной Лаборатории Лос-Аламос и в 1985 выпустил Flow-3D. Множество последующих ВГД пакетов, включая, например, Flow3D от Администрации Великобритании по атомной энергии (Англия) в 1987 и TASCflow, выпущенный Applied Scientific Computing (Канада) — сегодня оба существуют в составе ANSYS CFX. Computational Dynamics/ADAPCO (Англия/США), сооснователь профессор Дэвид Госман, еще один профессор Имперского колледжа Лондона, выпустили StarCD в 1989.
В начале 90-х, производитель рабочих станций Silicon Graphics, перечислил в своем каталоге ПО уже 18 коммерческих ВГД пакетов, которые были совместимы с их аппаратными продуктами, охватывающих около $30 млн. ВГД рынка (Бойсан и др., 2009). Основные технологии в этих ВГД пакетах было разработаны бывшими сотрудниками или внештатными учеными двух вышеупомянутых научно-исследовательских институтов — в Лондоне и Лос-Аламосе, либо основывались на их научных публикациях. Но существовали и другие разработчики ВГД технологии: в 1980-х появились альтернативные подходы к ВГД моделированию в рамках программы развития авиации и космонавтики в странах бывшего Советского Союза, в значительной степени незамеченные Западным научным сообществом из-за политической ситуации. Решаемые ими с помощью ВГД моделирования технические задачи были похожи на те, что существовали на Западе, но доступный аппаратный вычислительный ресурс для их решения был гораздо более ограничен. Тем не менее, из-за высокой политической приоритетности этих научно-исследовательских программ, были получены обширные экспериментальные данные для множества случаев потока жидкости, явлений теплообмена, особенно явлений течения в пристеночной области. Эта ситуация привела к появлению альтернативных методов ВГД, которые, основываясь на известных методах для Декартовых сеток, опубликованных на Западе, сочетали численные, аналитические и эмпирические данные. Такой инновационный подход дал возможность получать высококачественные результаты моделирования при низких требованиях к вычислительным ресурсам в сочетании с эффективностью методов, использующих Декартовые сетки. По ходу постепенной экономической либерализации Советского Союза, в конце 1980-х несколько команд ученых коммерциализировали эту ВГД технологию и, начиная с 1990-х, занялись продажей своих продуктов и услуг в Европе и Азии. Самыми известными продуктами такого рода были Aerospace-3D профессора Гаврилюк и его команды (Петрова, 1998 и Алямовский, 2008) и FlowVision доктора Аксенова и его команды (Аксенов и др. 2003).
Рисунок 2. Результаты моделирования в Aeroshape-3D (Парри и др., 2012)
Характерными чертами первого ВГД ПО были: примитивный по сегодняшним меркам пользовательский интерфейс ввода данных, рудиментарная графика и очень скромные вычислительные ресурсы, в частности, объем доступной ОЗУ памяти, которой постоянно не хватало, что сильно ограничивало максимальный размер модели. Эти ограничения приводили к очень высоким требованиям к пользователю в отношении моделирования геометрии и физики, а реальная задача должна была быть проанализирована, упрощена и передана в программу достаточно трудоемким способом. Неопределенности, присутствующие при выборе конфигурации физической модели и риск ошибки при вводе данных были очень велики, и, таким образом, возникала необходимость в комплексной оценке полученных данных, а проверка результатов моделирования была привычным очередным шагом рабочего процесса. Все это требовало обширных знаний в области численных методов, основ и ограничений физических моделей при их использовании в ВГД модели. Таким образом, пользователями ВГД технологии в то время были исключительно ученые и начно-подготовленные инженеры, которые могли частично или полностью сравнить результаты моделирования с экспериментальными данными. Этот период также характеризовался тем, что из-за ограниченного опыта работы с ВГД приложениями и высогой конкуренции на рынке ВГД ПО инструментов, производители, как правило, сильно переоценивали пригодность своих продуктов для решения производственных задач. Это, в сочетании с вопросами первых промышленных потребителей на счет достижимого с помощью ВГД качества результатов при заданной стоимости, чрезвычайно медленно повышало репутацию ВГД моделирования, итак чрезвычайно дорогого и со слишком расплывчатыми в плане пригодности для использования результатами. Эта отрицательная репутация сохранялась в большей части инженерного сообщества на протяжении более двух десятилетий, но ситуация изменилась в течение третьей фазы разработки ВГД ПО, когда ВГД моделирование стало повседневной работой для нового поколения пользователей.
В начале 1990-х, условия для ВГД ПО и моделирования достаточно быстро поменялись. Вычислительное оборудование, математические методы и физические модели — во всем ощущался огромный рост производительности. Скорость ЦПУ и размер ОЗУ быстро увеличивались и становились дешевле, предоставляя промышленным пользователям новые, более доступные аппаратные средства, такие как рабочие станции UNIX и PC, а чуть позднее, с появлением вычислительных кластеров, доступ к высокопроизводительным вычислениям (HPC). Эти новые возможности со стороны аппаратной части конечно же способствовали и развитию на стороне программного обеспечения. Численные методы, такие как неструктурированный Метод Конечных Объемов, многосеточные методы, динамические сетки и т.д. подходящие для сложных геометрий и оптимизированные для HPC, стали коммерчески доступными, а также более надежными, более гибкими и более широко применимыми для моделирования физических процессов. Таким образом появились новые области применения ВГД. Применимость ВГД технологии сильно возросла и наконец-то появилась возможность использовать реальные размеры моделей для существующих промышленных нужд. Ханна и Парри (2011) проанализировали это развитие и обнаружили прямую корреляцию между законом Мура для вычислительной мощности и, например, размером модели для гоночного автомобиля при ВГД моделировании. Эти новые возможности возвестили о наступлении новой эры в использовании коммерческого ВГД ПО — его появление в научных и конструкторских отделах промышленных компаний.
Рисунок 3. Развитие ВГД относительно роста аппаратных возможностей — тенденции ВГД на примерах гоночных автомобилей Формулы 1 1990-2010 (Ханна и Парри, 2011)
1.2 Вторая волна: ВГД появляется в научно исследовательских отделах промышленных компаний
На основе технологий типичных для первой волны Flometrics Ltd., основанная в 1988 Дэвидом Татчеллом и Харви Ростеном в Кингстоне-на-Темзе (Англия), сыграла ведущую роль в маркетинге ВГД ПО, разработанного непосредственно для промышленных нужд, выпустив в 1989 пакет FloTHERM. Оба основателя работали в CHAM Ltd на руководящих должностях, прежде чем уйти и основать Flometrics с целью “обеспечения промышленности хорошей наукой” (Татчелл, 2009). FloTHERM внес первые изменениея в парадигму промышленной ВГД, бывший акцент на сложную ВГД технологию сместился больше в сторону решения инженерных промышленных задач, это стало основной целью. Это также означало, что отныне в разработке продукта участвуют инженеры, а не только лишь ученые, являвшиеся ранее единственными пользователями ВГД ПО. Тем не менее, существующие ВГД технологии, вычислительные аппаратные средства и операционные системы накладывали некоторые ограничения на такой инновационный подход. Поэтому Flometrics изначально сосредоточились лишь на двух прикладных областях: охлаждение электроники (FloTHERM) и взаимодействие с окружающей средой HVAC (FloVENT). Требования к инженерно-ориентированному ВГД ПО для этих областей в то время уже были относительно четко определены и, что более важно, была возможность их удовлетворить.
Рисунок 4. Ранняя версия FloTHERM (Ханна и Парри, 2011)
Такая концепция открыла совершенно новые возможности рынка, потомучто впервые охватывалась гораздо более обширная группа пользователей, имеющих промышленные задачи и опыт их решения. Также это был тот момент, когда инженеры смогли без специфичных знаний численных методов и не имея обширного опыта работы с ВГД использовать ВГД моделирования в качестве инструмента проектирования продукта. Решение технической инженерной задачи оказалось в центре внимания, в то время как лежащая в основе технология ВГД отошла на второй план.
Очевидно, что остальные поставщики ВГД также признали это смещение парадигмы и отметили новые возможности для бизнеса, отреагировав на эту тенденцию своими предложениями. Таким был, например, MixSim, выпущенный в 1996, имевший специфичный интерфейс для моделирования процесса смешивания и основанный на решателе Fluent. Компания Fluid Dynamics International вышла на рынок ВГД для охлаждения электроники со своим продуктом Icepak, основанном на FIDAP решателе, а CD Adapco представила различные инженерные спец инструменты для автомобильной промышленности. Новые компании такие как Exa Corporation (разработчики PowerFlow) и Blue Ridge Numerics (разработчики CFdesign) увидели новые возможности и вышли на рынок ВГД продуктов со своими спец инструментами для промышленных задач. В целом, наблюдались инвестиции от всех поставщиков ВГД ПО для улучшения пользовательских интерфейсов, производительности решателей и повышения надежности физических моделей с целью закрепления ВГД в научно-исследовательских и опытно-конструкторских отделах крупных промышленных компаний, таким образов привлекая новое поколение ВГД пользователей.
Эта вторая волна разработки ВГД ПО для промышленных задач закончилась в начале 1990-х середине 2000-х. Она характеризовалась сочетанием доступности качественного ВГД моделирования и использованием более дешевых и более производительных вычислительных средств. Это породило резкий рост спроса на ВГД моделирование, особенно со стороны крупных компаний, что побудило производителей ВГД ПО проводить дальнейшую демократизацию ВГД технологии. Тем не менее, многие пользователи заметили еще одну тенденцию, характеризующую данный период: начало укрупнения игроков в отрасли ВГД ПО за счет приобретений и уходов некоторых участников с рынка. Многие появившиеся ВГД системы устаревали и требовали больших вложений для дальнейшего развития. Большинству поставщиков ВГД ПО не хватало запланированного равномерного роста доходов. Резкое увеличение затрат на разработку и более жесткая конкуренция вынуждала компании объединять свои силы, чтобы оставаться конкурентоспособными и решать возникающие проблемы в будущем. Во время этого периода были заложены основы для многочисленных приобретений которые привели к появлению ВГД компаний с штатом в несколько тысяч сотрудников и которые по настоящее время являются доминирующими на рынке ВГД ПО.
Рисунок 5. Пользовательский интерфейс FIDAP в конце 1990-х (Университет Делавера, 2007)
После закрепления ВГД в качестве успешного инструмента для функционального дизайна, верификации и оптимизации проектирования продукта, процессов, характеристик продукта — в крупных промышленных компаниях в 2000-х, репутация этой технологии среди инженеров значительно повысилась. Сотнями примеров было доказано, что при корректных действиях пользователя в процессе моделирования, использование коммерческого ВГД ПО может привести к экономии времени и затрат на проектирование. В результате сильно вырос спрос на ВГД, особенно в средних и малых компаниях, которые теперь могли сократить расходы, связанные с изготовление прототипов, которое им часто приходилось заказывать у сторонних компаний. Тем не менее, высокая стоимость ВГД моделирования по отношению к стоимости физических экспериментов в начале 2000-х годов все еще была серьезным препятствием. Эти расходы были связаны прежде всего с расходами на персонал: обучить или нанять высококвалифицированных пользователей, относительно длинный путь от пользователя, прошедшего обучения до специалиста, утомительный процесс моделирования (особенно если геометрия сложная), и сравнительно высокая стоимость лицензий на используемое ПО. Еще один важный аспект заключался в необходимости интеграции ВГД моделирования в процесс проектирования продукта, так как эти компании чаще всего не имели специального отдела моделирования (пока). Это означало, что инженеры из группы конструкторов или дизайна должны самостоятельно выполнять моделирование, и эффективность проектов моделирования должна повыситься за счет того, что результаты ВГД будут доступны почти одновременно с выполнением циклов проектирования продукта, что позволит формировать предложения по улучшению дизайна.
Рисунок 6. Пирамида использования ВГД (Ханна и Парри, 2011)
Обработка геометрии промышленного уровня сыграла ключевую роль. В то время данные о геометрии уже предоставлялись в виде 3D CAD, которые затем использовались с наименьшими модификациями и упрощениями для последующей автоматизированной генерации сетки. Рынок ВГД ПО ответил на эти требования множеством новых, улучшенных продуктов и третья волна ВГД ПО для проектирования промышленных продуктов начавшаяся тогда продолжается по сей день.
1.3. Третья волна: ВГД становится важным элементом процесса проектирования продукта
На третьем этапе основную роль играют основные CAD и PLM производители. С 1990-х они успешно внедряют концепцию управления жизненным циклом продукции (Product Lifecycle Management PLM), которая охватывает в том числе и CAE. В результате потребители оказываюли давление на поставщиков коммерческого ВГД ПО, чтобы те соответствовали этой концепции и принимали меры по интеграции своих продуктов в основные PLM системы. Таким образом в 2000-е практически все производители ВГД ПО добавили в свои системы как минимум новые интерфейсы импорта CAD. Многие разработали двунаправленные связи с основными CAD/PLM системами, некоторые встроили свои ВГД технологии непосредственно в 3D CAD системы.
Производители CAD систем поддержали эти нововведения, чтобы предоставить завершенное решение в фреймворке PLM системы, обеспечив поддержку через внешние специализированные модули разработчика. На этом этапе были объединены такие продукты как Fluetn for CATIA (Fluetn Inc), CFdesign (Blue Ridge Numerics) и FloWorks (NIKA GmbH). Также для поддержки этих новых требований были разработаны новые ВГД техники. Например, с 1999 CD-Adapco успешно использует инновационный объектно-ориентированный подход в разработке STAR-CCM+. Компания NIKA GmbH, основанная в 1999 как совместное Немецко-Российское предприятие, стала типичным примером поставщика нового коммерческого ВГД ПО в начале третьей волны. NIKA разработана на основе выше упомянутой технологии Aerospace-3D, ВГД ПО со встроенным CAD, которое сегодня поставляется в качестве отдельных модулей основной 3D CAD системы (Рис. 7).
Рисунок 7. FloEFD для Creo от Mentor Graphics
В ответ на эти меняющиеся условия рынка Blue Ridge Numerics представила пакет CFdesign как “Авансовую ВГД” систему. Сами поставщики PLM также расширили (за счет стоимости приобретения) свою деятельность в области CAD-интегрированного ВГД ПО для обеспечения лучшей поддержки процесса проектирования продукта. Представителями этого сегмента рынка являются Dassault Systemes и их SIMULIA Abaqus/CFD, и Siemens PLSM с их NX Advanced Flow и Femap Flow Solvers. Autodesk также усилил свое портфолио ВГД ПО за счет приобретения CFdesign от Blue Ridge Numerics в дополнение к их набору Algor.
Продолжающаяся третья волна предоставила новичкам из других областей возможность выйти на рынок ВГД, освежив его новыми передовыми технологиями. Таким примером стал XFlow от Next Limit Technologies (Испания), которые привнесли в инжиниринговое сообщество не столько свою альтернативную технологию ВГД, корни которой шли из киноиндустрии, сколько новый пользовательский интерфейс больше похожий на интерфейс анимационного ПО. Project Falcon от Autodesk также привнес игровые элементы в мир ВГД.
Рисунок 8. Пользовательский интерфейс XFlow от Next Limit Technologies (MSC Software, 2011)
Похоже, что складывалась следующая тенденция: рынок ВГД ПО становится все более разнообразным за счет новых, инновационных, нетрадиционных подходов, особенно в области опыта взаимодействия (User Experience UX) и юзабилити. Но у всех была одна общая черта: промышленный пользователь, с его или ее потребностью в легком для использования, ориентированном на цель, автоматизированном, надежном, эффективном и легкодоступном ВГД ПО, которое стало бы незаменимым инструментом при создании электронного прототипа. Это вызвано изменениями в процессах разработки и, как следствие, изменением роли инженера-расчетчика. Такие аспекты как процесс интеграции, надежность, безопасность моделирования, воспроизводимость становятся основными при решении о покупке того или иного ВГД ПО. Дальнейшее развитие ВГД ПО также будет основано на этих требованиях и приведет к появлению на рынке новых захватывающих технологий и продуктов. Таким образом в ближайшее время можно ожидать появление четвертой волны…
2. Что дальше — Видение
Ханна и Парри (2011) описали их видение будущего следующим образом: “По мнению авторов “Святой Грааль” ВГД выглядит следующим образом: в режиме реального времени, только нажмите на кнопку, автоматизированное, простое в использовании, двунаправленное, с поддержкой мультифизичности ВГД. Сегодня некоторые ВГД продукты находятся ближе к этим идеалам, некоторые дальше, но еще многое должно быть сделано, чтобы достичь этой нирваны в ближайшие 20 лет, в том числе со стороны аппаратного обеспечения, алгоритмического, физического моделирования и достижений в промышленности”.
Такая долгосрочная цель, однако, может быть достигнута лишь постепенно. Как замечают сами авторы, на пути предстоит решить еще множество проблем. Возможно эту конечную цель потребуется периодически обновлять, ведь окружающие факторы процесса проектирования также подвержены изменениям — ВГД это итерационный процесс! В следующем разделе рассматриваются некоторые вехи, стоящие на пути к “Святому Граалю”.
2.1 Мультифизичность
Важный аспект “Святого Грааля” ВГД — более реалистичное представление сложной физической реальности, без искуственных “ограничений”, которые существуют сегодня, сформировавшихся по мере истории развития ВГД: вычислительной строительной механики, многотельной динамики, кинематики и т.д. как отдельных дисциплин, использующих различные численные техники. Первые признаки этого уже проявляются в том, что стало широко известно как мультифизичное моделирование. Однако это часто означает немного большее, чем подстановка результатов одного моделирования (например, термического анализа) в качестве начальных или граничных условий для другой модели (например, термо-механической напряженности).
Некоторые поставщики ПО, такие как ANSYS и COMSOL выбрали мультифизичность основным аспектом философии своих продуктов и предоставляют широкий спектр возможностей моделирования. Тем не менее, сегодня в центре внимания мультифизичных приложений освоение функций и решение технических проблем, которые возникают при совместной работе отдельных компонентов из-за их исторически сложившихся или технических различий, которые могут стать причиной несовместимости. На помощь в решении этой проблемы приходят фреймворки, которые предоставляют необходимую инфраструктуру для совместной работы. Эти фреймворки могут быть результатом работы поставщика мультифизичного приложения или предоставляться независимыми сторонними разработчиками как промежуточное ПО (middleware). Одним из таких примеров является Fraunhofer MpCCI Framework.
Рисунок 9. MpCCI Vizualizer от Fraunhofer SCAI (Fraunhofer SCAI, 2012)
Другим ограничивающим фактором сегодняшних мультифизичных подходов является корректное представление фактической физической ситуации для отдельных модулей решателя, необходимое для данного проекта моделирования. Для того, чтобы гарантировать, что результаты одного моделирования можно использовать в качестве входных данных для следующего, часто необходимо иметь модель в стиле “белого ящика”, которая принимает исходную геометрию без каких либо упрощений и требует моделирования всех соответствующих физических эффектов со всеми деталями, с дополнительными вычислительными расходами. Модели “черного ящика”, которые могут обеспечить значительный прирост эффективности моделирования, но ограничиваются лишь одним из аспектов проблемы (например, тепловая модель электронного компонента), не подходят под эту парадигму.
Сегодня, выбор подходящих модулей, их конфигурация и расположение в рабочем процессе моделирования — за все отвечает пользователь, актуальный рабочий процесс определяется комбинированными требованиями к модулям решателя, а не физикой технического задания. Поэтому данной ситуации скорее всего более подходит название “мультивычисления”.
Необходимым условием для будущего успеха такого подхода будет не просто связь, а скорее объединение отдельных решателей в единую, последовательную методологию решения, которая позволит пользователю сосредоточиться на физике (возможно только на одном разделе физики) и получить среду моделирования, в которую можно подставить любые необходимые численные методы, которые не будут противоречить друг другу. Эта среда должна быть дополнена подходом проектирования на основе опыта взаимодействия (UX), что сместит внимание с “просто осуществить проект” на “эффективно решить поставленную инженерную задачу” как на более важный критерий.
2.2 Методы моделирования
Идея решателя общей физики кажется возможной для реализации, но при этом возникает проблема объединения нескольких очень разных, порой несовместимых численных методов. Это разнообразие методов, конечно, полезно, потомучто природа поведения различных физических факторов продукта очень разная и для каждого существует один или несколько подходящих численных методов, которые обеспечивают хорошую точность результата и эффективность решения при невысоких требованиях к вычислительными ресурсам.
В то же время, нежелательно жертвовать этим преимуществом и пытаться разработать единый процесс для всех возможных физических задач, который будет работать во многих областях, но значительно медленнее, чем каждое отдельное самостоятельное решение. Скорее цель должна заключаться в разработке инфраструктуры решателя, который будет автоматически использовать лучшие существующие методы для каждой ситуации, комбинировать и двунаправленно сочетать результаты как внутри одной модели, так и в случае нескольких моделей. Это означает, что должны быть интегрированы очень разные методы: методы дискретизации, такие как Метод Конечных Объемов для внутренних потоков; в сочетании с методами потоков частиц, таких как Гидродинамика Сглаженных Частиц для областей с несколькими физическими фазами и фазовым переходом; одномерные методы для систем с крупными потоками (гидродинамика). Многие элементы для осуществления такого подхода уже готовы, причем достаточно проработанны и надежны. Задача заключается в преодолении исторически сложившейся разобщенности модулей решателя в сторону единого движка моделирования, который будет комбинировать лучшие доступные методы, согласно моделируемой задаче. Большим преимуществом такого подхода является то, что он даст возможность полностью исключить из обязанностей инженера полное определение численного рабочего процесса, предоставляя ему рабочий процесс, сосредоточенный исключительно на инженерной задаче и ее решении. В этом отношении мы видим насколько долгий путь еще предстоит пройти к этому “Священному Граалю” ВГД.
2.3. Опыт взаимодействия (UX) и юзабилити
Несомненно, будущее развитие ПО для моделирования будет основано на потребностях инженера, как основного пользователя. Это ПО будет постоянно адаптироваться к рабочей среде пользователя, его потребностям и его индивидуальным интеллектуальным возможностям, а не наоборот. Это будет влиять как на общую концепцию, так и на каждую отдельную деталь ПО. Тоже относится к процессу описания продукта и внедрению, проводимому поставщиком ПО. Уже сегодня во многих компаниях, производящих ПО, внедрены современные процессы разработки, такие как Agile. Это обеспечивает естественный процесс применения ориентированных на пользователя принципов разработки, что также является необходимым условием для эффективного внедрения требований юзабилити с общей целью создать и поддерживать высокий уровень опыта взаимодействия (UX). Развитие в этом направлении несомненно приведет к появлению новых привлекательных продуктов на рынке ВГД ПО.
Рабочая среда инженеров и конструкторов также будет продолжать меняться. Появляются новые методы ввода, лучше отражающие естественные движения человека. К этому относится, например, появление сенсорных экранов и элементов дополненной реальности. Точно также появятся новые методы визуализации для более эргономичного и точного представления моделирования физической ситуации. От инженеров, технологов и рабочих, использующих печатные двумерные чертежи до печатающих трехмерные модели на 3D-принтере прошло менее 100 лет. Такие темпы развития сохранятся и инженер, в обозримом будущем, по-прежнему будет играть основную роль в принятии решения в процессе проектирования. Этот тренд, вызванный и активно поддерживаемый ПО моделирования, будет приобретать все большее значение. Визуализация и передача результатов моделирования при постоянно растущей зависимости от виртуального прототипирования для разработки рентабельной продукции тесно связана с увеличением ответственности инженера-расчетчика за сделанные им выводы.
Рисунок 10. Уровни методологии Agile — разработка, ориентированная на пользователя (Limina Application Office, 2012)
Тем не менее, изменения произойдут не только на абстрактном, но и на концептуальном уровне — так опыт взаимодействия (UX) и юзабилити будут играть гораздо более важную роль в качестве критерия принятия решения при выборе инструмента. Каждая деталь пользовательского интерфейса требует особого внимания. Многие интерфейсы сегодняшних ВГД ПО останутся на уровне первых появившихся ВГД интерфейсов, даже если заменить их визуально привлекательными поверхностями. Проблема не столько во внешнем виде, сколько начинке этого ПО и его поведении. Начиная с 1990 года, Якоб Нильсен разработал то, что стало довольно популярным перечнем общих принципов проектирования пользовательских интерфейсов — “10 эвристик юзабилити” (Нильсен и др., 1993). Далее мы попытались кратко прокомментировать применение этих правил в контексте к ПО моделирования будущего, как с практической так и с теоретической сторон:
Отображение состояния системы: система всегда должна должна информировать пользователей о том, что происходит в данный момент через соответствующие органы обратной связи в разумные сроки.
- Концепция: моделирование в режиме реального времени является конечной целью, поэтому это очень важный аспект “Священного Грааля” ВГД.
- Практика: особенно во время длительных действий, таких как работа решателя, проверка геометрии, перенос данных, отображение информации о текущем состоянии является необходимым. Этот аспект становится особенно важным, когда действия выполняются удаленно. Существующая тенденция облачных вычислений будет требовать все большую необходимость соблюдения этого правила.
Соответствие между системой и реальным миром: Система должна разговаривать на языке пользователя, словами, фразами и терминами, понятными пользователю, а не терминами, определенными самой системой. Согласно этому правилу информация должна появляться в естественном и логичном порядке.
- Концепция: Это правило применимо непосредственно к сложным рабочим процессам, таким как учет объединения нескольких физических в единой модели. Как уже было отмечено, ПО должно соответствовать рабочему процессу, рабочему контексту и возможностям пользователя, а не наоборот.
- Практика: Многие пользовательские интерфейсы ВГД до сих пор используют терминологию, знакомую только ВГД экспертам. Акцент должен быть на термины из конкретной инженерной области, и это относится не только лишь к интерфейсу пользователя, но также и ко всей документации, справочной документации и обучающим материалам.
Рисунок 11. Обложка “Usability Engineering” Якоба Нильсена (Нильсен, 1993)
Ограничения и свобода пользователя: Люди часто ошибаются при выборе системных функций и нуждаются в “аварийном выходе”, чтобы покинуть нежелательное состояние без необходимости проходить через длинный диалог. Должна быть поддержка отмены/повтора операции.
- Концепция: Появление облачных вычислений привносят некоторые сложности — аварийный выход может получиться недостаточно быстрым, затратным по ресурсам или недостаточно надежным из-за пользовательских ограничений. Разработчикам нужно будет постоянно обращать на это внимание.
- Практика: Операции отменить/повторить были незаменимыми в офисных приложениях на протяжении десятилетий, но большинство современого ВГД ПО по-прежнему не соответствуют таким основным требованиям юзабилити.
Последовательность и стандарты: У пользователей не должно возникать ситуаций, когда различные слова, ситуации или действия означают одно и то же. Следуйте правилам платформы.
- Концепция: Многие экземпляры ВГД ПО имеют длинную историю, охватывающую несколько поколений руководителей и разработчиков. Некоторые программные модули могли быть приобретены у сторонних производителей или получены по лицензии, что еще больше усложняет задачу. Тем не менее это правило должно быть одним из приоритетных при разработке пользовательского интерфейса и должно соблюдаться всеми частями программного продукта.
- Практика: Правила платформ часто игнорируются ради снижения затрат на разработку мультиплатформенных программных пакетов. Это относится не только к внешнему виду интерфейса, но к таким стандартным операциям как сохранение/загрузка файла, печать, поиск и т.п. и конечно же отменить/повторить.
Предупреждение об ошибке: Улучшение сообщений об ошибках является важной работой, которая предотвращает повторное появление какой-либо проблемы, уже случившейся один раз. Необходимо либо исключить условия возникновения ошибки, либо ввести дополнительные подтвержденя от пользователя при попытке совершить какое-либо действие.
- Концепция: Это требование представляет достаточно сложную задачу для ВГД ПО, из-за лежащих в основе сложных физических моделей, численных методов и т.д. На самом деле для решения такой проблемы необходимо некое подобие искусственного интеллекта. В будущем этот аспект станет основной особенностью опыта взаимодействия (UX), потому как является критическим фактором для обеспечения того, чтобы пользователи, не обладающие знаниями экспертов, могли успешно использовать ВГД ПО и получать надежные, высококачественные результаты.
- Практика: Сначала кажется очевидным решение — построить граф предупреждений для каждой возможной ситуации, но это не будет решением проблемы. Прежде всего необходимо сосредоточиться на наиболее важных ситуациях и предоставить функцию отмены/повтора.
Распознавание вместо дополнительных вопросов: Минимизировать загрузку памяти пользователя отображая используемые объекты, действия и опции. Пользователь не должен запоминать информацию из одной части диалога, находясь в другой. Инструкции по использованию системы должны отображаться или быть легко доступны при необходимости.
- Концепция: Ключ к концептуальному проектированию хорошего пользовательского интерфейса лежит в понимании пользователя, его рабочей обстановки и его рабочих процессов, разработка использования ПО на основе этих исследований должна происходить с акцентом на естественные ощущения пользователя.
- Практика: Современные интерактивные концепции пользовательского интерфейса уже основаны на этом принципе. Но многие детали все еще можно улучшить — например, списки недавних файлов, информация о состоянии, мастер-помощник и т.д.
Гибкость и эффективность использования: Ускорители — незаметные для начинающего пользователя — часто могут ускорить работу опытного пользователя, таким образом система удовлетворяет требованиям как неопытных, так и опытных пользователей. Предоставить пользователям возможность адаптировать часто совершаемые действия.
- Концепция: Опять же, это приводит к требованию, что ПО должно соответствовать рабочему процессу, рабочей обстановке и индивидуальным возможностям пользователя, а не наоборот. ПО должно помогать пользователю наращивать опыт и адаптироваться к этому росту.
- Практика: В Windows уже есть концепция горячих клавиш, с которой многие пользователи хорошо знакомы, так что лучше использовать эту концепцию. Сенсорные интерфейсы имеют концепцию жестов, которая также должна быть использована, даже если при этом доступна только мышь. Возможность создания своих скриптов поможет опытным пользователям настроить свои собственные функции автоматизации при сравнительно низких затратах.
Эстетичный и минималистичный дизайн: Диалоги не должны содержать ненужную или редко используемую информацию. Каждый новый информационный блок в диалоге конкурирует с уже существующими и уменьшает их относительную видимость.
- Концепция: Качество юзабилити измеряется не количеством кнопок пользовательского интерфейса. ПО с хорошим дизайном распознает дальнейшие шаги пользователя и предлагает ему именно те функции, которые могут иметь отношение к следующему шагу.
- Практика: Для многофункциональных продуктов, таких как ВГД ПО, чаще всего меньше — лучше. Достаточно отобразить имеющиеся функции, а серым закрасить недоступные. Автоматически будет предоставлен доступ к контекстно-зависимым функциям, относящихся к активному объекту.
Помогать пользователям обнаруживать, распознавать и исправлять ошибки: Сообщения об ошибках должны быть выражены простым языком (без кодов), точно описывать проблему, конструктивно предлагать решение.
- Концепция: В частности, “конструктивно предлагать решение”, кажется одним из основных направлений для совершенствования. Обработка ошибок имеет такой же приоритет как и предотвращение ошибок, что является критерием для обеспечения опыта взаимодействия (UX), а следовательно влияет на решение клиента о покупке ПО.
- Практика: Особенно важным требованием является наличие обработчиков пользовательских ошибок и программных сбоев с отдельными, не универсальными, сообщениями об ошибках — требуется совсем не так много усилий, чтобы хотя бы обеспечить правильное описание того, что же пошло не так.
Справка и документация: Несмотря на то, что лучше всего, если системой можно будет пользоваться совсем без документации, может возникнуть необходимость в наличии справки и документации. Любую подобного рода информацию должно быть легко найти, с акцентом на задачи пользователя, материалы должны содержать списки шагов для получения того или иного результата, но не слишком длинные.
- Концепция: Справка не ограничивается лишь текстовыми или графическими пояснениями; она должна использовать все имеющиеся средства передачи информации, включая короткие видеоролики, интернет-ресурсы, ссылки на интернет-сообщества пользователей и технической поддержки и т.д.
- Практика: Лучше один раз увидеть, чем сто раз услышать: этот принцип относится в частности к инженерам, как основным пользователям ВГД.
3. Заключение
Коммерческому ВГД ПО для промышленных приложений уже более 30 лет. Три десятилетия успешного ВГД моделирования сотнями тысяч ученых, инженеров и студентов сделали эту технологию незаменимым инструментом, который сегодня встраивается в процесс проектирования во многих отраслях. В то время как классическая технология ВГД в значительной степени уже созрела, быстро развиваются новые захватывающие концепции и технологии для решение ВГД задач будущего. По прошествии двух основных волн развития коммерческой ВГД, каждая из которых имела свои изменения в парадигме, мы в настоящее время переживаем третью волну, в которой парадигма смещается в сторону внедрения ВГД ПО в процесс проектирования. Затем, конечно же, появится четвертая волна ВГД ПО. Авторы полагают, что это будет новый шаг на пути к “Святому Граалю” ВГД: в режиме реального времени, “только нажмите на кнопку”, автоматизированное, простое в использовании, двунаправленное, поддерживающее мультифизичность… а классическая ВГД второй волны останется далеко позади.
Комментарии (16)
evocatus
05.01.2016 16:40+9А я думал будет что-то интересное…
Статье место даже не на GT, а на мегамозге — куча воды на менеджерском птичьем языке.
Kazancev
05.01.2016 17:43«это будет новый шаг на пути к “Святому Граалю” ВГД: в режиме реального времени, “только нажмите на кнопку”, автоматизированное, простое в использовании, двунаправленное, поддерживающее мультифизичность… а классическая ВГД второй волны останется далеко позади.»
Выше цитата характеризует не инженера, а оператора. Вспомните, советский анекдот про «оператора машинного доения» — то есть из инженера делают такую секретаршу — тут нажать, сюда ткнуть, записать, шефу отзвониться, и всё по инструкции на листике А5 (второй анекдот — «опять летим по пачке от Беломорканала»). Абалдеть, и никакого матана! Мечта же =)
Как студенту с кафедры динамики и прочности машин мне ближе проблемы прочности и т.д., а в жидкости и газы изо всех сил стараюсь не лезть по причине некой «магии» происходящего. CPU — он ведь тупой как дырокол — ему всё равно, что считать, а меня всегда учили, что оценивать результат уникального расчёта всё таки следует сверяясь с экспериментом и формулой. Механика ведь началась с точных красивых аналитических задач. Нет формулы — значит некая «магия» =) А если магия — значит инженер становится «кудесником, художником». И чисто инженерная задачка превращается в искусство. А мне формулы родней 8)
А можно узнать, это оригинал статьи или перевод? Возникли желания поближе познакомиться с возможностями фирм второго эшелона, чем они заняты и как выживают.Kazancev
05.01.2016 20:16Сорри, увидел. А можно ссылку на оригинал?
javdeev
05.01.2016 21:42В конце статьи есть незаметная ссылка, но продублирую ещё здесь:
Перевод: Ivo Weinhold, John Parry
И да там придется засветить свою почту, но я брал оригинал от туда.Kazancev
06.01.2016 19:33Да, спасибо. Один раз почти скачало. Следующие попытки неудачные =(
Взял отсюда www.mentor.com/products/mechanical/engineering-edge/volume4/issue1/three-waves-commercial-of-cfd
В конце как раз были ссылки на источники.
idiv
05.01.2016 20:45тут нажать, сюда ткнуть, записать, шефу отзвониться, и всё по инструкции на листике А5
Так в принципе это нормальный процесс. Никто, например, вручную не считает электрическую сеть в 3000 узлов. Именно, что пара кнопочек «выключить линию, изменить нагрузку, рассчитать».
Или, например, не нужно задумываться, как взаимодействуют три фазы в симуляторе реального времени для динамических процессов. Взял стандартные ЛЭП, вбил длину и нагрузку, нажал кнопочку и все.
Главное, как правило, идет до и после. Вначале про после — анализ полученных данных, учитывая их объем, та еще задача. И ошибки еще поискать нужно. А ведь результатов может быть море, что позволяет проверить главное «до» — идею. Она может быть очень сложная и для ее проверки отвлекаться на рисование отдельных стандартных деталей и их сборку — пустая трата времени сейчас.Kazancev
06.01.2016 19:42Нуу, я считаю, что электросеть неудачный пример. Если говорить о FEM, то в том и дело, CFD =! твёрдотел, с которым мне сухо и комфортно.
Я бы вообще не стал останавливаться на третьей волне, оно для обычных операторов. На самом деле уже идёт четвёртая волна, если говорить в выбранной исторической последовательности: другие более совершенные и более сложные маткоды, другие малоизвестные фирмы, другие задачи из атомной отрасли и совсем другие деньги. Может кому-нибудь что-нибудь скажет фраза «расчеты двухфазной неравновесной теплогидродинамики». Доступ к изучению такого софта имеют сотни спецов, вряд ли больше.idiv
06.01.2016 20:29Нуу, я считаю, что электросеть неудачный пример.
Есть еще программы, которые раньше (студенты на таком сейчас учатся, но только в 2Д, иначе за семестр не успеть) были кучей самописного кода, где в один клик можно проверить конфигурацию распределения электрических полей в сердечнике. Теперь проверка и подготовка данных занимает раз так в 50-60 меньше времени. Такой пример лучше?Kazancev
06.01.2016 20:35Вы всё равно считаете, что CFD не сложнее магнитостатики. Это не так, CFD называют «спортивной дисциплиной» — очень многое зависит от качества сетки, качества алгоритмов, вычислительных ресурсов. Я не лезу в CFD, потому что там — безбрежный океан без твёрдой почвы, на которую не опереться.
idiv
07.01.2016 21:24Я такого не говорил, тем более про статику (вы наверное не в курсе, что в энергетике нет статики, есть только постоянные переходные состояния?).
Я о том, что программа берет на себя самое простое и дальше идет уже выбор научно важной работы, вроде разрешения модели (ваше «качество сетки»), качества алгоритмов (можно самому придумывать алгоритм обращения матрицы, а можно взять у Интела, оптимизированный для работы на Интеловских процессорах. Судя по словам моего профессора быстрее них ничего не работает). Вычислительные ресурсы в данной постановке задачи у нас одинаковы (речь ведь идет о самописном коде и программе с одной конпкой).
Вам просто интересен процесс, а инженеру нужен результат. То, что программы проще, не значит, что они не позволяют глубоких модификаций. Они позволяют, но зато внесение изменений не требует больших усилий и, по сути, то самое однокнопочество.
BalinTomsk
05.01.2016 23:52Я участвовал в разработке софта для моделирования многокомпонентных жидкостей MODFLOW ~40 мег кода и около 600! диалоговых окон(это без считалок) написан на Borland C++
и в другой компании для расчета воздушных загрязнений AirMod написан на Delphi.
И даже сейчас предложи мне написать это снова — не выберу ни C# WPF ни JavaScript, хотя уже лет 10 не пишу на борландовских продуктах (просто несоизмеримый обьем работы) получится, xотя на обеих технологиях (C#/Java) уже давно пишу (обязывают).
Считалки исключительно на Fortrane (регулируется законодательством).
Самое интересное что методики расчетов остановились (из того что обязаны использовать) и соответствуют алгоритмам написанным в СССР еше в 70-х.
Nashev
06.01.2016 00:55Очень интересный исторический обзор в начале, жаль что закончился фантазиями на тему…
PapaBubaDiop
На рисунке 1 моделирование потока воздуха, а не жидкости.
javdeev
Спасибо, поправил.
omican
<зануда mode>Если в оригинале было слово «fluid», в данном контексте можно его переводить и как «жидкость». В механике сплошных сред (гидродинамика — ее раздел) понятие жидкость включает и газы, и капельные жидкости.</зануда mode>
PapaBubaDiop
Зануда занудой, но здесь не лингвистический форум, на рисунке моделируется обдув автомобиля, вода зачем? Кстати, этот численный расчет был очень популярен в 80-е, обычно считали Гольф.