Ansys для проектировщика КЖ-КМ

[Fedor 1,678]

"Как в DOS были графические пакеты" там удобнее было писать прямо в видеопамять :) 

[ДОБРЯК 616]

12 часов назад, Fedor сказал:

Direct похож на Open GL

Я вижу, что вы хорошо знаете Open GL и Direct X. Подскажите как в  Open GL работать с матрицами?

 

[Fedor 1,678]

Да я интересовался этой графикой лет двадцать тридцать назад. Где-то была статься в которой сравнивалась Direct и Open GL . И указывалась эквивалентность функций...  Давно это было, подзабылось :) 

 

https://habr.com/ru/articles/79257/   

Цитата

Общим для двух API является то, что обе не предоставляют чего либо за пределами работы с графикой. А именно, нет функций ни для создания окна, ни для работы с вводом с клавиатуры/мыши, ни для работы со звуком (здесь я не затрагиваю другие части DirectX, такие как DirectInput и DirectSound). Т.е. они не являются библиотеками высокого уровня.

Когда-то смутила сложность работы с мышью и клавиатурой ...  Поэтому и вернулся к GDI 

Edited September 8, 2025 by Fedor

[Fedor 1,678]

https://coollib.in/b/502702-yu-tihomirov-programmirovanie-trehmernoy-grafiki-opengl/read    Вот тут есть о графике 

 

[Chardash 313]

Немного добавлю:  в новых версиях OpenGL, если не хочется писать матрицы трансформаций вручную, используйте GLM https://github.com/g-truc/glm : glm::rotate - это замена glRotate (с виду почти тоже самое, но теперь управляет программист).

#include <glm/glm.hpp>
#include <glm/gtc/type_ptr.hpp>
#include <glm/gtc/matrix_transform.hpp>
  
glm::mat4 m(1.0f)
glm::transpose(mat4) транспонирует матрицу
  
// glm::translate(...),  glm::scale(...) ...

11 часов назад, Fedor сказал:

Когда-то смутила сложность работы с мышью и клавиатурой ...  Поэтому и вернулся к GDI 

 

11 часов назад, Fedor сказал:

 

нет функций ни для создания окна

 

Возможно, Вы не рассматривали SDL2 или SDL3? Это открытая и кроссплатформенная библиотека: можно  создать окно с контекстом OpenGL, есть простой доступ к клавиатуре, мыши, геймпадам, не мешает использовать OpenGL/Vulkan напрямую. И не нужно концентрироваться на деталях WinAPI.

 

И кстати, если Вы хотите добавить интерфейс к OpenGL проекту, взгляните на Dear ImGui. Он не заменяет SDL или GLFW "бэкенды", но работает с ними. Примеры: https://github.com/ocornut/imgui/tree/master/examples

imgui_impl_sdl2(3).cpp — поддержка ввода от SDL2
imgui_impl_opengl3.cpp — рендеринг через OpenGL

 

 

 

Практически самостоятельно разбирался с WinAPI (ниже пример) и Qt больше 5 лет назад, но бросил - было сложно и перешел на Python. Несколько месяцев назад вернулся к С++: вспоминаю графику, изучаю современные методы. ps Спасибо за книгу - отлично помогла освежить основы.

[Fedor 1,678]

 

 

ИИ полезная вещь. Посмотрел как последовательно теория обобщенных функций работает в грунтах и железобетоне. Чудесно объясняет... 

[Fedor 1,678]

https://www.youtube.com/shorts/RQCHCJnur0o?feature=share   Нет ли у кого чертежей такого соединения ?  

Что-то подобное хотел придумать, да уперся в то, что никто не готов был изготавливать образцы...  А корейцы молодцы :)

Edited March 6 by Fedor

[jtok 1,033]

Чертежей нет. Вот тут разрезик есть https://www.form-scaffs.com/rebar-coupler/one-touch-rebar-coupler-for-concrete-construction-rebar-splicing-coupler.html

[Fedor 1,678]

Спасибо. Принцип работы понятен. Что то похожее хотел сделать и где-то здесь размещал чертежик. Меня все к кому обращался убеждали что такое невозможно. А корейцы сделали и показали, что возможно и нужно.  

Позволяет экономить до 20%  арматуры, стыковать разные диаметры. Делать и угловые стыкователи. 

 

https://www.form-scaffs.com/rebar-coupler/one-touch-rebar-coupler-for-concrete-construction-rebar-splicing-coupler.html

Edited March 8 by Fedor

[Fedor 1,678]

Вот что советует ИИ 

Цитата

