nikcher (Всі повідомлення користувача)

Форум пользователей программных комплексов ЛИРА-САПР, МОНОМАХ-САПР, САПФИР-3D, ЭСПРИ

У зв'язку з великою кількістю неіснуючих підписок на оновлення форуму була проведена очистка. Якщо ви перестали отримувати повідомлення з оновленнями, прохання провести підписку знову.
Вибрати дату в календаріВибрати дату в календарі

Сторінки: Поперед. 1 2 3 Наст.
[ Закрито] Пожелания официальных пользователей, Тема для обсуждения новшеств необходимых по мнению пользователей
 
Надо бы отработать процесс сохранения настроенных сечений в ЛирСТК. Хотя бы для случая когда не изменяется список сечений. Сейчас при передаче из Лиры передается только часть характеристик сечения, остальные (марка стали, характеристики элемента и пр.) доназначается в ЛирСТК. Забивать их для полусотни сечений каждый раз после корректировки схемы в Лире тоже проблема, чреватая большим количеством ошибок. Мне кажется и здесь можно дать возможность вводить их еще в Лире (как опцию), что даст возможность наладить и полноценный обмен между Лирой и ЛирСТК и обратно характеристиками сечений.  
[ Закрито] Пожелания официальных пользователей, Тема для обсуждения новшеств необходимых по мнению пользователей
 
Думаю давно назрела необходимость задавать и передавать конструктивные элементы в цепочке Мономах-Лира-ЛирСТК-Лира, также как передаются характеристики сечений. Во-первых информация о конструктивных элементах, заданная в Мономахе не терялась бы в Лире, во-вторых при изменениях расчетной схемы в Лире (после расчета в ЛирСТК) не пришлось бы по-новой создавать эти элементы в ЛирСТК - это ведь очень трудоемкий процесс и для больших схем требует не один день, а схемы изменять приходится регулярно.
Пожелания и предложения пользователей
 
Предлагаю в окне "Выбрать элементы по критериям" - "Где искать" добавить возможность указать с какого по какой этаж осуществлять выбор элементов. Для многоэтажных зданий существенно облегчило бы корректировку расчетной схемы.
[ Закрито] Пожелания официальных пользователей, Тема для обсуждения новшеств необходимых по мнению пользователей
 
Вот если бы появилась утилита для пакетного расчета. Забил в утилиту какой надо запустить модуль (Лир-Визор, Лир-АРМ или Лир-СТК), указал перечень файлов для просчета и запустил на ночь. Утром - туча просчитанных вариантов. Красота :)  
Экспорт усилий в ФОК, Неправильно экспортируются усилия в ФОК
 
  Тут пришла еще мысль, но не успел до Вашего сообщения - отвлекли тут немножко. Можно ведь просто в экспорте добавить кнопочку - экспорт по локальным или глобальным осям. Собственно тогда все вопросы будут сняты: для замороченных случаев, когда фундаменты по кругу или под несколькими углами - экспорт по локальным осям, которые надо специально выставлять и затем повторить их поворот на плане ФОК ; для случаев попроще, но которые как правило и составляют 90% работы - экспорт по глобальным осям без каких либо подготовок, корректировок и дальнейших заморочек в ФОК.
Экспорт усилий в ФОК, Неправильно экспортируются усилия в ФОК
 
Согласен, что если подойти к этому вопросу с этой стороны, т.е. а правильно ли экспортируются усилия со стежней с локальными осями в ФОК, то формально ответ да. Но для конкретного пользователя гораздо важнее другое - создал 4 колонны, их не поворачивал , но получил 4 разных сочетания нагрузок от этих колонн за счет перекрученных местных осей.
Опять-таки по поводу
Цитата
Программа не знает, задал ли оператор поворот осей
обращаю внимание на то, что ни одну колонну или ось я не поворачивал, т.е. оператор тут ни при чем - это исключительно некорректности Мономаха и особенности Лиры.
Именно поэтому я и говорил о необходимости экспорта в глобальной системе координат. Сейчас экспорт в ФОК сделан так как-будто ФОК может воспринять этот поворот местных осей относительно вертикали. Но в ФОК эта информация не передается В результате имеем перепутанные усилия. Сейчас для того чтобы пользоваться экспортом нужно предварительно все местные оси колонн развернуть в нужном направлении и только после этого возможен корректный экспорт.
Честно говоря мне наша дискуссия напоминает Райкинскую миниатюру: "... к пуговицам притензии есть" Действительно к пуговицам притензий нет и сшито крепко, но костюм кривоват. Больше того я за время этой дискуссии попросил сына и он за несколько дней написал отличный конвертор и оси не путаются, и ограничений на 30 фундаментов нет, и задавать свои данные для типового фундамента можно и т.д. и т.п. Сделан конвертор на основе экселевского файла нагрузок на опорные точки расчетной схемы.
Посему, я так понимаю, тема исчерпана, причем каждый остался при своем мнении :)

