ANSYS vs MSC

[Sapr2kCAE 0]

Уважаемые, форумчане.

Рассматривается вопрос организации процессов CAE (проведение расчетов, хранение данных и пр.) в едином информационном пространстве.

В процессе отбора решений выявляются два "лидера":

MSC.SimManager

ANSYS EKM

"Лидеры" в кавычках, поскольку наиболее активно развиваются и используются на предприятии решения именно этих фирм.

Есть, конечно, предложения, типа LMS.TecManager, но их используемое ПО занимает крайне малую долю в расчетах.

Принимая во внимание необходимость интеграции (в дальнейшем) системы CAE с PDM решениями, возникает вопрос:

что предпочесть (с обоснованием)?

P.S. Хотел опросник сделать. Не нашел :(

Изменено 31 июля 2008 пользователем Sapr2kCAE

[a_schelyaev 366]

А какая у вас PDM?

[Sapr2kCAE 0]

PDM - TeamCenter, хотя, не думаю, что это - критично, т.к. под любую PDM-систему необходима "доработка напильником" (поэтому в 1-ом посте и не указал)

[a_schelyaev 366]

Просто если брать Abaqus, то к нему можно взять в довесок SLM.

А SLM есть надстройка над Enovia.

Поэтому гламурненько может выйти по стоимости владения БД и ее содержания.

Ну это так...

[Sapr2kCAE 0]

Кто-нибудь по организации CAE-процессов, что-нибудь авторитетное может озвучить?

Кто, как CAE-данные организовывает?

Кто-то о "прозрачности" CAE-расчетов задумывается, вообще???

[Sten 2]

PDM - TeamCenter, хотя, не думаю, что это - критично, т.к. под любую PDM-систему необходима "доработка напильником" (поэтому в 1-ом посте и не указал)

Если PDM ТЦ, то почему не использовать для ваших задач модуль ТЦ для управления CAE данными?? Ассоциативная связь с конструкторскими данными при граммотном использовании очень жизнь облегчает, да и интеграция ТЦ с MSC/Ansys-шными продуктами поддерживается.

[Sten 2]

Кто-нибудь по организации CAE-процессов, что-нибудь авторитетное может озвучить?

Кто, как CAE-данные организовывает?

Кто-то о "прозрачности" CAE-расчетов задумывается, вообще???

Вопрос организации данных встает или когда надоедает бардак,или когда надо вписать CAE в сквозной цикл разработки изделия,чтобы CAE данные были логически и ассоциативно связанны с конструкторскими данными. Вас какой случай интерисует?

[Sapr2kCAE 0]

Меня интересует второй случай.

Правда, у меня огромные вопросы про "логику и ассоциацию" с конструкторскими данными.

В авиастроении инженерные данные первичны, поэтому, что с чем ассоциировать - вопрос (что -- "курица", а что -- "яйцо" :) ).

А про поддержку ТЦ MSC/Ansys-шных продуктов -- кто-нибудь "пользовал"?

(В ТЦ даже простые вещи, порой, работают "непонятно как", вернее, как-то перректально).

Да и про "грамотное использование" ассоциативных связей хочется, что-нибудь вразумительное услышать...

[Sten 2]

Меня интересует второй случай.

Правда, у меня огромные вопросы про "логику и ассоциацию" с конструкторскими данными.

В авиастроении инженерные данные первичны, поэтому, что с чем ассоциировать - вопрос (что -- "курица", а что -- "яйцо" :) ).

А про поддержку ТЦ MSC/Ansys-шных продуктов -- кто-нибудь "пользовал"?

(В ТЦ даже простые вещи, порой, работают "непонятно как", вернее, как-то перректально).

Да и про "грамотное использование" ассоциативных связей хочется, что-нибудь вразумительное услышать...

В авиации ТЦ для CAE давно используется во французской части Аирбаса. Но там в основном он используется для организации расчётных данных и процессов, без связей с конструкторскими данными, точнее связь "асинхронная":), так как конструктора работают в другой PDM'ке. Больше всего ТЦ с CAE работает в автопроме и с MSC и c Ansys и с Альтаировскими продуктами. Есть примеры в авиационном двигателестроении. В России - сомневаюсь, я вообще не особо много слышал о том,чтобы в России кто-то заморачивался такими вещами:)