Для самозаклинивающихся цанговых муфт типа One Touch угол конуса (заклинивания) обычно составляет от 5° до 7° относительно оси арматуры.
 Этот диапазон обеспечивает надежный самозахват при нагрузке и предотвращает проскальзывание арматуры.
 
Вот основные технические моменты, которые определяют этот выбор:
Условие самоторможения: Угол должен быть меньше угла трения стали по стали, чтобы муфта не «выстрелила» под нагрузкой.
Эффект заклинивания: При угле 5–7° создается оптимальное осевое усилие, которое вдавливает зубья цанги в ребра арматуры.
Пятно контакта: Слишком острый угол (менее 5°) может привести к заклиниванию самой муфты «намертво» без возможности регулировки.
Распределение напряжений: Угол в 6° (среднее значение) лучше всего

Для готовых систем типа One Touch выбор конкретного изделия зависит от диаметра арматуры и требуемого класса нагрузки.

Поскольку угол заклинивания уже задан производителем в конструкции, при подборе готового решения ориентируйтесь на следующие параметры:

• Диаметр арматуры: Муфты One Touch обычно выпускаются под конкретные размеры (от 12 до 40 мм) и не являются универсальными.
• Тип проката: Проверьте совместимость с вашим классом арматуры (например, А400, А500С), так как форма серповидного или кольцевого ребра влияет на сцепление.
• Класс соединения: Убедитесь, что муфта соответствует категории Service Splice (стандарт) или Full Mechanical Connection (на полную прочность стержня).
• Наличие сертификата: Для самозаклинивающихся систем критически важны протоколы испытаний на растяжение и циклическую нагрузку.
• Индикатор фиксации: В качественных «ван-тач» муфтах есть визуальный контроль (пластиковое кольцо или щелчок), подтверждающий, что арматура зашла на нужную глубину.

:)

Edited March 10 by Fedor

[Fedor 1,678]

[Fedor 1,678]

Я чертил 3 градуса от оси, а можно оказывается 6 градусов .  Тогда совсем просто проектировать узел... 

[Fedor 1,678]

 

 

А на схеме у них 11 градусов от оси.   Что-то противоречит тому что пишет ИИ... 

[Fedor 1,678]

Цитата

Лучшее решение — трехсегментный клиновой захват (по типу цанг для преднапряженного бетона).

 

1. Геометрия клиньев

• Угол клина: Оптимально 6–7 градусов на сторону. При таком угле осевое усилие в 15 тонн создаст радиальное давление прижима около 50–60 тонн.
• Длина контакта: Чтобы не смять и не срезать рифление арматуры, длина клиньев должна быть не менее 80–100 мм.
• Сегментация: Клин должен состоять из 3 частей. Это обеспечит центровку и равномерный обхват «неидеального» прута.

 

2. Требования к материалам

• Клинья: Сталь 20Х или 12ХН3А с цементацией и закалкой до 58–62 HRC. Зубья должны быть острыми (шаг 1.5–2 мм, глубина 0.8 мм), чтобы врезаться в металл арматуры.
• Корпус (обойма): Должен быть массивным, чтобы выдержать колоссальное давление на разрыв. Используйте сталь 40Х или 45 с улучшением (закалка до 35–40 HRC).

 

3. Расчет корпуса (обоймы)

При осевой силе 

null

 

 кН и угле 

null

 

:

• Радиальная сила (
  null

   
  ): составит примерно 
  null

   
   кН (120 тонн).
• Толщина стенки: Внешний диаметр корпуса должен быть в 2.5–3 раза больше диаметра арматуры. Если арматура 14 мм, диаметр корпуса должен быть не менее 45–50 мм.

 

4. Критически важные нюансы

• Смазка: Наружную поверхность клиньев (которая касается корпуса) нужно обязательно смазать графитовой смазкой. Это снизит потери на трение «клин-корпус» и направит всю силу на сжатие арматуры.
• Предварительный зажим: Чтобы система сработала, клинья нужно слегка поджать в начале (пружиной или легким ударом), иначе при подаче нагрузки они могут проскользнуть.

ИИ хорошо помогает проектировать, дает дельные советы... :) 

Цитата

Для проектирования цангового зажима на 15 тонн (150 кН) необходимо использовать схему с отдельными клиньями в массивном корпусе. Стандартная тонкостенная цанга здесь не подойдет — её просто разорвет или деформирует.

Ниже приведены ключевые параметры проектирования:

 

1. Геометрия клинового узла

• Угол конуса (
  null

   
  ): Принимайте 6° (на сторону). Это «золотая середина»: угол достаточно мал для самозаклинивания, но позволяет извлечь арматуру после снятия нагрузки (с помощью удара).