Экспорт усилий в ФОК, Неправильно экспортируются усилия в ФОК
 
Вот лировский файл
Экспорт усилий в ФОК, Неправильно экспортируются усилия в ФОК
 
 Вот сделал еще одну иллюстрацию проблемы. На рисунке все стержни получены при использовании настроек по умолчанию (т.е специально колонны не поворачивались) первые два стержня экспортированы из Мономаха (№1 строго вертикален, №2 с небольшим отклонением по вертикали), №3 создан в Лире при генерации рамы и №4 - тот же стержень с небольшим отклонением по вертикали. Все стержни выбираются инструментом "Отметка вертикальных элементов", т.е. опознаются Лирой как вертикальные.
Теперь как обычно строится каркас: строим в Мономахе простенький каркас с прямоугольной сеткой осей, экспортируем в Лиру, добавляем пару колонн и после этого вполне можем получить весь набор колонн, приведенный на рисунке. И теперь по этим локальным осям получим экспорт нагрузок в ФОК. У кого повернется язык назвать такой экспорт корректным?
В прицепе рисунок и лировский файл с этими стержнями.
Экспорт усилий в ФОК, Неправильно экспортируются усилия в ФОК
 
Цитата
Ориентация фундамента и сечение колонны должны согласовываться
C этим никто не спорит. Более того так как на картинке в посте 6 колонны не разворачивает - поворот составляет 90 градусов. Это отлично видно в файле металлического каркаса, который я Вам недавно посылал и который также как и обсуждаемый здесь каркас был сделан сначала в Мономахе и затем экспортирован в Лиру. В ФОК не расчитываются колонны повернутые относительно фундамента. Если нужно повернуть фундамент относительно вертикальной оси - это делается на плане фундаментов, т.е  физически в другом файле ФОК, который не экспортируется из Лиры.
По правилам Лиры и ФОК глобальные оси на плане располагаются так: по горизонтали X, по вертикали Y.
Теперь что мы имеем с локальными осями стержней (колонн) в Лире, если схема получена из Мономаха - см. картинку в прицепе. Здесь локальная ось стежня Y направлена вдоль оси X, а локальная ось Z - вдоль оси Y. В результате при экспорте из Лиры в ФОК усилия Qy (в ФОК это -Qy)- направлены вдоль глобальной оси X, а Qz (в ФОК - это -Qx)- вдоль глобальной оси Y. Тот же расклад и с моментами. Отсюда и все проблемы с экспортом в ФОК.
Не знаю насколько получилось пояснение, но именно поэтому я и предлагал не теоретизировать, а взять ручками для первого фундамента (первого опорного узла, а не узла стержня в местной системе координат) в предлагаемом каркасе вывести на экран нагрузки от РСН  и заполнить первую строчку нагрузок в файле ФОК. Сравнить с аналогичной строкой в файле экспорта Лиры, ну и сделать выводы про криминал и пр.
Экспорт усилий в ФОК, Неправильно экспортируются усилия в ФОК
 