Как работают CAEшнык PDMки у MSC,Ansys и прочих - не скажу,так как опыта не было. С ТЦ всё просто..В принципе как показывает практика вопрос организации CAE данных и их связь с конструкторскимим данными, больше методологический вопрос,чем инструментальный. У конструкторов больше вклад именно функционала PDM системы, а у CAE - методики. Для начала всё-таки неплохо определить кто курица,а кто яйцо:) Далее надо понять в каком виде приходят данные от конструкторов сейчас, и в каком виде они должны быть,чтобы спецы CAE больше занимались своими вопросами,чем выгребали недоделки и ляпы конструкторов - вопрос очень болезненный и критичный, так как если не навести порядок в конструкторской части, которая поставляет входящие данные для CAE, то говорить об ассоциативности будет затруднительно. Подводных камней очень много В первую очередь народ старается снизить трудозатраты на "интерфейсные" работы между конструкторами и расчётчиками, то есть стараются сделать так,чтобы геометрия на выходе от конструкторов, как можно больше соответствовала тому,что надо расчётчикам. Всем конечно не угодить, но компромисс найти возможно. Для этого в первую очередь утрясают требования к моделям (есть ещё требования к структуре изделия, но тут как показывает практика не получается перетянуть хоть немного одеяла на сторону расчётчиков:)), дальше по этим требованиям заставляют конструкторов доводить модели, все по разному, там где организация на высоте,хватает включения требований в штатный чек-лист, в других местах вписывают проверку требований в автоматический чекер (в зависимости от КАД системы чекеры разные), а кое-где и то и другое(по-моиму самое оптимальное). Дальше идут процессы, во-первых важен сам процесс организации передачи детали/сборки на расчёт,и последующие этапы, тут ПДМ система как раз сильно помогает, почти в любой ПДМ сейчас можно легко настроить workflow, который будет не только воспроизводить какой-либо конструкторский процесс, но и передавать данные в CAEшный процесс, и возвращать их обратно. Опять же всё сильно зависит от методологии проектирования, но такие базовые вещи, как замораживание состава сборки и входящей в неё геометрии на время расчёта - являются базовыми, и это решается ПДМ. С одной стороны это даёт возможность расчётчику работать со статичными данными, что сильно облегачает ему жизнь, иначе приходится сталкиваться с ситуацией, когда переодически прибегают конструктора и что-то меняют, а то и вовсе оказывается, что расчёт закончен,а модель уже изменилась. Но с другой стороны чтобы обеспечить гибкость надо разрабатывать альтернативные сценарии на случай если всё же возникла необходимость изменить входящие данные, над которыми уже работают расчётчики. В любом случае ПДМ система позволяет упорядочить этот процесс, что сильно отражается на времени проектирования. Далее...передача структур сборок, как правило структура какой-то сборки которой пользуется конструктор далеко не всегда подходит для расчётчика, и он (в зависимости от типа расчёта) вынужден что-то выкидывать из сборки (например крепеж), что-то добавлять, процесс трудоемкий и занудный,а самое главное переодический. Тут спасают фильтры,умные,настроенные фильтры,которые по какому-либо признаку или убирают какие-то входящие компоненты,или добавляют,или заменяют. На практике обычно "зубры"-опытные спецы создают некий набор фильтров, что-то вроде библиотеки, которые потом используются всеми. Как правило в любой компании сборки(детали) однотипные, точнее от изделия к изделию не сильно меняются идеологически, поэтому такая библиотека фильтров достаточно статична..Для каждого типа сборок создаётся свой набор фильтров для разных типов расчёта (статика, динамика,тепло..итд). В итоге получается,что для преобразования конструкторского состава в расчётный достаточно выбрать нужный фильтр в зависимости от типов сборки и расчёта,а дальше уже работает ПДМка. Фильтры динамические, поэтому при изменениях в конструкторском составе можно автоматом получать обновленную структуру для расчётов - но опять же процесс изменений не должен быть спонтанным, а по заранее определённому и желательно "зашитому" в ПДМ процессу.С одиночными моделями чуть проще, как правило ассоциативная цепочка состоит из исходной модели,которая а) заморожена для изменений и б) доступна только для чтения, далее идеализированная модель с прямой односторонней ассоциативной связью на исходную модель - в идеализированной модели расчётчик "доводит" до ума модель (отверстия убрать если надо,упростить что-то,итд..), далее на основе идеализированной модели получают fem модель с сеткой (или несколько), и последняя часть это сама расчётная модель,которая состоит из какой-либо fem модели+расчётный случай. В идеале цепочка ассоциативна сверху вниз, в реальности зависит от инструментария, кое-где связь рвётся и тогда надо изобретать что-то,чтобы связь была хотя бы на уровне автоматической трансляции из одно в другое. Само собой когда на одну идеализированную модель приходится несколько вариантов сеток,а на каждую сетку несколько расчётных случаетв, то без ПДМки хранить всё это тяжко. Не говоря уже о результатах. Ну и так далее :)

