Пожелания официальных пользователей

Заметил некоторую разницу в подборе арматуры в пластинчатых элементах пр расчете в релизе от 14.05.07 по сравнению с релизом от 12.02.07. Подскажите, что произошло? Почему теперь арматуры требуется больше..? P.S. Кстати, задачу я выслал в Ваш адрес 30.05.07...

У зв'язку з великою кількістю неіснуючих підписок на оновлення форуму була проведена очистка. Якщо ви перестали отримувати повідомлення з оновленнями, прохання провести підписку знову.
   RSS
[ Закрито ] Пожелания официальных пользователей, Тема для обсуждения новшеств необходимых по мнению пользователей
 
Заметил некоторую разницу в подборе арматуры в пластинчатых элементах пр расчете в релизе от 14.05.07 по сравнению с релизом от 12.02.07. Подскажите, что произошло? Почему теперь арматуры требуется больше..?
P.S. Кстати, задачу я выслал в Ваш адрес 30.05.07...
Сторінки: Поперед. 1 ... 3 4 5 6 7 ... 20 Наст.
Відповіді
 
Еще вопрос(пожелание), если это возможно, сделать места пересечения элементов "живыми" чтоб можно было к ним "привязаться", просто когда оба элемента идут под углом  для вычисления точки их пересечения тратиш время, которого обычно нет. или может есть кокой-то способ?
 
аспирант, по этому поводу можно обратиться на dwg.ru, там есть и люди, кто был на семинарах, так и дискуссии, также в книге Городецкого "Расчет и проектирование конструкций высотных зданий из монолитного железобетона" этот вопрос, по-моему тоже упоминается.

Цитата
аспирант пишет:
сделать места пересечения элементов "живыми" чтоб можно было к ним "привязаться"
Вы тратите время, потому что не знаете, что найти пересечение КЭ можно выполнить довольно быстро - 2 объекта (линия, пластина, объемные или несколько) объединяются в разные блоки, затем выполняется стандартная операция - пересечение блоков. Можно в акаде, если есть исходная схема.
 
ander