Я поступил так, чтобы проблема стала абсолютно очевидна, а именно:
1. В ЛИР-ВИЗОР сделал расчет нагрузок на опорные узлы от РСН.
2. Вывел на экран усилия на фрагмент - для одного опорного узла (например для узла 1) и глядя на экран заполнил таблицу ФОК. Так вот при таком заполнении результат отличается от того, который выдается Лирой при экспорте этих же нагрузок в ФОК.
Проблема неправильного экспорта, я так думаю, в том, что при экспорте из Лиры нагрузки определяются на основе местной системы координат стержней (о чем так красноречиво свидетельствует картинка в посте 4), в то время как нагрузки на фундаменты надо собирать в глобальной системе координат. Следовательно как только местные оси стержней (колонн) развернуты относительно глобальных осей - Лира будет выдавать неправильный экспорт. Формулы которые я привел в посте 1 справедливы именно для нагрузок на опорные узлы в глобальной системе координат - что исключает такие проколы.
Кстати при существующем экспорте, наверное, проявится и та проблема, что для строго вертикальных и наклонных стержней угол поворота местных осей вычисляется по-разному (на форуме кто-то из разработчиков уже упоминал об этом). Поскольку при экспорте из Мономаха достаточно часто в Лиру приходят не строго вертикальные колонны (о чем я уже говорил на форуме), но которые все же выделяются инструментом II, то в результате имеем хорошо замаскированную и плохо предсказуемую основу для неправильного экспорта в ФОК нагрузок на фундаменты от этих колонн.
Задачу и весь пояснительный материал повторно отослал. Жаль что здесь на форуме очень жесткое ограничение на размер прикрепляемого файла - приходится слать на мыло - послать, то послал, а получили или нет узнать непросто :(  о чем свидетельствует анализ поста 2 и поста  4.
[ Закрито] Пожелания официальных пользователей, Тема для обсуждения новшеств необходимых по мнению пользователей
 
Мне кажется очень актуальным вопрос о плагинах для Лиры. Суть в следующем: в каждом новом релизе много нововведений (а требуется еще больше), но эти нововведения понятное дело чаще всего сыроваты (глюковаты). Однако исправить эти глюки - жди следующего релиза, когда наберется достаточное количество исправлений или появится что-то фундаментальное (типа модуля Грунт). А был бы механизм подключения плагинов - можно было бы сделать плагин для какой-то функции и несколько кругов нарезать по отработке этого плагина, а когда он созреет, то уже включать в основную поставку. По-моему вполне могли бы быть плагинами:
1. Экспорт-импорт файла жесткостей между ЛИР-ВИЗОР и ЛирАРМ/ЛирСТК.
2. Экспорт нагрузок на фундаменты в ФОК - тот, что есть сегодня - не выдерживает никакой критики.
3. Назначение цветовой группы диапазону армирования с жестким соответсвием цвета определенному армированию (тема обсуждалась на одном из семинаров)
ну и т.д.
Кроме уже описанных аргументов важно и то, что можно было бы подключать усилия сторонних программистов для создания таких плагинов - они ведь реализуют сервисные функции и для создания плагинов не надо лезть в математику программного комплекса. Лира стала бы развиваться не линейно-последовательно (от релиза к релизу), а параллельно по многим направлениям.
Номер сообщения
 
Админ погладил по шерсти, а не против - приятноооо! Еще раз убеждает, что данный форум для пользователей!
Номер сообщения
 
C администратором спорить - это как ... ладно воздержусь от аналогий :) Это не мое изобретение, но считаю его очень удобным в следующих случаях:
1. Форум набирает обороты и сейчас будут появляться темы с большим количеством страниц, соответственно иногда удобно не цитировать несколько сообщений, а просто указать номера сообщений в виде гиперссылки - кому интересно - пошел углубился, неинтересно - сообщение с такими ссылками совсем коротенькое и не забивает сраницу лишней информацией, что облегчает чтение. Свобода выбора - это свобода!
2. Темы, затрагиваемые на форуме, обсуждаются параллельно не только здесь, но и на других форумах. Согласитесь, что неудобно вновь прибывшему сюда шерстить даже эти 5 страниц, чтобы найти нужное сообщение, вместо того чтобы попасть сразу в нужное место.
Понятное дело это мое личное видение  - так мне удобно.
Резервное копирование и архивирование данных Лиры
 
Как рационально организовать резервное копирование и архивирование данных Лиры. Что сохранять, чтобы гарантированно можно было воспроизвести результаты расчета спустя энное количество времени, но архив был при этом минимальных размеров? При условии что Лира в полной комплектации.  Я так понимаю, что в список попадают все файлы (не папки!) в папке Lira 9.4 и содержимое папки LData. Или нужно еще что-то из папки LWork? Есть какие-то рекомендации на эту тему?
Тот же вопрос актуален для Мономаха.
Составные сечения из листового проката
 
