Уважаемые пользователи SCAD, Лира !
Предлагаю Вам решить простейшую тестовую задачу на геометрическую нелинейность:
плоская схема, консольная балка, жесткостью EJ=10 (ед. силы*ед.длины^2) (сдвиги не учитываются). Длина балки - L=10 ед. длины . Нагружена на конце сосредоточенным моментом М=3 (ед. силы * ед. длины)
Задача имеет тривиальное решение: дуга окружности, длиной L, изогнутая по радиусу R=EJ/M .
Пробовал решать в SCAD, получил какую то хрень. Думаю вы ее за полминуты воспроизведете.
[ATTACH]1188461462.GIF[/ATTACH]

[p_sh]

в микрофе тоже не получилось

[dermoon]

Не совсем понял, что должно получиться? Деформации? В СКАДе по горизонтали получается 5,1 ед. длины, по вертикали 12,5 ед. длины. Еще что?

Сообщение от p_sh в микрофе тоже не получилось

Интересно, спасибо.

Сообщение от dermoon Не совсем понял, что должно получиться? Деформации? В СКАДе по горизонтали получается 5,1 ед. длины, по вертикали 12,5 ед. длины. Еще что?

Должно получиться вот что: момент = М, поп. сила = прод. сила = 0 (это чистый изгиб, очевидно).
Изогнутая ось воспроизводит дугу окружности, радиусом R=10/3=3.33.
Перемещения (от начальной точки): вертикальная проекция +6,6; горизонтальная -9,5.
Деформированная схема (ANSYS Educational v9)
[ATTACH]1188465378.JPG[/ATTACH]

[Разработчик]

в микрофе тоже не получилось

Значит не умеете! В понедельник вернется Семенов, передам ему - он расскажет как сделать.

[novinkov]

ANSYS:
Поступательные перемещения по оси Y. Масштаб перемещений - реальный. Радиус ~ UY/2 (половина перемещения по оси Y) 6.63/2=3.31м
[ATTACH]1188465339.jpg[/ATTACH]

[novinkov]

Горизонтальное перемещение -9.53м
[ATTACH]1188465672.jpg[/ATTACH]


Добавил: большой пардон. Не обратил внимание, что решение уже ранее дано в ANSYS

[ander]

Хворобьевъ, если Вы хотели увидеть закручивание, то нужно было тип КЭ сменить на гибкий, а не стандартный КЭ-10, я такую задачу уже решал, все там нормально получается. Ну и про дробление стержня надо не забыть.

Сообщение от ander Хворобьевъ, если Вы хотели увидеть закручивание, то нужно было тип КЭ сменить на гибкий, а не стандартный КЭ-10, я такую задачу уже решал, все там нормально получается. Ну и про дробление стержня надо не забыть.

Естественно, я хотел бы видеть правильное решение, оно единственное в данном случае.
Не могли бы выложить файл, или скриншорт с результатами. Я естественно дробил (на 10 частей) и элементы разные пробовал. Получается ерунда почему то - во всех случаях.
В тот то и фокус, что в ANSYS правильное решение получается для всех типов конечных элементов, в т.ч. самых "неточных" - с линейной аппроксимацией поля перемещений. И при автовыборе (по умолчанию) разновидности метода Ньютона-Рафсона.

[dermoon]

В Скаде результаты разнятся в зависимости от продольной жесткости (EF) и количества интераций. Какую продольную Вы задаете в Анисе? Если в Скаде EF=0, то горизонтальные перемещения тоже в 0 уходят. Это при элементе 305.

Сообщение от dermoon В Скаде результаты разнятся в зависимости от продольной жесткости (EF) и количества интераций. Какую продольную Вы задаете в Анисе? Если в Скаде EF=0, то горизонтальные перемещения тоже в 0 уходят. Это при элементе 305.