[Sapr2kCAE 0]

Спасибо, за такой развернутый ответ!

Меня, как раз, очень смущает "прямолинейность" ассоциативной цепочки :)

Не всегда получается однозначно сопоставит геометрию (от единичного узла до сборки) и расчетную CAE-модель, а это значит -- "разрыв цепочки" на самой первой стадии.

В Сименсе рассуждают просто: вот -- дерево CAD, по нему строим дерево CAE.

Но у CAE -- нет дерева, в презентациях MSC это декларируется с первых слов!

CAE-данные -- это не древовидная структура.

Согласен, что здесь больше методологии, чем взаимодействия инструментов, но про взаимодействие инструментов тоже очень хочется узнать поподробнее.

(В одной из презентаций MatLab-а декларировалась возможность проведения аэродинамических расчетов по результатам "работы" Simulink-модели!)

[Sten 2]

Спасибо, за такой развернутый ответ!

Меня, как раз, очень смущает "прямолинейность" ассоциативной цепочки :)

Не всегда получается однозначно сопоставит геометрию (от единичного узла до сборки) и расчетную CAE-модель, а это значит -- "разрыв цепочки" на самой первой стадии.

В Сименсе рассуждают просто: вот -- дерево CAD, по нему строим дерево CAE.

Но у CAE -- нет дерева, в презентациях MSC это декларируется с первых слов!

CAE-данные -- это не древовидная структура.

Согласен, что здесь больше методологии, чем взаимодействия инструментов, но про взаимодействие инструментов тоже очень хочется узнать поподробнее.

(В одной из презентаций MatLab-а декларировалась возможность проведения аэродинамических расчетов по результатам "работы" Simulink-модели!)

Так в том то и дело,что ассоциативность не прямолинейна,а условна. На уровне геометрии связующим является идеализированная модель, которая может отличаться от исходной конструкторской. То же самое со структурами сборок, связь условная, но есть. На условиях и строится преобразование одного в другое. CAE данные не древовидные, но приводятся к этому виду тоже если надо:) В любом случае если на вход от конструкторов приходит дерево сборки, то как ни крути,а дело будешь иметь с такой структурой. Другой вопрос,что для CAE практически не важно какое это дерево, как организованно и как сконфигурированно. У конструкторов сборка может представлять собой многоуровневую древовидную структуру, а для CAE она же будет в виде простой одноуровневой плоской сборки. Вопрос только надо ли? Особенно если в рассчитываемых узлах есть вариантность. MSC немного лукавит, когда говорит,что связь с конструкторскими данными не так важна, и что дерево не имеет смысла:)Вот сделают они это себе в СимМенеджере и сразу станет важна:)

[Sapr2kCAE 0]

Нету в Сим-менеджере дерева :)

Там всё построено на "карте процесса", т.е этакий workflow, согласно которому производится cae-процесс.

Т.е. от получения данных до формирования отчета -- всё регламентировано!

"Шаг влево, шаг вправо..." ;) -- невозможен, если это не предусмотрено на этапе формирования "проекта".

Во, как!

А "карта процесса" создается либо CAE-специалистом, либо вкупе с CAE-специалистом в SimExpert-e.

Графически, как в Симулинке ;)

[Sten 2]

Нету в Сим-менеджере дерева :)

Там всё построено на "карте процесса", т.е этакий workflow, согласно которому производится cae-процесс.

Т.е. от получения данных до формирования отчета -- всё регламентировано!

"Шаг влево, шаг вправо..." ;) -- невозможен, если это не предусмотрено на этапе формирования "проекта".

Во, как!

А "карта процесса" создается либо CAE-специалистом, либо вкупе с CAE-специалистом в SimExpert-e.

Графически, как в Симулинке ;)

Процессность никак не отрицает древовидность данных CAE:) А что до процессов, то я для себя сделал два вывода,во-первых граммотно построенные типовые процессы CAE (простейшие) и адаптированные до уровня пользования конструкторами - сильно облегчают жизнь CAEшникам, и избавляют их от тучи рутины. А во-вторых средства workflow сейчас в любой PDM системе позволяют реализовывать процессы для CAE и тот же Sim-менеджер ничего в этом плане не даёт. Как правило с этой точки зрения в ПДМках функционала и удобств побольше будет.