• Количество сегментов: Строго 3 клина. Двухсегментные клинья сплющивают арматуру, превращая её в эллипс, что ведет к проскальзыванию.
• Длина клина (
  null

   
  ): Для 15 тонн длина зоны контакта должна быть 90–110 мм. Это распределит давление и предотвратит срезание выступов рифления арматуры.

 

2. Внутренний профиль (зубья)

Поскольку арматура имеет переменный профиль и высокую твердость:

• Резьбовой профиль: Внутри клиньев нарезается «упорная» острая резьба с шагом 1.5–2 мм.
• Твердость: Клинья должны пройти химико-термическую обработку (цементацию) до твердости 58–62 HRC. Зубья должны быть способны «вгрызаться» в арматуру класса А500С.

 

3. Расчет корпуса (обоймы)

Корпус работает на разрыв (радиальный распор).

• Материал: Сталь 40Х или 45 с закалкой до 32–38 HRC.
• Толщина стенки: При 15 тоннах осевой нагрузки радиальное давление будет огромным.
  • Пример: Если диаметр арматуры 14 мм, то внешний диаметр корпуса должен быть не менее 60–65 мм.
• Чистота поверхности: Внутренний конус корпуса должен быть отшлифован (
  null

   
   0.8–1.6).

 

4. Сборка и работа (Важные детали)

• Смазка: Обязательно нанесите графитовую смазку или смазку с дисульфидом молибдена (
  null

   
  ) на внешнюю сторону клиньев. Это критично: клин должен скользить по корпусу, чтобы эффективно сжимать арматуру.
• Пружинное стопорение: В торце клиньев рекомендуется поставить общую прижимную пружину. Она обеспечит «начальный закус», без которого заклинивание может не начаться при быстром рывке.
• Уплотнительное кольцо: Чтобы сегменты клиньев не рассыпались, их обычно удерживают вместе резиновым кольцом в специальной канавке на внешней поверхности.

 

Проверочный расчет (упрощенно)

Сила радиального сжатия 

null

 

 вычисляется как:

null

 

Где 

null

 

 кН, 

null

 

, 

null

 

 — угол трения на внешней стороне клина (

null

 

 со смазкой).
Ваш зажим создаст около 80–100 тонн радиального давления. Этого более чем достаточно для удержания арматуры «намертво».

Под какой конкретный диаметр арматуры (например, 12, 14, 16 мм) вы делаете расчет? От этого зависит диаметр проходного отверстия.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

[Chardash 313]

09.02.2026 в 15:55, Fedor сказал:

ИИ полезная вещь. Посмотрел как последовательно теория обобщенных функций работает в грунтах и железобетоне. Чудесно объясняет... 

Федор, попробуйте ИИ Spec-Driven подходы, еще приятней удивитесь (скорее всего). Например, BMAD

Скоро инженеры сами напишут себе свои ANSYS и ABAQUS

Или, как главный разработчик Claude говорит, софт станет бесплатным, тк его будут писать все.

Edited March 11 by Chardash

[Chardash 313]

BMAD (spec‑driven, через чёткие роли и артефакты) инженеру полезен как способ заставить ИИ работать по инженерным правилам, а не «программировать за вас».

Что такое BMAD простыми словами

BMAD — это не про «магический ИИ, который всё делает сам», а про процесс: вы пошагово превращаете задачу в спецификацию, а ИИ на каждом шаге помогает уточнять требования, находить дырки и фиксировать решения.
Итог — вместо «болтовни с чатом» у вас получается связка документов: постановка задачи, допущения, критерии проверки, список шагов, которые может исполнять уже и человек, и скрипты, и другие ИИ‑инструменты.

Почему это важно именно инженеру (ПГС, расчёт, FEM)

Инженер отвечает не за код, а за безопасность конструкции, соответствие нормам и трассировку решений — это чисто спецификационная работа. BMAD даёт каркас, как вместе с ИИ:

• Выписать исходные данные и допущения для расчёта (нагрузки, комбинации, схемы закрепления, классы бетона/стали) так, чтобы их можно было проверить коллегой, заказчиком, экспертизой.

• Развернуть «мутную» задачу заказчика («надо усилить перекрытие») в набор формализованных сценариев: какие варианты усиления рассматриваем, по каким критериям сравниваем (несущая способность, деформации, стоимость, технологичность).

• Сразу связывать 3D/BIM‑модель, расчётную модель и спецификации (BOM/BIM) через единый словарь терминов и атрибутов — то, чего как раз не хватает в стройке и что сегодня часто делается вручную в Excel.

То есть вы используете ИИ не как «генератор отчёта», а как ассистента по систематизации инженерной логики.

