Роторная динамика в NX Nastran: Решение задачи разными методами

[karachun 2 038]

Здравствуйте!
Осваиваю расчет роторной динамики в NX Nastran. Моделирую тестовый ротор.

Вот такой  

Hide  

 

В качестве подшипников использую элементы CBUSH - обычные Фемаповские пружины.
Строю диаграмму критических скоростей. Я не включил продольные формы колебаний в эту диаграмму для упрощения понимания.

Диаграмма Кэмпбелла  

Hide  

 

После этого рассчитываю отклик от дисбаланса (ETYPE = 1). Считаю модальным и прямым методом (Modal - SOL111, Direct - SOL108).
Для модального метода использую фиксированную и вращающуюся системы координат (REFSYS - FIX/ROT).
Задаю вязкоупругое демпфирование в подшипниках и структурное для всей модели, через PARAM,G,.04.
Рассчитываю случаи для прямой и обратной прецессии ротора (через изменение фазы нагрузки DAREA с 90 на -90).
Нагрузки для прямой и обратной прецесии
И получаю не совсем понятные результаты (перемещения узла №20 в котором приложена нагрузка от частоты):

 

1. Модальный расчет в фиксированной КС для прямой прецессии - результаты похожи на правду - пики на частотах 3, 15, 35 и 78 Гц соответствуют пересечениям линии 1P диаграмме Кэмпбелла (правда крит. скорости соответствуют обратной а не прямой прецессии).

Отклик зависит от демпфирования.

Модальный расчет в фиксированной КС для прямой прецессии  

Hide  

 

2. Модальный расчет во вращающейся КС для прямой прецессии - получается парабола.

Модальный расчет во вращающейся КС для прямой прецессии  

Hide  

 

Сравнение откликов  

Hide  

 

Для расчета изменил два значения

ROTORD Card  

Было
ROTORD         1      1.      1.     100     FIX     -1.      HZ      HZ+       
+             NO    1.-6               1       1     1.0                +       
+              1       1                                                
Стало
ROTORD         1      1.      1.     100     rot     -1.      HZ      HZ+       
+             NO    1.-6               1       1     0.0                +       
+              1       1                                                

 

Hide  

 

3. Прямой расчет в фиксированной КС для прямой прецессии - пики соответствуют критическим оборотам, но результаты не зависят от значения структурнрго демпфирования - для данного случая структурное демпфирование вообще не учитывается.

Сравнение с модальным методом при одинаковых настройках  

Hide  

 

4. Те же модели для обратной прецессии: неожиданно результаты модального и прямого в фиксированной КС близки с учетом неизбежной неточности модальных расчетов. В модальном рассчете с фрвщающейся КС пики соответствуют линейным (продольным) формам колебаний.

Три метода для обратной прецессии (зеленая и красная линии практически совпадают) 

Hide  

 

При составлении файлов руководствовался NX Nastran 11 Rotor Dynamics User’s Guide.
Из всего этого возникают вопросы: что я делаю не так и как добиться получения совместных результатов для трех вариантов анализа модели? И являются ли сами результаты адекватными (для критических скоростей - например 75 Гц диаграмма Кэмпбэлла показывают обратную прецессию, но отклик находится методами прямой прецессии - фаза нагрузки DAREA).
 

Также в файле FRA_(Modal,Fix,Forward)_Var_Bearing.dat, рассчитываю немного изменеррый ротор с частотно зависимыми подшипниками (через свойство PBUSHT). Если изменить значение жесткости в таблице с 1000001 на 1000000 - функция жесткости подшипника от частоты, то модель считается, а в текущем варианте - выдает ошибку.
Как можно учесть нелинейные подшипники для роторной динамики?
 

Таблицы функции жесткости  

Не считает
TABLED2        5      0.                                                +       
+             0.1000000.    100.1000001.ENDT

Считает
TABLED2        5      0.                                                +       
+             0.1000000.    100.1000000.ENDT

 

Hide  

Файлы анализа прикладываю.

Заранее благодарю за помощь!

 

 

 

 

 

Critical Speeds.dat

FRA_(Modal,Fix,Forward).dat

FRA_(Modal,Rot,Forward).dat

FRA_(Direct,Fix,Forward).dat

FRA_(Modal,Fix,Backward).dat

FRA_(Modal,Rot,Backward).dat

FRA_(Direct,Fix,Backward).dat

FRA_(Modal,Fix,Forward)_Var_Bearing.dat

Изменено 20 февраля 2018 пользователем karachun

[karachun 2 038]

Проблема частотнозависимых подшипников решилась использованием CBEAR вместо CBUSH (но в документации к NX Nastran заявлено, что можно использовать CBUSH с функциональными зависимостями). Но осталась проблема - при решении прямым методом - SOL108 решатель игнорирует структурное демпфирование - в приложенном примере изменение параметра PARAM,G,.04 не приводит к изменению результата. Отклик получается такой, как при PARAM,G,.0

FRA_(Direct,Fix,Forward)_CBEAR_Damping.dat

[Arkur 15]

 попробуйте задать напрямую демпфирование в поле GE для MAT1 и PBUSH

 

Изменено 21 февраля 2018 пользователем Arkur

[karachun 2 038]

