с матлабом не знаком, не уверен что главную идею правильно понял. сведение сложной системы к комбинации готовых настраиваемых модулей, без учёта их пространственного расположения, каждый из которых имеет достаточно обкатанную параметрическую модель, с автосшивкой на стыках, что позволяет быстро получить оценки по работе системы в целом?
показанные блок-схемы flo(w)master напоминают.
на одном блочном подходе далеко ли можно уехать? самые интересные вещи - глубоко уникальны, и создание их параметрической модели - сомнительное занятие, тем более что не с чем сравнить без прототипирования, которого нужно всячески избежать.
"всё с первого раза работает! ... одним движением мышки взял ... одним кликом сделал ... нажал ещё на одну кнопку и увидел все ... всё это за один расчёт модели". эээ, ну-ну :) в подобный софт вваливаются сотни человеколет, через него прокачиваются премногие тысячи невыдуманных пользовательских задач, и даже после этого утверждать что либо с таким оптимизмом невозможно. впрочем маркетологи именно этим и занимаются, но так никогда не станут делать инженеры и программисты, потому что в каждом из этих высказываний видят границы их применимости.
Да, принцип вы правильно поняли. У Flowmaster, насколько я знаю, похожий принцип. По поводу "далеко ли можно уехать", могу сказать, что есть два редко пересекающихся мира - моделирование систем в концентрированных параметрах и распределённых (метод конечных элементов, CFD и т.д.). К примеру, для расчёта гидропривода с давлением около 200 атмосфер не имеет практически никакого значения высота расположения элементов, да и вихри при выходе из трубочек. Для лопастного насоса уже такие допущения не годятся и нужно учитывать каждый изгиб лопатки. Для каждой задачи нужен свой софт.
"всё с первого раза работает! ... одним движением мышки взял ... одним кликом сделал ... нажал ещё на одну кнопку и увидел все ... всё это за один расчёт модели". эээ, ну-ну :)
Я смотрю, вы в теме :) Дальше по тексту: "Те, кто имел дело с математическим моделированием, наверняка ехидно ухмыльнулись на том моменте, где я рассказывал, что ты просто набрасываешь нужные тебе элементы и получаешь желаемую модель."
один из этих миров по-видимому очень мал, ибо запрос "моделирование систем в концентрированных параметрах" выдаёт около нуля релевантных результатов. я на стороне cfd, привет из другого мира!
эти задачи не так уж и изолированы. насколько я понимаю, довольно часто в достаточно простой схеме имеется по крайней мере один нетривиальный блок, который испортит всю затею на корню. как вы с этим справляетесь? а: придумай сам модель своей штуковины и впиши вот сюда сорок таблиц? или б: покрути эти тысячи ручек дженерик модели и подгони результат под свой вариант?
мы скрещивали таких ежа с ужом несколько лет назад - одномерный flowmaster с трёхмерным cfd. 3d-пакет в автоматическом режиме набивал вариацией входных параметров параметрическую модель нетривиального компонента, после чего его можно было вставить блоком в 1d-пакет. профит! голосуйте за трампа выбирайте комплексные решения от mentor graphics siemens
Да, CFD сейчас на подъёме, но у нас от этого меньше работы не становится) Ещё раз, мы не конкурируем с CFD, а CFD не конкурирует с нами. Если нам нужна модель какой-то нетривиальной штуки, мы можем построить её на основе эксперимента, а можем и взять из CFD-расчёта. Мы сами клиентов часто отправляем к CFD, когда видим, что постановка задачи выходит за рамки системы ОДУ.
По поводу скрещивания ежа с ужом, в Дрезденском ТУ скрещивали нашу программу с Ансисом лет 10-15 назад. Пришли к выводу, что делать так можно, вопрос только - нафига?) Проще насчитать характеристики в CFD, забить таблицей в нашу программу и считать динамику. А ещё лучше на этапе CFD расчёта изменить конструкцию так, чтобы гидродинамика вела себя предсказуемо и могла быть описана простыми формулами.
Сейчас ANSYS прибрал к рукам SCADE (ранее бренд компании Esterel Technologies), и они как раз заявляют обо всём об этом: полная интеграция с их МКЭ-МКР-линейной, системное моделирование посредством наглядных пиктограмм, интеграция со сторонними моделями, автоматическая кодогенерация под требования автомобильных и авиационных стандартов. Было бы любопытно почитать, как позиционируется ваше ПО в плане конкуренции с ANSYS, основные преимущества-недостатки и т.д. и т.п.
Ну а нас сейчас купила фирма ESI, которая позиционирует себя как виртуальную фабрику, где "вообще не надо будет умирать". Я скептически отношусь к попыткам скрестить эти два типа этих задач до тех пор, пока мощности компьютеров не выйдут на тот уровень, когда МКЭ и прочие можно будет считать хотя бы в реальном времени. По поводу кодогенерации, по части стандартов я ничего не скажу, но производители автомобилей давно используют наш софт для кодогенерации. Так что, конкретно для нас ANSYS - не конкурент. Конкурент для нас - Amesim и Dymola. У них удаётся с переменным успехом отбивать клиентов. Где за счёт более высокой скорости расчётов, где за счёт удобства.
показанные блок-схемы flo(w)master напоминают.
на одном блочном подходе далеко ли можно уехать? самые интересные вещи - глубоко уникальны, и создание их параметрической модели - сомнительное занятие, тем более что не с чем сравнить без прототипирования, которого нужно всячески избежать.
"всё с первого раза работает! ... одним движением мышки взял ... одним кликом сделал ... нажал ещё на одну кнопку и увидел все ... всё это за один расчёт модели". эээ, ну-ну :) в подобный софт вваливаются сотни человеколет, через него прокачиваются премногие тысячи невыдуманных пользовательских задач, и даже после этого утверждать что либо с таким оптимизмом невозможно. впрочем маркетологи именно этим и занимаются, но так никогда не станут делать инженеры и программисты, потому что в каждом из этих высказываний видят границы их применимости.
Reply
По поводу "далеко ли можно уехать", могу сказать, что есть два редко пересекающихся мира - моделирование систем в концентрированных параметрах и распределённых (метод конечных элементов, CFD и т.д.). К примеру, для расчёта гидропривода с давлением около 200 атмосфер не имеет практически никакого значения высота расположения элементов, да и вихри при выходе из трубочек. Для лопастного насоса уже такие допущения не годятся и нужно учитывать каждый изгиб лопатки. Для каждой задачи нужен свой софт.
"всё с первого раза работает! ... одним движением мышки взял ... одним кликом сделал ... нажал ещё на одну кнопку и увидел все ... всё это за один расчёт модели". эээ, ну-ну :)
Я смотрю, вы в теме :)
Дальше по тексту:
"Те, кто имел дело с математическим моделированием, наверняка ехидно ухмыльнулись на том моменте, где я рассказывал, что ты просто набрасываешь нужные тебе элементы и получаешь желаемую модель."
:)
Reply
эти задачи не так уж и изолированы. насколько я понимаю, довольно часто в достаточно простой схеме имеется по крайней мере один нетривиальный блок, который испортит всю затею на корню. как вы с этим справляетесь? а: придумай сам модель своей штуковины и впиши вот сюда сорок таблиц? или б: покрути эти тысячи ручек дженерик модели и подгони результат под свой вариант?
мы скрещивали таких ежа с ужом несколько лет назад - одномерный flowmaster с трёхмерным cfd. 3d-пакет в автоматическом режиме набивал вариацией входных параметров параметрическую модель нетривиального компонента, после чего его можно было вставить блоком в 1d-пакет. профит! голосуйте за трампа выбирайте комплексные решения от mentor graphics siemens
Reply
Ещё раз, мы не конкурируем с CFD, а CFD не конкурирует с нами. Если нам нужна модель какой-то нетривиальной штуки, мы можем построить её на основе эксперимента, а можем и взять из CFD-расчёта. Мы сами клиентов часто отправляем к CFD, когда видим, что постановка задачи выходит за рамки системы ОДУ.
По поводу скрещивания ежа с ужом, в Дрезденском ТУ скрещивали нашу программу с Ансисом лет 10-15 назад. Пришли к выводу, что делать так можно, вопрос только - нафига?) Проще насчитать характеристики в CFD, забить таблицей в нашу программу и считать динамику. А ещё лучше на этапе CFD расчёта изменить конструкцию так, чтобы гидродинамика вела себя предсказуемо и могла быть описана простыми формулами.
Reply
Reply
Я скептически отношусь к попыткам скрестить эти два типа этих задач до тех пор, пока мощности компьютеров не выйдут на тот уровень, когда МКЭ и прочие можно будет считать хотя бы в реальном времени.
По поводу кодогенерации, по части стандартов я ничего не скажу, но производители автомобилей давно используют наш софт для кодогенерации.
Так что, конкретно для нас ANSYS - не конкурент. Конкурент для нас - Amesim и Dymola. У них удаётся с переменным успехом отбивать клиентов. Где за счёт более высокой скорости расчётов, где за счёт удобства.
Reply
Reply
Leave a comment