Примеры использования в ПГС и CAE (ANSYS/Abaqus)

1. Постановка расчётного кейса

   • Описываете на естественном языке: тип конструкции, пролёты, опирания, загружения, ограничения по прогибам и трещиностойкости.

   • В стиле BMAD просите ИИ: сначала собрать список исходных данных и неизвестных, затем предложить структуру расчётной модели (какие элементы, какие типы КЭ, какие упрощения допустимы), затем оформить это как формальный «спек» для расчёта (шаблон задания или чек‑лист).

   • Результат: у вас есть проверяемый документ «Задание на расчёт», который можно показать главному инженеру до того, как вы вообще открыли ANSYS/Abaqus.

2. Подготовка и проверка модели

   • ИИ по BMAD‑подходу не «строит модель», а ведёт вас по шагам: сетка, граничные условия, нагрузки, вариации сочетаний, критерии сходимости и проверки.

   • Вы можете просить: «Сделай мне список типичных ошибок для такой схемы и чек‑лист, что проверить перед запуском» — и добавляете этот чек‑лист в свой процесс.

   • На больших проектах это снижает риск того, что вы неделями гоняете расчёты с фундаментальной ошибкой в схеме.

3. Связка BIM ↔ расчёт ↔ спецификация

   • BMAD‑мышление хорошо ложится на ту же проблему, что обсуждают в контексте BIM/BOM: разрозненные данные, ручные связи между CAD, ERP, расчётными моделями.

   • Вы можете договориться с ИИ о «языке проекта»: как называются элементы, как мы кодируем типы нагрузок, где хранится истина по сечениям и материалам.

   • ИИ помогает вам генерировать/обновлять табличные представления (условно: «паспорт элемента»), на основе которых уже проще синхронизировать Revit/Tekla, расчёт и смету.

Чем это отличается от «программистской» выгоды

Разработчик в BMAD выигрывает за счёт того, что код пишется по хорошему ТЗ и меньше «халлюцинаций» в логике.
Инженер выигрывает в другом:

• Снижение риска: каждое допущение и шаг расчёта проговариваются и фиксируются, а не живут «в голове» или в устной договорённости.

• Повторяемость: один раз отработанный спек на расчёт узла, серии ферм, площадки или типового узла можно быстро адаптировать на следующий объект.

• Прозрачность для экспертизы: вы можете показать не только итоговый отчёт из ANSYS/Abaqus, но и структуру логики: какие сценарии рассматривались, почему выбрано такое армирование/сечение.

Как «сразу завтра» попробовать

• Выберите одну типовую задачу: расчёт балки, фундамента, рамной схемы или проверка существующей конструкции.

• Вместо того, чтобы сразу лезть в расчёт, сядьте с ИИ и прогоните цепочку: «уточни задачу → собери исходные данные → сформируй список допущений → предложи структуру расчёта → сделай чек‑лист проверки».

• Сохраните это как текстовый спек и используйте при следующих похожих задачах, постепенно допиливая под стандарты вашего отдела.

Так BMAD превращается для инженера не в модный ИИ‑хак, а в способ дисциплинировать собственное инженерное мышление и обернуть его в повторяемый процесс с подсказками ИИ.
 

Цитата

надо свои скилс писать, с базовыми скиллами в BMAD нельзя работать?

 

Можно работать и с «базовыми» скиллами — они для этого и придуманы. Но чем лучше вы понимаете свою предметку (ПГС, расчёты, ANSYS/Abaqus), тем полезнее для вас становится BMAD.

Нужно ли писать свои кастом‑скиллы

• В экосистеме BMAD уже есть готовые роли/скиллы (аналитик, PM, архитектор, dev, quick‑spec и т.п.), которые умеют делать общий каркас: уточнять задачу, структурировать требования, разбивать на шаги.

• Этих базовых вещей достаточно, чтобы:

  • формализовать расчётную задачу;

  • собрать допущения/нагрузки/критерии;

  • сделать чек‑листы и структуру отчёта.

Когда «свои скиллы» действительно нужны

• Когда вы хотите, чтобы ИИ уже говорил на вашем инженерном языке: СП, Eurocode, типовые узлы, ваши шаблоны отчётов, фирменные методички.

• Тогда поверх базовых BMAD‑ролей вы делаете тонкую настройку: свой «PM по расчётам», свой «архитектор расчётной схемы», свой «scrum‑мастер для FEM‑кейсов», но это не обязательный старт, а следующий уровень.

Практичный вариант для старта инженера

• Начать с готовых базовых скиллов и использовать их ровно для одного этапа: постановка задачи и чек‑лист к модели/расчёту.