спасибо! действительно не знал :( .
 
Цитата
ander пишет:
когда выйдут в свет описание остальных документов для входного языка? (до 9.4)

:idea: Есть идеи вообще исключить текстовый файл из цепочки выполнения расчета. Размеры текстов задач неуклонно растут в виду увеличения производительности программ и «железа» . Препроцессор тратится на создание, процессор на разбор и контроль огромных файлов.
Поэтому  не знаю будут ли документированы дополнения к файлам *.тхт .  :oops:
 
Пока есть текстовый файл, есть хоть какая-то возможность прочесть файл в низшей версии. Если конечно будет предусмотрен алгоритм пересохранения в файлы для низших версий, то не все так страшно.
 
В лире есть возможность получить после счета картину инерционных нагрузок по тонам , например от сейсмического воздействия.  Можно вручную прилагать их как нагрузки создавая псевдосейсмическое нагружение. Далее копированием нагружений можно создавать   любые нагружения-комбинации и после счета можно пользоваться всеми благами визуального анализа.
Просьба к разработчикам автоматизировать процесс приложения инерционных нагрузок, создавая  под заказанным именем вариант исходной задачи с добавкой новых нагружений после всех имеющихся.  
 
Просьба к разработчикам сохранить и на будущее
текстовый формат данных. это гарантированная проверка корректности данных при выходе на счет.
Имея опыт несложно разобраться со всеми новациями табличного ввода. легко перебросить данные в scad7.31, правда чуть сложнее обратная задача.
Несложно перекодировать основные массивы :
элементы , координаты и  при желании жесткостные
характеристики в  fea формат, используя только word и exel. Не стоит закрываться от друзей-конкурентов. Этим вот французский ROBOT сразу оттолкнул.
Лира универсальна и как средство быстрой и качественной подготовки исходных данных не только под себя саму. Зная ее, можно сработать на всем.если
понадобится.
 
Когда же будет реализован расчет "нагрузки на фрагмент" после нелинейных расчетов? Все же это нужно; если бы дело касалось только назначенных связей, но и усилие в сечении, заданного пластинами, иногда требуется определить. Да и для определения опорных реакций вводить одноузловые КЭ это тоже не всегда хорошо.
 
Присоединяюсь к Борисову, действительно нужен читаемый человеком формат данных. Несколько раз приходилось править вручную исходные данные, хотя текстовый формат вполне читаемый, некоторые данные исправляются методом "тыка", так как нет документации на нововведения. Вопрос еще стоит и в архивации исходных данных, по прошествии десяти-пятнадцати лет скорее всего невозможно будет расшифровать закрытые форматы (не помню в какой стране проводился опыт по открытию старых документов - окончился печально). Лира благодаря текстовому формату позволяет расшифровывать данные и переносить в другие программы и версии. Не стоит забывать и про то, что корова государственная, а молоко - наше. Пользователь должен иметь право на то, что производит и должен иметь право использовать свое произведение по собственному усмотрению без привязки к инструменту (проблема художника и кисти - без наличия кисточки которой написана картина художник не увидит своего творения и никому не сможет ее показать). Выходом из положения может быть формат ifs - хотелось бы узнать о нем подробнее. По поводу огромности текстовых файлов - рост размера задач неизмеримо отстает от роста вычислительной мощности.
 
Цитата
Константин Меляйкин пишет:
читаемый человеком формат данных
действительно нужен но если он критически влияет на время расчета то лучше предусмотреть ( создать ) отдельный модуль конвертации основного файла в текстовый.  (ИМХО).
Еслибы все зависело от Бога,то все были бы святыми. Но свобода воли - закон Вселенной.
 
Очень трудоемкой задачей является определение опорных усилий для используемых сечений в ЛирСТК. Особенно если количество используемых сечений несколько десятков.  Казалось бы чего проще - выбрал фильтром нужные сечения и проанализируй на предмет максимума усилий. Но для этого нужно, во-первых, решить набившую оскомину проблему экспорта сечений обратно в Лиру, во вторых, как-то разделить опорные усилия и пролетные. Кстати в Лира-КМ эта проблема тоже не решена - там для всех сечений просто выдаются максимальные усилия, а кому это надо? Чертежи КМ являются основой для разработки КМД и усилия, проставляемые в спецификациях, нужны в первую очередь для проектирования узлов, а не для общего сведения об усилиях в балке. Посему конкретная просьба - сделать в ЛирСТК вывод опорных усилий конструктивных элементов - на экран или в таблицу Excel.
 
Согласен, из цепочки расчета можно исключить, но предусмотреть "страховочную" возможность - чтобы при невозможности открытия файла с закрытыми данными можно было посмотреть, исправить. Желательно создание текстового файла автоматически, не обязательно с учетом последних изменений, наверно при таком варианте возможно создание текстового файла в процессе ввода данных, когда процессор не загружен расчетами. При отдельном модуле конвертации маловероятна, но возможна потеря всей задачи.
Интересно было бы если в процессе ввода данных что-нибудь просчитывалось не мешая работе :)
 
Ещё раз хочу вернуться к армированию до обновления и после обновления Лиры 9.4.
Одина и та же расчетная схема была посчитана до обновления и после: результаты по перемещениям, напряжениям, усилиям и т.д. получаются идентичными, а вот с армированием БЕДА. Во-первых оно получается больше, во-вторых распреление его совершенно не понятно (чуть ли не в шахматном порядке элементы армирует).
Получается Лира считает однинаково, а вот ЛИР-АРМ почему то по разному? В чём подвох?  
P.S. Лира у меня лицензионная.
 
В ЛирВИЗОР и ЛирСТК желательно сделать регулируемый размер отображения шарниров. На планах больших схем, или просто на вытянутых разрезах металлокаркасов, шарниры отображаются настолько большими, что сливаются друг с другом и схемы становятся нечитаемыми. А схемы эти необходимы как для экспертизы, так и для правильного конструирования КМ и КМД.
 Извиняюсь, что встрял в длинную полемику двух предыдущих ораторов :)
 
   Новая версия лирарма действительно выдает на первый взгляд больше арматуры в
