Есть официальные пользователи Nastran и Marc?

[AK74 15]

Проблема состоит в том, что техподдержка MSC это полный ахтунг. Уже не первый раз, начиная ковыряться в какой-либо совершенно примитивной задачке, я натыкаюсь на ошибки в софте. Ошибки дурацкие, но они есть. Проблема возникает при попытке сообщить в техподдержку. Что русский, что американский офисы работают исключительно с официальными пользователями. Поэтому у меня ни разу не получалось законченного диалога с их специалистами. Есть вариант поставить студенческую версию, и выдав себя за студента, таки добиться от них ответов. Но быть может есть на форуме официальные пользователи, с которыми ребята из MSC охотно говорят?

 

Я этого подхода не понимаю. На мой взгляд, серьезная контора, которая радеет над качеством продукта, не должна фильтровать пользователей по классам официальности. Ведь речь идёт о качестве продукта. В случае MSC это правило не действует.

Тем не менее, меня приятно удивил Siemens. Пока я изучал их Solid Edge ST6, тоже наковырял несколько багов и они их зафиксировали, несмотря на то, что софт точно так же использовался неофициально. Но здесь скорее всего повезло с человеком, который курирует русскоязычную версию.

[JAR 28]

Это давняя беда: MSC работает только с юрлицами, в отличие от Siemens. Студенческую версию Вам не поставить, если только Вы не ректор крупного вуза.

Я являюсь официальным пользователем продуктов MSC уже 4й год, у меня нет претензий лично к Александру, Эдуарду и прочей компании, на вопросы они отвечают быстро и ясно, однако само отношение Мак-Нил Швендлера к пользователям просто вымораживает.
 Это изначально было разработкой для военных, поэтому Патран априори лишен красивостей и юзер-френдли-гайдов. Над качеством им работать ни к чему, и так все хорошо. Вот что касается линейки SimXpert/SimDesigner/SimManager, тут СМК работает по-полной. Думаю, с Apex будет еще лучше. 

А что за ошибки? В Partan? В самом Nastran на ошибки я ни разу не натыкался, вернее, в нем много подводных камней (как и во всех нормальных МКЭ-считалках), и полученный с наскоку ответ - не всегда правильный.

[AK74 15]

Это давняя беда: MSC работает только с юрлицами, в отличие от Siemens. Студенческую версию Вам не поставить, если только Вы не ректор крупного вуза.

Я являюсь официальным пользователем продуктов MSC уже 4й год, у меня нет претензий лично к Александру, Эдуарду и прочей компании, на вопросы они отвечают быстро и ясно, однако само отношение Мак-Нил Швендлера к пользователям просто вымораживает.

 Это изначально было разработкой для военных, поэтому Патран априори лишен красивостей и юзер-френдли-гайдов. Над качеством им работать ни к чему, и так все хорошо. Вот что касается линейки SimXpert/SimDesigner/SimManager, тут СМК работает по-полной. Думаю, с Apex будет еще лучше. 

А что за ошибки? В Partan? В самом Nastran на ошибки я ни разу не натыкался, вернее, в нем много подводных камней (как и во всех нормальных МКЭ-считалках), и полученный с наскоку ответ - не всегда правильный.

Ну, скажем так подозреваю, что ошибок полно зарыто в том функционале, который основная масса пользователей не использует, либо который был добавлен относительно недавно.

Ошибки в решателях.

Например в Nastran есть возможность задавать балку произвольного сечения с помощью PBMSECT, либо PBRSECT. Кроме того, разработчики предусмотрели возможность визуализации распределения напряжений по сечению с помощью PARAM,ARBMSS,YES. То бишь можно вывести красивые картинки распределения напряжений в совершенно определенных точках балки. Так вот данный функционал выводит в корне не верные результаты, как численно, так и качественно. Программа не верно визуализирует задачу, приведенную в их документации в Linear Static Analysis User’s Guide на рисунке Figure 4-38. Такого распределения напряжений для косого изгиба балки, рассмотренного в примере, не может быть.

 

В Marc сейчас наткнулся на то, что если в 2D постановке задавать жесткое контактное тело как стандартную дугу  ITYPE = 2, METHOD = 4, то в случае кусочно-линейного представления данного тела, задача решается, а если выставить analytical (гладкая дуга), то задача перестает решаться нормально, более того в некотрых случаях контакты вообще не определяются. (жесткое тело пересекает деформируемое и проходит насквозь). В некоторых случаях эта проблема решается уменьшением величины contact tolerance, а в случае масштабирования жесткого тела (при задании growth factor), контакты вообще не определяются. Мне не удалось ни разу получить решение. Как только ту же самую дугу задаем через NURBS, проблема совершенно исчезает. Если учесть, что Mentat по умолчанию всю геометрию преобразует в NURBS в случае analytical, понятно почему данная проблема не всплывала...

