Последние лет десять я так или иначе участвую в процессе продажи программного обеспечения для инженерных расчётов. Общаюсь с менеджерами по продажам и непосредственно с клиентами, и у меня накопился список вопросов, которые задают чаще всего и на которые зачастую не так легко ответить. А ещё, поскольку направление инженерных расчётов в АСКОН довольно молодое, в этот список я включил вопросы, касающиеся особенностей программного обеспечения, которое мы считаем в АСКОН частью комплексного PLM-решения консорциума «Развитие». Итак, поехали!
Какие продукты мы считаем в АСКОН частью комплексного решения консорциума «Развитие»?
Прежде всего, речь идёт о продуктах для трёхмерного численного моделирования гидрогазодинамики и механики деформируемого твёрдого тела. Это продукты наших партнёров по консорциуму «Развитие».
Компания НТЦ АПМ (Научно-технический центр «Автоматизированное проектирование машин») выпускает продукты под брендом APM (это латиница), включая приложение, встроенное в КОМПАС-3D, который называется APM FEM (А-пэ-эм фем). Продукты НТЦ АПМ предназначены для решения задач механики деформируемого твёрдого тела (в просторечии – прочностных расчётов).
Компания ТЕСИС выпускает продукты для вычислительной гидродинамики (на деле, их софт способен на гораздо большие подвиги, чем просто гидрогазодинамика). Флагманский продукт называется FlowVision (ФлоуВижн или, как шутят сами коллеги, Струегляд), а встроенный в КОМПАС-3D – KompasFlow (КомпасФлоу).
Кроме этого, из расчётного софта мы ещё работаем с компанией Сигма-Технологии, которая делает продукты IOSO и IOSO-K (для КОМПАС-3D). Они решают задачи параметрической оптимизации и, фактически, являются надстройкой над другими продуктами, которая управляет расчётами, меняя их параметры.
А ещё в нашем портфолио продукт численного моделирования объектов в виде системных моделей Pradis (Прадис) от компании «Ладуга». Такой софт позволяет соединять простые численные или аналитические модели в связанные системы и использовать их для получения оптимальных характеристик на этапе концептуального проектирования или на этапе эксплуатации для быстрого расчёта поведения в цифровых двойниках изделий.
В чём разница между «младшими» и «старшими» продуктами?
«Младшие» продукты – это приложения для КОМПАС-3D: APM FEM, KompasFlow, IOSO K. «Cтаршие» – отдельные приложения со своим графическим интерфейсом.
В «младших» продуктах, как правило, ограничены расчётные возможности, скажем, в KopmpasFlow нельзя посчитать задачу c многофазным течением или более чем одной расчётной областью, а в APM FEM не получится использовать балочные элементы или считать задачи с сейсмической нагрузкой. Зато они в привычном конструктору интерфейсе КОМПАС-3D и используют геометрическую модель, сделанную прямо в этом же окне. Именно инженеры-конструкторы являются целевыми пользователями этих продуктов. Поскольку они имеют более понятный интерфейс и ограниченные возможности, они несколько проще в освоении. «Младшие» продукты позиционируются как системы для «экспресс-расчётов», но что под этим подразумевается, не все понимают и могут объяснить (см. следующий вопрос). «Младшие» продукты используют тот же решатель (расчётное ядро), что и «старшие», но запускают его незаметно для пользователя.
«Старшие» продукты предназначены профессионалам САЕ – инженерам-расчётчикам. Они могут общаться с CAD-системой через передачу файлов геометрической модели (например, в нейтральных форматах, формате геометрического ядра C3D или даже напрямую в формате КОМПАС), могут совсем от неё не зависеть, как Pradis, а могут даже и сами управлять запуском КОМПАС, как IOSO. В «старших» продуктах доступны все расчётные возможности, хотя это зависит от купленной лицензии.
«Младшие» продукты проще, но дешевле и имеют небольшое количество вариантов лицензирования. «Старшие» продукты дороже, но предоставляют больше возможностей.
«Младшим» продуктам можно обучаться самостоятельно или в рамках небольших курсов, для освоения «старших» продуктов важно пройти специальное обучение.
Что такое «экспресс-расчёты», для которых предназначены продукты APM FEM и KompasFlow?
Когда говорят о расчётных приложениях для КОМПАС, формулируют их предназначение – для «экспресс-расчётов». Как говорил товарищ Цой: «Все говорят, что мы вместе. Все говорят, но немногие знают в каком». Мне от пользователей приходилось слышать: «Нам обещали экспресс-расчёты, а мы попробовали решить простую задачу с рамой из металлического профиля, а она считалась 12 часов, да так и не посчиталась». Давайте проясним ситуацию. Экспресс в нашем случае означает только то, что при постановке задачи не придётся передавать геометрическую модель из КОМПАС в другую программу, не придётся рисовать модель с нуля (в некоторых пакетах можно только так), вся постановка задачи делается внутри CAD и с минимумом настроек, а при изменении конструкции по результатам расчёта на перепостановку задачи требуется меньше времени. Однако сама по себе методика моделирования в «младших» и «старших» продуктах ничем не отличается. Более того, при помощи «старших» продуктов можно зачастую соорудить даже более быструю по скорости счёта модель (см. ответ на следующий вопрос). Например, в APM FEM нет балочных элементов (пока что), при помощи которых как раз можно достаточно точно, но с минимальными временными затратами рассчитать модели металлоконструкций, а в «старшем» APM – есть.
Как быстро считают ваши программы?
О, это нестареющая классика! Такой вопрос обычно задают либо совсем новички в деле моделирования, либо аксакалы. Во втором случае, правда, используются более умные слова типа «бенчмаркинг» и «высокопроизводительные вычисления», и «предел распараллеливания».
Самое главное, что нужно понимать про любую систему для численного моделирования, это то, что она – не более чем просто очень сложный калькулятор. И скорость расчёта на этом калькуляторе зависит от того, насколько сложную задачу ему поставил инженер, насколько быстрый компьютер решает задачу и насколько эффективны те алгоритмы, которые заложены разработчиками.
Сложность задачи вполне измерима, она зависит от количества узлов или ячеек расчётной сетки и может быть отрегулирована инженером. Мощность вычислительной машины также можно выбирать (на этапе покупки). Из реальных достижений компьютерной науки остаётся оценивать только алгоритмы. И вот тут как раз начинается вышеупомянутый «бенчмаркинг»: давайте посчитаем, сколько времени займёт решение вполне определённой, откалиброванной, тестовой задачи на вполне определённом железе. И то, тут не получится выдать абсолютное значение, а лишь сравнение. Либо мы сравниваем два разных ПО между собой (что, кстати, может быть и не всегда возможно в силу, например, разных методов построения расчётной сетки). Либо сравниваем две версии одного ПО. Ведь новые версии должны быть быстрее старых, правда? Или есть ещё вариант, что мы сравниваем работу алгоритмов при увеличении мощности расчётной машины: если мы удвоим количество ядер, считающих задачу, удвоится ли скорость расчёта? Что, кстати, приводит нас к следующему вопросу.
Кроме того, обычно любой расчёт делится на три основных этапа: препроцессинг (подготовка численной модели, постановка задачи), собственно решение задачи и постпроцессинг (обработка результатов). И как показывает моя практика расчётчика, до 75% времени тратится именно на подготовку задачи. А будет моя задача решаться ровно час или час, десять минут и 23,05 секунды не так уже и существенно. Эффективного способа сравнить удобство препостроцессинга, на мой взгляд, не существует. Уж больно это субъективная категория.
Какие системные требования для запуска программы?
Тоже классический вопрос, его часто задаёт ИТ-служба предприятия. Бывает ещё формулировка: «Какие минимальные системные требования». Здесь мне тоже хотелось бы прояснить ситуацию. Несмотря на то, что тераватты мощности современных компьютеров тратятся на то, чтобы можно было быстро и легко смотреть видео с котиками, изначально вычислительные машины создавались именно для инженерных расчётов и численного моделирования. Поэтому я не вижу ни одной причины хотеть себе для расчётов мало вычислительной мощности. Человек, который спрашивает про минимальные системные требования, подобен клиенту автосалона, который интересуется с какой минимальной скоростью едет машина, которую он выбрал. Одним словом, чем мощнее будет машина, на которой будет запущен расчёт, тем лучше.
Из объективных категорий следует выделить следующие обстоятельства.
Почти все расчётные программы в настоящее время считают на центральных процессорах (не на графических, хотя такие разработки ведутся), поэтому чем больше ядер будет у процессора и чем они быстрее, тем лучше.
В задачах механики, в отличие от задач гидродинамики, объём оперативной памяти имеет большее значение. У разработчиков есть такая негласная рекомендация закладывать в спецификацию по минимум 4 Гб ОЗУ на одно ядро.
Графическая карта должна быть хотя бы дискретной. Она используется только для вывода изображения, поэтому её мощность и объёмы видеопамяти вторичны.
Лучше комплектовать расчётную машину твердотельным накопителем (SSD). Расчётное ПО генерирует огромные объёмы «сырых» результатов, измеряемые гигабайтами. Вам захочется, чтобы эти объёмы быстро писались и читались с диска.
В любом случае, стоит помнить, что чаще всего лицензии на САЕ-продукты это довольно дорогие лицензии, после покупки которых «железо» может быть куплено на сдачу. При этом для решения большинства задач на большинстве предприятий не надо покупать специальное дорогое выделенное серверное «железо» или даже пытаться строить вычислительный кластер, вполне достаточное просто хорошего настольного компьютера.
А прежде чем потратить кучу денег на покупку лицензий расчётного ПО, многие задают вопрос.
С какой точностью считают ваши программы?
И этот вопрос сразу выдаёт человека, которому ещё только предстоит научиться что-то считать. Правильный ответ на такой вопрос – с произвольной точностью. Как и с ответом на вопрос про скорость вычисления, надо вспомнить, что софт для расчётов это всего лишь очень сложный калькулятор и он считает только ту задачу, которую ему поставил инженер.
Даже опуская вопрос, что мы принимаем за точное решение, потому что тут много подводных камней, связанных с методикой постановки эксперимента и измерением, если за «точное» решение мы берём результат каких-то испытаний, и с применимостью аналитических методов, если за точное решение мы принимаем какую-нибудь «формулу из ГОСТа» или «формулу из учебника», генераторами ошибки в результатах бывают (в порядке увеличения размера ошибки):
ограниченная машинная точность
ограниченная точность алгоритмов софта
неоптимальный выбор настроек расчёта
ошибки дискретизации («плохая» сетка или её недостаточная подробность)
неточность задания граничных условий и свойств материалов
неправильный выбор применяемых моделей (непонимание физики процессов или ограничений численных моделей).
Из всех перечисленных факторов только точность алгоритмов зависит от разработчиков, самые важные лежат в зоне ответственности пользователя продукта. Именно поэтому важно обучать пользователей.
Мы ищем замену Ansys (Siemens, NASTRAN)? А ваши программы могут как Ansys (Siemens, NASTRAN)?
Или есть ещё вариант этого же вопроса: «А ваши продукты уже достигли уровня Ansys, вы догнали Ansys». Такой вопрос обычно задают либо люди, занимающие высокое положение в компании, либо непосредственные пользователи замещаемого софта, особенно когда им нужен аргумент, чтобы не осваивать новый продукт.
Ключевой момент в ответе на этот вопрос – это понять, а какие задачи пользователь решал с помощью замещаемого софта. Ни одна компания не использует всех возможностей мощного софта полностью, кроме, может быть, специальных компаний, которые специализируются на выполнении расчётов. При этом специализированные продукты могут быть в решении конкретных задач даже лучше, чем универсальные комбайны всё в одном. Хороший пример – это задачи обработки металла давлением и задачи литья, здесь специализированное ПО выигрывает конкуренцию у крупных разработчиков, хотя универсальное ПО и может считать такой класс задач.
Одним словом, надо выяснят, какие именно задачи решаются на предприятии и может ли предлагаемый софт решить эту задачу. Для этого, конечно, необходим диалог между специалистами-расчётчиками, а не сравнение на уровне брендов.
Ну, и на закуску главный вопрос жизни, вселенной и вообще.
Зачем вообще нужно это ваше численное моделирование?
Обычно отказ от численного моделирования и пользования расчётным софтом мотивируют либо тем, что зачем считать если всё равно все выяснится на испытаниях, либо тем, что всё это не нужно, потому что есть ГОСТы, СНИПы, аналитические методы из учебника и так далее.
Если говорить про второй вариант аргументации, то контраргументом тут могут служить такие доводы.
Ни одна нормативная методика расчёта не обладает достаточной точностью, чтобы по её результатам можно было тонко оптимизировать конструкцию: уменьшить стоимость, повысить технологичность. Кроме того, использование численного моделирования позволяет расширить критерии, по которым мы проверяем наше изделие (скажем, если мы хотим посчитать не только статическую прочность, но и устойчивость, поведение при резонансе, сейсмическую прочность, то собирать все нужные формулы мы будем долго)
Современные нормативные документы зачастую включают в себя применение численного моделирования.
Если отвечать на вопрос о замене моделирования испытаниями, то критерий применимости тут вполне экономический: для каждого испытания нужно не только разработать, но и изготовить тестовый образец, какую-то оснастку. И уже пара-тройка проваленных испытаний, после которых приходилось перепроектировать и переизготавливать испытательный образец, часто вполне могут покрыть расходы на приобретение софта, железа, обучение сотрудников и их содержание. Кроме того, есть варианты, когда испытания просто невозможны. Мой любимый пример – проектирование АЭС. По современным нормам здание реактора должно выдерживать землетрясение, цунами и падение самолёта. Как можно догадаться, испытания ни на одну из этих нагрузок ни на одной из АЭС мира не проводилось.
Так что итоговый ответ один: численное моделирование, да и компьютерные инженерные расчёты вообще, позволяют для предприятия снизить затраты на проектирование нового изделия и сократить цикл проектирования.