Да, продольная жесткость не должна влиять при чистом изгибе. Но, вообще, брал большую, по моему от 1 до 1000, или около того (несжимаемое тело).
Вот попробовал посчитать еще в одной программе, которую в download раньше (вернее руководство по которой) выкладывали.
http://dwg.ru/dnl/2224
При М=3 просто не досчитывает до конца, указывает на расходимость интерационного процесса. При М=0,5 сходится и дает сравнительно верный результат.
В SCAD фигово даже не то, что результат неверный (он кстати при малых значениях перемещений все же близок к теории), а то что под видом верного результата может выдаваться всякая бяка. По моему должен быть контроль сходимости какой то.
[ATTACH]1188484123.JPG[/ATTACH]

Вот ансисовский код
и в архиве абакусевый инп-файл для CalculiX.

Код:

[Выделить все]

L=10
M=3
E=10
J=1
/PREP7
ET,1,BEAM3
R,1,1,J,, , , , 
MP,EX,1,E
K,1,
K,2,L
L,1,2
LESIZE,ALL, , ,10, ,1, , ,1,
LMESH,ALL
/SOLU
DK,1, , , ,0,ALL, , , , , , 
FK,2,MZ,M
NLGEOM,ON
SOLVE
FINISH  
/POST1   
*GET,UY,NODE,2,U,Y  
alpha=L*M/(E*J)
UY_TH=2*(E*J/M)*(sin(alpha/2))**2
ERR=(UY/UY_TH-1)*100

[ATTACH]1188487483.zip[/ATTACH]

[dermoon]

У меня в Анисе такая-же загибулина. В Скаде результаты почему-то стремятся к точности наоборот, вертикальные - как горизонтальные, примерно 10, горизонтальные - как вериткальные, примерно 6.

Сообщение от dermoon В Скаде результаты почему-то стремятся к точности наоборот, вертикальные - как горизонтальные, примерно 10, горизонтальные - как вериткальные, примерно 6.

А не могли бы Вы выложить файл spr или TXT, просто глянуть?

Я могу только догадываться о причинах, почему алгоритм одной программы оказывается эффективнее другого, применительно к данной задаче.
Насколько я представляю по статьям, в ANSYS сходимость автоматически отслеживается , может изменяться метод и увеличиваться число шагов. При проблемах со сходимостью он выбрасывает флаг, а результаты, которые успели получиться верны с заданной точностью. Ясно, что ANSYS - машинстроительная программа, постоянно юзаемая для контактных задач, физнелина, нестационарного тепла и т.д. Там все эти методы получше отработаны, чем в строительном софте.
Кстати, что то Лировцы прижукнулись, неужели никто не пробовал решить??

[Sleekka]

Раскажите пожалуйста причем здесь геом нелинейность и почему должна получиться окружность когда слева - заделка?

Сообщение от Sleekka Раскажите пожалуйста причем здесь геом нелинейность и почему должна получиться окружность когда слева - заделка?

заделка это реактивный момент, уравновешивающий активный. не окружность, а дуга окружности должна получиться.
Для упругой балки испытывающей чистый изгиб справедлива зависимость: K=M/EJ
где K=1/R кривизна, величина обратная радиусу кривизны. Для пологой кривой кривизну заменяют на вторую производную, получают приближенное дифференциальное уравнение. Точное выражение кривизны дает возможность использовать уравнение для больших прогибов. Нелинейность между М и перемещением тут налицо из геометрических соотношений...

[Shbalanke]

Лира 9.4 КЭ310 (нить?) EF>0

[ATTACH]1188499733.gif[/ATTACH]

[Sleekka]

Спасибо - вроде разобрался.

[Lamer Inc..]

Вроде похоже в Лире получается...
[ATTACH]1188503576.jpg[/ATTACH]

[dermoon]

Вот Скадовский файл: (7.31R5)
[ATTACH]1188518949.zip[/ATTACH]

Сообщение от Lamer Inc.. Вроде похоже в Лире получается... [/ATTACH]

Спасибо.
Т.е. получается только для одного типа элемента, а остальные учет нелинейности не предполагают? дает ли Лира при адекватной разбивке всегда сходящийся к верному результат, или может выдавать невесть что?
И еще, не могли бы вы выложить текстовый файл или бинарный?
замыкается ли в начальную точку в Лире окружность при М=2*Pi() = 6.283 ?



dermoon