кэ оболочек. Это касается элементов расположенных именно в проблемных местах расчетной схемы с пиковыми усилиями и проявляется не всегда.
При неучете трещинообразования результаты для всей массы кэ сопоставимы с предыдущей версией, разница на один шаг расчетной линейки возможна и вполне объяснима грубостью шкалы, при выяснении и сравнении конкретных цифр все близко. При учете трещинобразования, в относительно малом количестве кэ, где усилия явно пиковые, вероятно по новому алгоритму подбора арматуры , что то не уравновешивается и идет безудержное наращивание  количества арматуры.
Может что-то прояснят и подскажут разработчики? Можно  вернуться временно в предыдущий релиз .
А так при учете трещинообразования в пределе придется удалять назначение  материала для проблемных элементов и армировать остающиеся.
 Чтобы сравнить картинки пришлось повозиться с сопоставимостью цветовых линеек.Кажется это уже было на форуме: Окно параметры шкалы , подменю "настройка" ,формульная форма представления, указываем шаг арматуры и давим ок. Строится линейка с подсказкой диаметров при заданном шаге с охватом  ПОЛНОГО диапазона подобранных площадей арматуры. Чем шире диапазон, тем грубее линейка. Просьба разработчикам ввести в данном подменю окошко "предельное значение максимума площади для формирования линейки с подсказками диаметров" задаваемое пользователем. Получим приемлемую рабочую шкалу. Реальный пик останется без подсказки, которая и не нужна. На сегодня можно формировать такую линейку вручную, но она действует разово, хранить в буфере обмена не выход, он постоянно используется.
 Хотелось бы также иметь возможность формировать свои личные фиксированные линейки запоминать и грузить их, как грузим на сегодня материалы. Применение личной линейки принудительное и нужно окошко с галочкой для его приоритета.
 
При написании текстового файла задачи, для уменьшения объема файла желательно активнее использовать повторители.В последних версиях Лиры
они совсем не применяются.
Поддерживаю всех пользователей,которые высказались за сохранение текстового файла.
p.s.
Вопросы к разработчикам по моделированию конструкций желательно задавать в других
темах форума.
В этой теме - только по работе самой программы и ее приложений.
 
 :!: обругаю себя, что вчера написал что с армированием
в последнем релизе все не так плохо.  В контрольном примере знакопеременность назначенная  нагружению в рсу , при просмотре  результатов рсу
(в лирвизоре) проявилась в стержнях, но НЕ обнаружилась в оболочках .  Посмотрите , как с этим у Вас.  Хорошо последний объект закончил на осеннем релизе. Безотносительно к данному факту, в некоторых элементах ранее выполненной  задачи с  монолитными перекрытиями даже без учета трещинообразования несуразно подскочила арматура.

 
  :?: по поводу своего сообщения№111 о проблемах с армированием.
Может я тупой, зря народ беспокою. Поправте если нетрудно.
контрольник: плита 6.6х6.6 м, сетка кэ 0.3х0.3 четыре задвинутые на 0.3 м от граней стойки по углам плиты. Два симметричных отверстия в плите 0.3х3.6 м вдоль оси У на расстоянии 0.3 м от левого и правого торцов плиты. Все полностью симметрично относительно обоих осей.
 два нагружения:
  1--0.680 т/м2 по всей площади плиты,
  2-- четыре соср. силы по 10 т против  оси Х  в узлах соединения плиты со
  стойками
Нагружение№2 в таблице генерации рсу объявлено кратковременным знакопеременным.
Вопрос , почему картина армирования слева и справа от оси -У- симметрии расчетной схемы у ЧАСТИ конечных элементов  разная и разные рсу-сочетания.
(для таких кэ, рсу-сочетаний то две строки,и ловится вилка Мх, а у их визави всего одна строка)
 -  -Если сделать нагружение №1 фиктивным ,оставив прорезы, армирование  симметричное.
 -Если добавить третье нагружение инверсное №2, все идеально для всех  кэ.
 Получается использование галки знакопеременности , это не совсем то же самое , что
наличие двух взимопротивоположных нагружений. Главный вопрос: почему
количество рсу-сочетаний  разное(отсюда разная арматура).
 
Господа, дабы не было путаницы с сообщениями, которые после переноса в другую тему теряют некоторый смысл, просьба в данной теме более не задавать ВОПРОСОВ. Здесь только пожелания.
 
В ЛИР-СТК при расчетах элементов по СНиП предлагаю ввести трассировку расчетов (алгоритм расчета),
как это выполнено при расчетах по Еврокоду и расчетах узлов.
У пользователей появится возможность увидеть реальные напряжения в элементах,
и как они получаются. Да и отчет можно будет сделать более солидным.  
Сторінки: Поперед. 1 ... 3 4 5 6 7 ... 20 Наст.
Читають тему (гостей: 1)