Озаботился проверкой листового сортамента на предмет соответсвия ширины и толщины листа наименованию листа в сортаменте и уд. массе . Хотел проверить не наделал ли я ошибок при дополнении сортамента (см предыдущее сообщение п.2). Оказалось там уже и до меня постарались:
1. В сортаменте LIST2-25 и LIST2-25S для следующих листов проставлена неверная уд. масса (в скобках указаны правильные цифры)
-450 x 10  36.33 (35.325)
-500 x 25  58.88 (98.125)
-630 x 8   50.4 (39.564)
-630 x 25  157.5 (123.6375)
Лист с наименованием -1000 x 6 имеет характеристики h=1000 t=10 и уд. массу 78.5
2. В сортаменте LIST20- и LIST20-S для следующих листов проставлена неверная уд. масса (в скобках указаны правильные цифры)
-500 x 25 58.88 (98.125)
-630 x 25 157.5 (123.6375)
Ошибки указаны для файлов поставляемых с Лирой. Проверку выполнил с помощью экселевской таблички - будет интересно - выложу.
Составные сечения из листового проката
 
Предлагаю
1. в ЛИР-СТК (Лире) доработать окно редактирования стального сечения таким образом, чтобы при редактировании составных сечений, содержащих стальной лист, можно было бы вводить требуемые ширину и толщину листа непосредственно в окне редактирования стального сечения, при этом лист автоматически сохранялся бы в выбранный сортамент. Сейчас для того чтобы изменить толщину или ширину листа (при отсутствии такого размера в сортаменте) нужно больше десятка кнопок нажать, а ведь подбор нужных листов делается перебором вариантов!
2. В сортаменте листового проката вполне достаточно оставить для ввода данных только два параметра - ширина и толщина листа. Остальные параметры - наименование и уд. масса надо или вообще убрать, или сделать, чтобы было заполнение по умолчанию в зависимости от введенных ширины и толщины. Сейчас кроме очевидного неудобства ввода (дублирование информации и необходимость дополнительного вычисления уд. массы) очень велика вероятность ошибки - выбор листа в окне редактирования стального сечения делается по наименованию, а жесткой связи между наименованием листа  и размерами этого листа в сортаменте нет, т.е. ничего не мешает в сортаменте листового проката назвать лист 200 x 10 с шириной 2000 и толщиной 100, или присвоить листу неправильно вычисленную уд. массу. С учетом описанного в п.1 подбирать составные сечения приходится очень долго, да еще и результат может оказаться с подвохом :(
Экспорт усилий в ФОК, Неправильно экспортируются усилия в ФОК
 
Что-то не вызывает отклика проблема :( Послал в техподдержку на мыло файл Лиры с которого были получены нагрузки на узлы и файл экспорта в ФОК -  сюда прицепить невозможно из-за размера (800 кб).
Экспорт усилий в ФОК, Неправильно экспортируются усилия в ФОК
 
Неправильно экспортируются усилия из Лиры в ФОК. Сейчас усилия передаются по схеме Mx ФОК = Mx Лира , Qx ФОК = -Py Лира, My ФОК = My Лира, Qy ФОК = Px Лира, а надо, учитывая, что в ФОК другие направления усилий, Mx ФОК = -My Лира, Qx ФОК = -Px Лира, My ФОК = Mx Лира, Qy ФОК = -Py Лира. В прицепе картинка с правилом знаков из хелпа ФОК, нагрузки на опорные узлы расчетной схемы и экспорт в ФОК для этой же схемы.
Файл материалов в ЛИР-АРМ
 
Переустановил еще раз Лиру, хотя у меня и так стояла майская версия. Файл материалов по прежнему корректно импортируется только в тот файл ЛИР-АРМ, в котором был создан, а во вновь экспортированный из Лиры файл материалов импортироваться не хочет. К Вам на мыло послал файл с видеозахватом "смоделированного" процесса импорта материалов (файл примерно 1.5 мб)
Номер сообщения
 
В сообщениях нужна нумерация. Сейчас вот хотел  сослаться на сообщение, а номера-то и нет :)
Сторінки: Поперед. 1 2 3 Наст.