спасибо.
при M=0.5 и заданных вами параметрах нелинейного расчета SCAD дает верный результат (ни момент не перевирает, ни перемещение).
Это даже лучший результат который я когда-либо видел. Для более сложных задач (например продольно-поперечный изгиб) он начинает врать гораздо раньше, т.е. практически сразу за критической силой. а для мачт на оттяжках (конструкций, в которых это практически все нужно) и задолго до потери устойчивости.

[ATTACH]1188528828.GIF[/ATTACH]

[dermoon]

Хворобьевъ
Похоже, Скад не умеет считать на действительно большие перемещения. Тут недавно была тема: http://dwg.ru/forum/viewtopic.php?t=15366
У автора темы получалось по деформациям вообще фигня, у меня, когда я заново создал его задачку, более-менее вразумительные результаты вышли. Не могли бы Вы воспроизвести эту задачку в Анисе? Я вот что-то не знаю, как в Анисе задавать связь конечной жесткости.

Сообщение от dermoon Хворобьевъ Похоже, Скад не умеет считать на действительно большие перемещения. .

Фигово не то, что он не умеет считать что то, а то, что он под видом правильного результата может выдавать фигню (бывает что и линейных задач это касается). Когда речь идет при этом только о несовершенстве самого метода, то это не способствует доверию и создает общее чмошное впечатление. Вы опытный пользователь SCAD, и то столкнулись с затруднениями. А ведь в практических задачах нет возможности знать точное решение наперед! И где заканчиваются "маленькие" и начинаются "большие" перемещения? И какой итерационный метод выбирать с ходу? Для коммерческой программы не уметь корректно делать заявленные изначально вещи - это не понятиям.

Сообщение от dermoon Не могли бы Вы воспроизвести эту задачку в Анисе? Я вот что-то не знаю, как в Анисе задавать связь конечной жесткости.

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

[Lamer Inc..]

Лира 9.2:
[ATTACH]1188543186.rar[/ATTACH]

Т.е. получается только для одного типа элемента, а остальные учет нелинейности не предполагают?

- Да, задача с сильно изгибаемыми элементами в Лире решается КЭ-309.

Сообщение от Lamer Inc.. - Да, задача с сильно изгибаемыми элементами в Лире решается КЭ-309.

Спасибо.
Выкладываю вторую тестовую задачу.
Тестовая задача #2:
прощелкивание круговой безшарнирной арки (заделанной),
радиусом 41 ед. длины,
нагруженной по середине сосредоточенной силой -2000 ед. силы
Сечение арки прямоугольное: ширина b=1, высота h=0,5.
Модуль Юнга Е=30000000 ед.силы/ед.дл^2
Сдвиги не учитываются.
Ответ: перемещение по центру = 66.07 ед. длины
решается методом засечек.
График и файл в прис. архиве.
В SCADе у меня получилось 61 ед., но форма не пойми какая. Интересен результат Лиры.
[ATTACH]1188545474.zip[/ATTACH]

[Александр Бауск]

За Calculix -- я вас люблю.

[АС_В]

какая в принципе не отвечающая реальности задача
(прям веет студенческими временами)

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

[Александр Бауск]

Ну вообще-то здесь речь идет не о соответствии реальности, а об алгоритмах работы и их последствиях.

[MMV]

"но поскольку там нет в библиотеке вантового элемента как такового"

А link10 С keyopt3=0?

Сообщение от MMV А link10 С keyopt3=0?

Это просто односторонняя связь и он не учитывает провисания от поперечной нагрузки на ванту. Его (1 оттяжка = 1 элемент) можно использовать в первом приближении, с подкорректированным модулем упругости, с точностью ±10-15 %.
Также все линковые и балочные элементы можно использовать в качестве вант, разбив на несколько частей (как в верификационных примерах). Но это геометрически-изменяемая система, одну нить смоделировать можно запросто, но если вант много то процесс просто будет расходиться.

[vv_77]

Интересную книжечку выложил Техсофт. Руки так и чешутся все это попробовать...

http://www.tech-soft.ru/otchet_14.pdf

(тут есть и ЭТОТ пример)

ЗЫ: Семенову низкий поклон.

[ETCartman]

Сообщение от vv_77 http://www.tech-soft.ru/otchet_14.pdf .