По поводу демпфирования в SOL108 подсказали на портале сименс: нужно использовать параметры W3 и W4, как в трансиенте, для перевода структурного демпфирования в вязкоупругое. При этом скорости задаются в карточке ROTORD (возможно через PARAM,W3/PARAM,W4 тоже будет рабоать, но я не проверял). В обоих случаях частоту нужно задавать в радиан/сек. В NX Nastran 11 Rotor Dynamics User’s Guide все это описано в пункте 2.1.4.

Изменено 22 февраля 2018 пользователем karachun

[karachun 2 038]

Дополню, что частотозависымые элементы CBEAR можно использовать вместо CBUSH и в статоре модели, для того чтобы настран правильно включил их в расчет их тоже нужно добавить в группу к элементам подшипников, а ID группы прописать в карточке ROTORD.

Изменено 14 мая 2018 пользователем karachun

[Arkur 15]

@karachun А Nastran NX умеет распараллеливать транзиент на несколько ядер?

 

[karachun 2 038]

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

Показать содержимое  

Hide  

Вообще для модального транзиента (SOL 111-112) можно заморочиться и освоить рестарт - тогда можно использовать формы, насчитанные при расчете собственных частот, а на это уходит основное количество ресурсов.

[Arkur 15]

А вы случайно сами не считали SOL129? там действительно при основном расчете используется несколько ядер? Мы используем MSC Nastran и там получилось распараллелить только расчет собственных частот. Это нам не нужно. Основное время тратиться непосредственно на сам расчет SOL129 т.к. вместо рестарта используем суперэлементы

[karachun 2 038]

С MSC Nastran никогда не работал, о степени загруженности судил по диспетчеру задач. С 129 решателем тоже не работал, он считает переходные процессы прямым и модальным методами?

[Mrt23 173]

не только Nastran, если Вас это успокоит.)

[Arkur 15]

31 минуту назад, karachun сказал:

С MSC Nastran никогда не работал, о степени загруженности судил по диспетчеру задач. С 129 решателем тоже не работал, он считает переходные процессы прямым и модальным методами?

SOL 129 - Nonlinear or linear transient response.

23 минуты назад, Mrt23 сказал:

не только Nastran, если Вас это успокоит.)

Я что-то подобное подозреваю, но надеюсь на прогресс:)  Вдруг еще и ускорение на GPU появится...

P.s. А Вы сейчас говорите только про Абакус?

 

[Mrt23 173]

да, если говорить о substructure. он тоже пишет что-то про not supported. 129-скорее всего параллелится, НО из-за субструктур...=( уже считает на одном потоке. 

могу ошибаться. @kolo666, расскажите, пожалуйста, что и как там в Nastran. =)

[karachun 2 038]

Запустил тестовый расчет 500k DOF в 129 решателе - периодически загрузка восьмиядерного CPU доходит то 100%.

[Mrt23 173]

@karachun с субструктурами?

Изменено 14 мая 2018 пользователем Mrt23

[karachun 2 038]

нет, запустил через bat-файл с параметром smp=8

Изменено 14 мая 2018 пользователем karachun

[Mrt23 173]

а... ну так то понятно...

[kolo666 255]

5 часов назад, Mrt23 сказал:

расскажите, пожалуйста, что и как там в Nastran

В Nastran, каждое решение - это набор модулей DMAP, каждый из которых выполняет определенные математические операции, типа декомпозиции матрицы и т.п.

Какой-то модуль поддерживает распараллеливание или использование графического процессора (например, графика AMD и NVIDIA поддерживаются в модуле декомпозиции DCMP и модуле частотной характеристики FRRD1), а какие-то модули не используют эти возможности .. поэтому не совсем правильно говорить о распараллеливании какого-либо решения в целом.

 

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

5 часов назад, karachun сказал:

периодически загрузка восьмиядерного CPU доходит то 100%.

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

Поэтому имеем:

7 часов назад, Arkur сказал:

там получилось распараллелить только расчет собственных частот

Как-то так..вообще там очень много всего в этой теме..но надеюсь чем-то помог=)

Изменено 14 мая 2018 пользователем kolo666

[kolo666 255]

 @karachun верно подметил

8 часов назад, karachun сказал:

но вообще там быстродействие намного сильнее зависит от скорости жесткого диска, для средних и больших моделей

При быстром SSD прирост производительности реально ощущается, и не только при решении (в несколько раз), но и при создании моделей - работать намного комфортнее потому, что все равно идет обмен с жестким (через папку Stratch).

Но прогресс не стоит на месте, например MSC в APEX пошли несколько иным путем - матрица жесткости создается для каждой детали отдельно, насколько я помню, там нет понятия сшить узлы, вместо этого используется податливое соединение. Таким образом можно параллелить создание глобальной матрицы жесткости - это дает некий прирост производительности для больших сборок.

[karachun 2 038]

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

Показать содержимое  

Hide  

[kolo666 255]

12 часа назад, karachun сказал:

для больших моделей можно улучшить скорость решения включив итеративный решатель

Только если модель по большей части аппроксимирована объемными элементами с количеством DOF от 1-2кк.

С одними пластинами не прокатит.

Изменено 15 мая 2018 пользователем kolo666