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

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