Интересно - хоть одна отечественная программа сертифицированна по ISO как ANSYS или Code_Aster
В верификационных задачах ничего по себе необычного нет, их в любом случае решают авторы и почти всегда (за рубежом во всяком случае) добавляют в дистрибутив.
Кстати бывает что версия под Линукс считает верно на некоторых задачах, а версия под виндоус косячит. Вообще - верификация на подобных примерах суть защита от грубых ошибок (и хорошая демонстрация возможностей к тому же).

[Rotfeder]

Сообщение от ETCartman Интересно - хоть одна отечественная программа сертифицированна по ISO как ANSYS или Code_Aster В верификационных задачах ничего по себе необычного нет...

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

Опять же вот забавная история
Весьма поучительное событие произошло 23 сентября 1999 года, когда при попытке выхода на орбиту спутника Марса погибла американская автоматическая межпланетная станция Mars Climate Orbiter. Спустя неделю было выпущено официальное сообщение, приведшее многих в шок [3]: в бортовом программном обеспечении оказалась не выявленная при многократных проверках ошибка, которая привела к неправильному управлению станцией. Причина ошибки заключалась в том, что одна из групп разработчиков использовала британскую систему единиц измерений, а другая - метрическую. Наибольшую озабоченность руководство NASA выразило даже не потерей объекта стоимостью 125 млн. долл., а неспособностью системы контроля качества выявить ошибку. И насмешкой выглядело сообщение, также вышедшее после аварии, что одна группа разработчиков программного обеспечения полетов уже сертифицирована в соответствии с ISO 9001, а другая рекомендована для этой процедуры
взято отсюда http://www.osp.ru/cio/2001/11-12/171992/

Что же касается верификации, то все зависит от самих тестов. Правильно подобранные тесты показывают можно ли использовать программу, вообще, а так же для каких задач и с какими ограничениями можно ее использовать.
Что же касается ошибок, то они есть везде, вне зависимости ото всяких ISO. И, как мне кажется, какая-нибудь простая шкала оценок типа теста Джоела Спольски
http://russian.joelonsoftware.com/Ar...eJoelTest.html более эффективна для борьбы с ними.

[ETCartman]

По ISO предполагается решение верификационных примеров, как в представленном документе. Проверки касается самой математики и конечных элементов.
Госстроевская сертификация касается только соответствия перечисленным позициям СНиП, хотя практически человек может и не использовать модули подбора арамтуры или сечений. И что удивительно - все сертифицированные программы дают разные, иногда в разы отличающиеся результаты на инженерных проверках притом.
Я бы не сказал, что ISO совсем фигня, хотя ошибки есть везде и даже неизбежны. Для меня лично критерий доверия - самостоятельное решение тестовых примеров. Это помогает установить уверенную связь с программой. Мне кажется что и расчетчиков нужно самих именно так "сертифицировать" - чтобы из справочника задачи фигачили.
Дело ведь еще в том, что расчет зависит от выбора модели, а выбор расчетных схем и моделей практически нельзя формализовать - это очень индивидуально.
Кстати наш институт по ISO сертифицировался. По моему бардака еще больше стало -)
Так что абсолютно с вами солидарен - хорошей программе сертификат не нужен, ее и так видно.

[Rotfeder]

По поводу самостоятельного решения тестовых примеров - вы счастливый человек, если имеете время на прогонку пары-тройки сотен тестовых примеров. И это только для проверки основ МКЭ-расчета, не говоря уже про расчеты по нормам.
Проверять программы, конечно, стоит. Но боюсь у рядовых инженеров - сотрудников некрупных контор - времени на это реально нет.
Сдается мне что стоит искать золотую середину - самому проводить выборочные проверки, а в остальном доверятся проверкам независимых организаций. Если у нас действительно наладят систему верификации - это будет хорошее дело.
Насчет же госстроевской сертификации, то там, как мне кажется, проверяется формальное наличие расчетов, но не их истинность. В любом случае не проводится полноценное тестирование, так что в разных результатах сертифицированных программ нет ничего удивительного.

[ETCartman]

"пары-тройки сотен тестовых примеров" - времени само собой нет. Но один-два на заданную тему периодически решить не помешает.