Предложения и замечания Лира 10.4 R2

Постараемся решить эту проблему.

Не очень удобно, что при вызове команды из стека активных, все, которые были выше нее, "удаляются" из стека. Т.е. при редактировании кэ сетки приходится постоянно использовать 2-3 одинаковые команды со своими настройками. И все таки хотелось бы увидеть произвольные нагрузки на архитектурный элемент (нагрузка от стен), иначе работа с арх. элементами теряет свой смысл, т.к. пока единственный вариант- задать как равномернораспределенную нагрузку по линии.

Обращаюсь к Колесниковой Лене.
Есть некоторые проблемы с относительно большеразмерными задачами.

Попробовал подгрузить текущую задачу из САПРа(через текст, 9.4 -- .lir)
(Количество узлов = 350589 ,  количество элементов = 426048, 17 статических нагружений , из них 4 инерционных). Два домика на сваях в массиве линейных солидов.

При конвертации пострадали только жесткости пластин и линейных солидов.
Правим их в 10ке в редакторе сечений. Постоянно выскакивает сообщение что жесткость неверна , не давая выйти в главное окно и поглядеть, к чему относится данный тип.  Хорошо, ставим во все проблемные жесткости пока любую толщину. контроль успокоился. Находим через фильтр элементы относящиеся к проблемным жесткостям и в редакторе правим . Переход в главное окно и в редактор работает быстро и хорошо.
 Но есть пожелание: почему бы не подсветить элементы данного типа жесткости  прямо из редактора жесткостей. То что мы выходим в главное окно, через фильтр выбираем тип  
и выделяем  его элементы  , эта цепочка действий  программируется. А нам в редакторе сечений(аналогично и материалов)маленькую кнопочку «подсветить». Зачем всё делать вручную?

Жесткости отлажены. Аналогично поправили материалы. Запомнили задачу. Пытаемся запустить на счет. Зависание, никакой реакции , протокол не появляется. (процессор что то там считает 13% загрузки).
Остановить не получается. Снял  задачу. Загрузил.  Попробовал запустить упаковку. Зависание. Остановить не дает. (процессор 13% , что то делает). Долго и безрезультатно .  Понятно , что что то не так.  Решил попробовать с другого конца. Загрузил небольшой расчет(110696 ,159578 кэ)
Все нормально.  пытаюсь увеличить задачу копируя схему целиком. Тут проблемы.
Ругается, таблицы выдает, кейс, буфер, чтение-запись… Ясно. Копируем кусками,
все нормально. Упаковываем, ругается аналогичными таблицами претензий, но делает. Пускаем на счет, считает двойную схему.  Хорошо. Понятно что при   работе со схемой  объемы имеют значение.
 Сейчас мы под ХР ( комп i7) . то ли в программе в настройках кейсы, буферы  невелики, то ли памяти винда сколько кто хочет дать не может. в 9.4 и в 9.6 таких проблем не было,
вообще.  все работало за счет подкачки,  медленнее , но  безотказно.  Этот принцип должен сохраняться.  
  Вернулись к большой задачке. В ней под этим соусом под подозрением нагрузки.
Там 4 статических инерционных нагружения , по три нагрузки на узел(даже не по 6).
 Заходим в редактор нагружений. Пробуем удалить нагружение начав с последнего.
Программа вылетает.  Хорошо, тогда иначе. Заходим в нужное нагружение и в редакторе назначения нагрузок выполняем удаление всех нагрузок. Это мгновенно. Удалив 3 из 4х
инерционных нагружения добились выхода на счет. Упаковка опять ругается. Типа проверь всё. Игнорируем. Пусть посчитает.  Сосчитано  и даже быстро 69 мин. По протоколу нагрузки совпадают с оригиналом. Ну наверное и остальное тоже. Не стал проверять(перемещения , хотя это и  обязательное) . главное считает и быстро.
САПР просчитал за 46 минут, но под W-7-64.  так что у 10ки из под ХР вышло очень  неплохо.
  Что делать, если нагружений много? Ну есть конденсация масс,  можно резко уменьшить аппетиты на формы и их наполнение , при переводе в инерционные нагрузки это решающий момент.

Это на сегодня.
Пожелание на завтра:
увеличить что то в настройках , чтоб 10ка кушала любые объемы элементов, жесткостей, нагрузок, и тп.   Или обозначить их предельные цифры под ХР. Или указать какой RAM желателен для данного класса задач(узлов столько то, элементов столько то…, но тогда это W-7,8 64 бита разумеется).
   Такой казус был например с ing+2010, в том же году. 29 нагружений и гибель Титаника, но посоветовали поставить под 64бита и навесить приличный для него объем RAM.
Всё разрешилось.
Имхо , все же  универсальным должен быть случай, когда программа считает всё и всегда под любой операционкой за счет дисковой памяти и обмена с оперативкой. Раньше то так и было. И это концептуально правильно.
  Попробовал проармировать, всё ничего, достаточно быстро. Но с оформлением ,с гибкостью шкалы, тут пробел. Иван Иванович это раньше отметил. Для практики нужна полная свобода с цветами , количеством  диапазонов и их цифровым наполнением.  Чтобы работать по принципу : фоновое (базовое) армирование+подсвеченное дополнительное армирование с нужной степенью дискретизации. Тут эталон САПР. То есть информация на поверхности.
 Последнее. Лена вы обещаете двусторонний обмен с 9.6 через прежний текстовый формат. Это хорошо. Но чтоб не лукавить, уточню, что имею в виду  Лиру САПР.
   Текстовый формат абсолютно универсален. Что можно передать, передаем, чему нет соответствия . опускаем.  Опять же имхо, САПР вывел лиру2013 в открытый доступ. Вопрос всякого лома под любым « благовидным» предлогом отпал на корню .
  Фриварка+старли решают основные проблемы конвертации  в реально распространенные комплексы. Это выгодно и Вам. Учиться лучше на реальных задачах. Расчеты делаем немедленно, экономим время на создании моделей,  и акцентируемся на том , что у кого лучше реализовано на выходе. При таком подходе любой интерфейс осваивается немедленно, разве что  с другого конца , с корректуры. А там на автомате  становится понятно что к чему.  
  Еще по интерфейсу. Сечение-отсечение. Нужно таки указать от одной до трех цифр координат. То есть идти в «очки» ткнуть в нужное место, забить в мозг цифру и воспроизвести  ее в инструменте сечение-отсечение. Если ничего не трогать, то и эта цепочка программируется. В очках – кнопочку копировать координату  в буфер. В инструменте Сечение правой клавишей можно вставить из буфера.
Если это ортогоналка, то все примитивно. Если произвольная плоскость , то вам подумать, чтоб всегда в буфер копировались все три координаты, а в приемнике автоматом выбиралась нужная. Тоже просто. Как уже отмечалось у И.И , Очки лучше бы работали с прочим инструментарием параллельно(это на будущее. И  потихоньку вернуть оправдавшие себя старые ценности, в том числе и копирование за два узла с параллельным масштабированием . это фишка самая универсальная при построениях).
 Приношу извинения за много буков. Но хочу быть понятым. Поэтому так подробно.
C уважением.
Андрей.

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