• По мере того как вы увидите, какие вопросы/формулировки реально помогают в вашей работе, из этого уже собрать свой кастом‑скилл (по сути — сохранённый промпт/профиль роли с вашими нормами и шаблонами).

То есть: с «ванильным» BMAD можно спокойно заходить и получать пользу; кастом‑скиллы — это не «обязалово», а способ позже зашить внутрь ИИ вашу конкретную инженерную школу.

 

Edited March 12 by Chardash

[Chardash 313]

Позже добавлю примеры, например, калькулятор, написанный на Rust, который работает не только на десктопе, но и в веб-версии. Это покажет, как BMAD может быть использован для создания универсальных решений.

[Fedor 1,678]

Спасибо, посмотрю. Как раз хотел оживить старые коды , а то в VS 2003 все работало и работает на VM и старой W.   А при компиляции на новых выдает кучу ошибок. Хотел переделать на Qt и заодно приделать для Добряка оболочки и балки, чтобы проверить теорию да и вообще в Linux как то приятнее работать :) 

[Chardash 313]

В практической работе с современными языковыми моделями постепенно сформировалось довольно трезвое понимание их роли в разработке. Речь, как правило, не идёт о "замене программистов". Скорее это инструмент, который может ускорять часть работы, но при условии, что человек остаётся основным носителем инженерного мышления.
 

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

Даже при использовании ИИ остаётся минимальный технический порог входа. Обычно достаточно ориентироваться хотя бы в одном распространённом языке, чаще всего в Python или JavaScript. Важнее даже не способность писать код, а способность его читать и понимать. Полезно представлять себе, как устроена работа с Git: что такое коммит, ветка, pull request, как читать diff. Кроме того, желательно иметь общее представление о том, как взаимодействуют компоненты веб-систем: HTTP, REST-подход, формат JSON, базовые схемы авторизации. Эти знания позволяют хотя бы на уровне здравого смысла оценивать предложенный моделью код.
 

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

По наблюдениям, модели достаточно уверенно справляются с типовыми задачами на популярных языках и фреймворках. Это могут быть простые сервисы, интеграции между системами, небольшие утилиты, генерация тестов или объяснение существующего кода. В таких ситуациях они часто ускоряют рутинную работу. Однако в областях с жёсткими требованиями к памяти, времени отклика или безопасности ситуация иная. Для кода на C или C++, для встроенных систем и real-time-приложений цена ошибки может быть слишком высокой. Аналогичные ограничения возникают при работе со сложной архитектурой, криптографией, параллелизмом или большим легаси-кодом. В этих случаях модель нередко предлагает решения, которые выглядят корректно, но не учитывают важных деталей.
 

Типичные проблемы при использовании сгенерированного кода достаточно известны. Модели могут ссылаться на функции и API, которых в реальности не существует. Часто пропускаются граничные случаи и обработка ошибок. Иногда отдельные фрагменты кода написаны в разных стилях и плохо согласуются между собой. Кроме того, ответы редко учитывают нефункциональные требования - производительность, устойчивость к отказам, ограничения инфраструктуры.
 

Поэтому на практике ИИ остаётся инструментом, а не самостоятельным участником проекта. Он не несёт ответственности за результат, не учитывает стоимость ошибки и не участвует в согласовании решений между заказчиком и командой. Архитектура системы, приоритеты разработки и компромиссы между требованиями по-прежнему формируются людьми.
 

Если говорить упрощённо, то работа с такими инструментами становится действительно полезной тогда, когда человек способен прочитать предложенный код, понять его смысл и критически оценить результат. В этом случае модель может выступать ускорителем рутинных задач и источником черновых решений. Дальнейшая проверка и доведение до промышленного уровня остаётся обычной инженерной работой.
 

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

Edited March 16 by Chardash

[Chardash 313]

Возможно, сравнение не совсем точное, но по ощущениям ИИ для программистов сегодня играет примерно ту же роль, что системы вроде Autocad,  ЛИРА-САПР или Tekla Structures для инженеров-конструкторов. Речь не о замене специалиста, а о появлении инструмента, который снимает часть рутинной работы и ускоряет отдельные этапы.
 

Я не застал эпоху перфокарт, но хорошо помню время, когда код практически полностью писался вручную и основным источником помощи были форумы и обсуждения на Stack Overflow. Чтобы разобраться с ошибкой или понять работу какой-то базовой функции библиотеки, иногда уходили дни, а иногда и недели.
 

Сейчас многие из этих задач решаются заметно быстрее. ИИ не отменяет необходимости понимать код и архитектуру, но заметно упрощает процесс обучения и поиска отправной точки для решения.

Edited March 16 by Chardash