[AK74 15]

В задачах циклической симметрии SOL 114, если узлы, лежащие на оси и указанные чере карту CYAX будут пронумерованы последовательно и заданы через 1 THRU n, решатель выдаст ошибку *** USER FATAL MESSAGE 4313 (CY2S12)
     GRID POINT 538976288 REFERENCED BY CYAX BULK DATA CARD IS UNDEFINED.
 CYCLIC2 WILL TERMINATE DUE TO ABOVE MENTIONED FATAL ERRORS.

Вышеуказанный номер узла не существует в принципе и нигде не фигурирует до этого и насколько помню (но могу ошибаться) вообще не зависит от задачи (быть может это вообще максимально возможный номер). Ежели узлы на оси вращения задавать явно, то есть перечислением, то ошибка пропадает и задача решается.

 

Есть и еще примеры, несомненно в некотрых случаях я могу заблуждаться, но ошибки имеют место быть.

[JAR 28]

В первом случае ошибки не вижу, там же эквивалентные напряжения показаны.

Марком не пользовался.

В третьем случае ошибка не дает неправильное решение, а приводит к обрабатываемому исключению, таких вещей в Nastan, действительно, немало, а в Thermal и Flightloads еще больше. В MSC такие вещи регистрируют, принимают к сведению и через пару лет выкладывают в "перечень известных ошибок" у себя на сайте. Пользователям остается обучаться танцам с бубнами.

[AK74 15]

В первом случае ошибки не вижу, там же эквивалентные напряжения показаны.

Марком не пользовался.

В третьем случае ошибка не дает неправильное решение, а приводит к обрабатываемому исключению, таких вещей в Nastan, действительно, немало, а в Thermal и Flightloads еще больше. В MSC такие вещи регистрируют, принимают к сведению и через пару лет выкладывают в "перечень известных ошибок" у себя на сайте. Пользователям остается обучаться танцам с бубнами.

Ошибка в том, что нейтральная линия в случае косого изгиба развернута на определенный угол относительно приложенного момента и балка гнется не в вертикальной плоскости (а в плоскости, развернутой на тот самый угол), в этом можно убедиться, если посмотреть на результататы узловых перемещений. На рисунке в документации выведена не верная картина напряжений, не учитывающая данный разворот, а численные значения совершенно не соответствуют точному решению. Картинка 1 - правильное решение. Картинка 2 - не верное представление результатата. О косом изгибе хорошо написано у Феодосьева в Сопротивлении материалов.

 

В третьем случае, решатель, естественно, не даёт вообще никакого решения, т.к. отваливается с ошибкой обработки исходных данных (учитывая, что исходные данные введены верно).

 

В случае с Marc надо еще поисследовать что там не так, но я чувствую, косячок имеет место быть.

 

Есть еще большие вопросы по поводу балок переменного сечения (tapered beam). Они не выдают точное решение и результат будет зависеть от плотности разбиения на КЭ, но указаний об этом я не нашел в документации.

 

Может я конечно и придираюсь, но всю эту фигню, мне думается, надо исправлять, а не копировать от версии к версии.

[JAR 28]

Да, действительно, косяк. Результаты-то правильные, но для другой задачи.

 

 

[AK74 15]

Еще, поскольку Nastran не учитывает тот самый угол разворота, он выводит результаты напряжения не в точках, где они максимальны (лежащие на максимальном удалении от нейтральной линии), а в иных точках интегрирования, в результате можно получить небольшую ошибку и по напряжениям, хотя эта ошибка будет обусловлена всего лишь не верным выбором точек. По хорошему, проще всего было вывод сделать по 6-ти или больше точкам интегрирования, но в программе ограничение - 4 точки.

Но все это справедливо лишь для визуализации результатов. Задача на самом деле решается верно.

[JAR 28]

С этим (ограничение по Stress recovery) тоже в свое время намучились, давно плюнули на напряжения в балках и считаем руками. На Боинге то же самое - из Nastran берут только силы и моменты, а напряжения находят дедовским методом. В NASA, насколько я знаю, напряжения из Nastran тоже не используют.