Jump to content

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


Recommended Posts

Fedor

image.pngimage.png

 

Вот что такое окаймление в симметричных матрицах.  

 

void ldl_decomposition(const vector<vector<double>>& A, vector<vector<double>>& L, vector<double>& D) {
  

И вот как примерно хранить матрицу жесткости на втором шаге для решения.  На первом лучше хранить vector<list<block>>& A  тут исходная нумерация для того чтобы построить и модифицировать по https://pinega3.narod.ru/fmin.htm  учесть всякие линейные связи которые сократят число неизвестных и позволят перейти к уравнениям Лагранжа второго рода, если говорить в терминологии аналитической механики. Когда-то придумал для циклической симметрии в многопоточных передачах .  Потом распространил на всякие другие условия :)  

Link to post
Share on other sites


Chardash

Pinega — приложение для 3D инженерного моделирования

Обзор

Pinega — это приложение на C++ для 3D моделирования инженерных конструкций, созданное с использованием Microsoft Foundation Classes (MFC). Проект предназначен для инженеров и разработчиков, работающих с анализом конструкций, конечно-элементным моделированием и симуляцией.

Ключевые возможности

  • 3D моделирование: создание и управление 3D инженерными конструкциями.

  • Симуляция материалов и нагрузок: определение материалов, сил и граничных условий.

  • Операции с матрицами и векторами: встроенная поддержка разреженных и полных матриц.

  • Модульная архитектура: разделение базовой логики и компонентов пользовательского интерфейса.


Архитектура проекта

text
pinega/
├── MODELER/          # Главное MFC приложение (MDI интерфейс)
├── PFPDLL/           # MFC расширение DLL (вычислительные функции)
├── docs/             # Документация (в разработке)
└── third_party/      # Сторонние библиотеки (при наличии)

Компоненты

1. MODELER (Главное приложение)

  • Тип: MFC MDI приложение

  • Назначение: 3D моделирование инженерных конструкций.

  • Ключевые классы:

    • CModelerApp — главный класс приложения.

    • CMainFrame — главное окно фрейма.

    • CChildFrame — дочерние окна MDI.

    • CModelerDoc — класс документа для данных модели.

    • CModelerView — класс представления для визуализации.

    • CModel — основная структура данных модели.

    • CSection, CForce, CMater — элементы модели (сечения, силы, материалы).

2. PFPDLL (DLL библиотека)

  • Тип: MFC расширение DLL

  • Назначение: вычислительные функции для моделирования.

  • Ключевые компоненты:

    • Операции с матрицами (FullMatr, Sparse, GolMatr).

    • Элементы конструкций (Block, Element3d, SofaceElement).

    • Структуры векторов (VectorElement, VectorLine, VectorNode).

    • Расчеты материалов (Material).


Технологии

 
 
Компонент Технология Примечания
Язык C++ Современный C++ (рекомендуется C++17/20)
Фреймворк MFC (Microsoft Foundation Classes) Устаревший, но функциональный UI фреймворк
Среда разработки Visual Studio 2019/2022 Рекомендуется для наилучшей поддержки MFC
Система сборки MSBuild / Visual Studio Файлы .vcxproj для поддержки современных VS
ОС Windows MFC специфичен для Windows

Сборка и запуск

Требования

  • ОС: Windows 10/11

  • Среда разработки: Visual Studio 2019 или новее (для поддержки .vcxproj)

  • Компилятор: MSVC (рекомендуется последняя версия)

Инструкция по сборке

  1. Откройте решение в Visual Studio:

    bash
    cd MODELER
    # Откройте Modeler.sln
    cd ../PFPDLL
    # Откройте PFPDLL.sln
  2. Порядок сборки:

    • Сначала соберите PFPDLL (DLL библиотеку).

    • Затем соберите MODELER (главное приложение, которое использует DLL).

  3. Конфигурации:

    • Debug: отладочная сборка с символами.

    • Release: оптимизированная сборка для выпуска.


Структура исходного кода

MODELER — ключевые файлы

 
 
Файл Описание
MODELER.CPP Точка входа в приложение
Model.cpp/h Основной класс данных модели
modelerDoc.cpp/h Класс документа для данных модели
modelerView.cpp/h Класс представления для визуализации
MainFrm.cpp/h Главное окно MDI фрейма
ChildFrm.cpp/h Дочерние окна MDI
Section.cpp/h Элементы сечений
Force.cpp/h Классы сил и нагрузок
Mater.cpp/h Определения материалов
Dialog*.cpp/h Диалоги конфигурации

PFPDLL — ключевые файлы

 
 
Файл Описание
pfpdll.cpp Инициализация DLL (DllMain)
Sparse.cpp/h Операции с разреженными матрицами
FullMatr.cpp/h Операции с полными матрицами
Material.cpp/h Расчеты материалов
Element3d.cpp/h Определения 3D элементов
Block.cpp/h Структуры блоков

Вклад в проект

Мы приветствуем вклад от международного сообщества! Вот как вы можете помочь:

Начало работы

  1. Сделайте форк репозитория (если размещен на GitHub/GitLab).

  2. Клонируйте репозиторий:

    bash
    git clone git clone https://gitflic.ru/project/pavelpnz/pinega.git
  3. Настройте среду разработки (Visual Studio 2019/2022).

  4. Соберите проект (следуйте инструкциям по сборке выше).

Правила

  • Стиль кода: Следуйте современным практикам C++ (используйте std::string, std::unique_ptr и т.д.).

  • Документация: Пишите комментарии и документацию на русском языке.

  • Тестирование: Добавляйте тесты для новых функций или исправлений ошибок (используйте Google Test или Catch2).

  • Сообщения коммитов: Используйте понятные, описательные сообщения коммитов.

Как внести вклад

  1. Сообщайте об ошибках: Откройте задачу с четким описанием.

  2. Предлагайте новые функции: Откройте задачу с вашей идеей.

  3. Отправляйте изменения: Откройте запрос на слияние с вашими изменениями.


План развития

Краткосрочные цели

  • Добавить документацию для всех модулей.

  • Перенести систему сборки на CMake для поддержки кроссплатформенности.

  • Добавить модульные тесты для основной функциональности.

  • Заменить устаревший код современными практиками C++.

Долгосрочные цели

  • Поддержка кроссплатформенной сборки (Linux/macOS через Qt или аналоги).

  • Интеграция с Rust для критичных к производительности модулей.

  • Современный интерфейс пользователя (замена MFC на Qt или веб-интерфейс).


Внешние ресурсы


Примечания для разработчиков

Особенности кода

  • Используется MFC Extension DLL для разделения кода.

  • Математические функции используют <cmath> и <cfloat>.

  • Пользовательская функция round() для точного округления.

  • Устаревшие комментарии на русском языке.

Известные ограничения

  • Изначально создан в Visual Studio 6.0 (файлы .dsp, .mak).

  • Добавлены современные файлы .vcxproj для поддержки новых версий VS.

  • Убедитесь, что PFPDLL.DLL доступна для MODELER при сборке.

Рекомендации

  1. Проверьте пути к DLL в настройках проекта.

  2. Используйте конфигурацию Debug для разработки.

  3. Проверьте пути к включаемым файлам и библиотекам в свойствах проекта.


Глоссарий

 
 
Термин Описание
MFC Microsoft Foundation Classes — фреймворк C++ для приложений Windows.
MDI Multiple Document Interface — интерфейс с несколькими дочерними окнами.
DLL Dynamic Link Library — разделяемая библиотека для Windows.
PCH Precompiled Header — предварительно скомпилированные заголовки для ускорения сборки (stdafx.h).



 

Спасибо. Пока дополнительные вопросы отсутствуют. Если кому-то еще потребуется, информация по проекту более подробно изложена в README выше.

Изучаю код постепенно - тк сейчас ведутся и другие проекты (Python). При изучении проекта учитываю, что C++ не является моим основным стеком, поэтому анализ может занять больше времени.

Link to post
Share on other sites
Fedor
Цитата
FullMatr.cpp/h Операции с полными матрицами

Это тоже разреженные блочные матрицы в исходной нумерации узлов.  Создаются вначале и в них учитываются условия при наличии связей. 

 

Sparse.cpp/h Операции с разреженными матрицами  оптимизированные в новой нумерации для минимизации профиля и разложения .  
Edited by Fedor
Link to post
Share on other sites
Fedor

Спросите у ИИ google  -  "Как реализовать схему Ларкума Кнута для хранения симметричных разреженных матриц из блоков на с+

и получите неплохое объяснение как примерно устроена начальная глобальная матрица жесткости ... 

Цитата
Использование std::list для динамического изменения — это классический подход «списка смежности» (Adjacency List). Это позволяет вставлять новые блоки в произвольные строки или удалять их за 
nullnull
null
null
 (если итератор уже на месте) без перемещения огромных массивов данных в памяти.
Для реализации схемы Ларкума-Кнута с акцентом на динамику, лучше всего использовать вектор списков. Вектор дает быстрый доступ к строке по индексу, а список внутри строки позволяет гибко манипулировать блоками.

 

image.gif

image.gif

image.gif

image.gif

Вот так и делал для создания и изменения согласно условий глобальной матрицы  

  • Нравится 1
Link to post
Share on other sites
Chardash

С ИИ проблем нет. С платными не работаю (пока хватает бесплатных, что-то могу и без нейросеток). Кстати, бесплатный копилот меня сразу заблокировал, как увидел в контексте названия строительной гусеничной техники РФ. Теперь даже с КВНом не работает.

Edited by Chardash
Link to post
Share on other sites
Chardash
1 час назад, Fedor сказал:

у ИИ google 

уточню ответ - у Гугла есть бесплатная модель, но с нюансами или ограничениями для генерации кода.
ИИ подсказки в поиске могут не работать, если гугл отключил ИИ модель, если начать активно ее расспрашивать. Через несколько дней снова включает. 

Link to post
Share on other sites
Fedor

Ну тогда по старинке, Писсанецки стр 32-33 посмотреть.

И старое доброе Искусство программирования для ЭВМ    Кнута   том 1 стр 376-377

Когда-то ими обходился 

:) 

Edited by Fedor
Link to post
Share on other sites
Fedor

Интересно бы поэкспериментировать с  std::valarray   да руки не дошли. Хотя Страуструп писал что можно добиться ускорения в 30 раз при вычислениях. Особенно для скалярных произведений, это основная операция при разложении матрицы ... 

image.png   Хотя много чего интересного и перспективного появилось в алгебре ... 

 

Link to post
Share on other sites
Chardash
15 минут назад, Fedor сказал:

Интересно бы поэкспериментировать

Да, да. Федор, как мне кажется, сначала нужно сделать базовый MVP , пусть с тормозами, но на современном Си++  и с базовым интерфейсом на кьют / imgui. Потом уже переходить к оптимизации, кэшированию и прочим улучшениям. Примерный план:

0. Изучение исходников, литературы, практик разработки МКЭ пакетов (я еще здесь)
1. Перенести код на современный C++ (заменить char*, new/delete, C-массивы).
2. Разделить проект на модули (Model, Solver, IO, UI).
3. Добавить минимальный интерфейс на Qt/ImGui.
4. Написать тесты для критических частей.
5. Стабилизировать MVP (убедиться, что всё работает как раньше).
6. Профилировать и оптимизировать (только после стабилизации).

Литература у меня есть, есть и примеры. Нужно время, чтобы погрузиться перед стартом.

Или вообще оставить на MFC. Но это может растянуться на годы.
 

Скрытый текст

В чем-то даже плюс, мельком видел код от ядра визуализации Скад Оффиса, там тоже MFC

 

Link to post
Share on other sites
Fedor

На win XP и VS 2003 все работает на VM файлы я выложил. Так что проверять есть по чему. 

Как обычно переход занимает год-полгода.  По крайней мере так было раньше с новыми версиями. 

Edited by Fedor
Link to post
Share on other sites
Chardash

Сделал план подробней, чтобы скелет оброс "мясом"
 

Фаза 0. Стратегика и аналитика

0.1. Бизнес-цели и ограничения  
- Определить, что именно является "core value": учебная МКЭ-песочница, исследовательский инструмент, пре- и постпроцессинг для конечно-элементного анализа (КЭА/FEA), моделирование и анализ структурной механики, специализированные расчеты или задел под индустриальный продукт.  
- Для open source: сформулировать позиционирование (например, "легкий учебный FEA-пакет на C++ c Python API"), определить лицензию (пример: GPL/AGPL для ядра, более свободная для API, если планируется коммерческое расширение).
- Для дальнейшего бизнеса: заранее продумать, что останется открытым (ядро, форматы, часть визуализации), а что можно делать в виде закрытых модулей (BIM-интеграции, специальные решатели, корпоративный UI).
 

0.2. Пользователи и сценарии  
- Ядро сценариев:  
  - студенты и преподаватели, которым важны прозрачность алгоритмов, простые модели, Python-скриптинг;  
  - инженеры-энтузиасты/исследователи, которым нужна возможность автоматизации и интеграции с питоновским стеком (NumPy, SciPy,
- Сразу отсеять "завышенные" ожидания: массовое промышленное внедрение/сертификация по нормам на первом цикле — нереалистично, это долгий путь.

0.3. Анализ текущего приложения 
Выделить все существующие функции PINEGA. Что она делает? Какие типы моделей поддерживает? Какие расчеты выполняет? Какие результаты визуализирует? Как пользователь взаимодействует с приложением? Это критически важно, чтобы "убедиться, что всё работает как раньше" на этапе MVP. 
- Картировать функциональность и выделить действительно обязательный минимум для первой версии (тип элементов, типы нагрузок, типы результатов).  
- Зафиксировать, что переносим "как есть" в ядро, а что можно сразу выкинуть/переписать (UI-обвязка, устаревшие диалоги, специфические хаки под GDI/MFC).  
- Отдельно выписать зависимости от Windows API и отрисовки (GDI), чтобы впоследствии их не протащить в новую архитектуру.

0.4. Анализ технологий и практик  
- В качестве ориентира использовать существующие открытые FEA/CAE-проекты: CalculiX, Code_Aster, MFEM, FEniCS/SFEPy и т.п., где ядро на C++/Fortran, а Python используется как оболочка и для автоматизации. 
- Для UI и визуализации в "настольном" варианте на старте сосредоточиться на связке Qt + OpenGL/VTK, как показала практика миграций MFC→Qt в индустрии.
- Game-движки (Unity/Unreal) сразу зафиксировать как длинную перспективу, а не как обязательную часть первой дорожной карты: они оправданы, когда уже есть стабильный solver и потребность в сложных интерактивных сценах/BIM/VR (в GDI-решении, отсутствует встроенная концепция LOD, подобная той, что используется в игровых движках или ГИС)

0.5. Архитектура ядра PinegaCore  
- Язык: современный C++ (минимум C++17), строгий RAII, модульность, чистые интерфейсы.  
- Основные подсистемы ядра:  
  - Model — геометрия, сетка, материалы, нагрузки, граничные условия;  
  - Solver — МКЭ-решатель, в перспективе возможность подключать внешние численные библиотеки;  
  - IO — форматы моделей и результатов (включая backward-совместимость с .pin);  
  - Math — линейная алгебра и утилиты (с возможной опорой на внешнюю библиотеку, а не самописную);  
  - Python API — слой биндингов к Model/Solver/IO, по образцу MFEM, FEniCS и других библиотек с Python-интерфейсом.
 
Разработка высокоуровневой архитектуры и детального дизайна:
* Диаграмма компонентов (Model, Solver, IO, UI, Renderer).
* Диаграммы классов для ключевых модулей.
* Диаграммы последовательности для критических сценариев.
* Определение API между модулями.

Принципы кодирования и стандарты
* Соглашения по стилю кода: Google Style, LLVM Style или свой собственный?
* Принципы ООП/SOLID: как будем применять их при рефакторинге?
* Принципы дизайна API: как будут выглядеть внешние интерфейсы модулей?
 

0.6. Риски и их снижение  
- Риск расползания скоупа: Unity, BIM, AI, репортинг — всё сразу невозможно, поэтому жёстко зафиксировать MVP-скоуп (решатель + базовый UI + простая визуализация).  
- Риск потери функционала: завести набор эталонных задач, которые должны давать одинаковые результаты в старой и новой системе.  
- Риск по лицензированию: выбрать лицензию, совместимую с планами на бизнес (например, ядро под LGPL или MPL, если хочется допускать проприетарные надстройки).

0.7. Миграция формата данных  
- Зафиксировать формат .pin как legacy, реализовать новый внутренний формат (например, текстовый/JSON/SQLite) и конвертеры старый→новый и по необходимости новый→старый.  
- На ранней стадии ограничиться минимальным набором сущностей, чтобы не "цементировать" старые архитектурные решения.

0.8. Концепция UI и визуализации  
- Для первой версии: кроссплатформенный десктопный UI на Qt или ImGui(wx/GTK я бы рассматривал только если есть ограничение по Qt) с простым 2D/3D-просмотром (каркас, базовые карты результатов)
- Unity/Unreal прописать как отдельный ветвистый трек, который стартует только после стабилизации ядра и десктопного UI, а не как часть основного маршрута.

Фаза 1. Модернизация ядра PinegaCore

Какую новую функциональность вы хотите добавить? (Например, поддержка новых типов элементов, улучшенные алгоритмы, новые методы визуализации, интеграция с другими системами, экспорт/импорт в современные форматы). Нужно описать, как различные пользователи будут использовать систему для выполнения своих задач.

1.1. Рефакторинг и перенос алгоритмов  
- Перенести вычислительную часть на чистый C++ без зависимости от MFC/GDI.  
- Заменить ручное управление памятью и сырые массивы на стандартные контейнеры и умные указатели, структурировать код по модулям и неймспейсам.

1.2. Разделение на модули  
- Разнести Model, Solver, IO, Math в отдельные библиотеки/модули так, чтобы Solver можно было использовать без UI (как библиотеку).  
- Заложить минимальные точки расширения: возможность добавить новые типы элементов, материалов, решателей без переписывания всего ядра (через фабрики/регистрацию).

1.3. Тестирование  
- Ввести юнит-тесты для математики и локальных алгоритмов.  
- Добавить интеграционные тесты на уровне "model → solver → results" и регрессионные тесты по эталонным задачам (сравнение с исходной PINEGA и, по возможности, с внешним FEA-решателем для валидации).
 

Фаза 2. MVP: базовый UI и визуализация

* 3D-рендерер: OpenGL (какой версии?), Vulkan, DirectX? Или абстракция типа Diligent Engine, bgfx?
* Геометрическое ядро: OpenCASCADE, С3D(исходники и разрешение нужно запросить у разработчиков) или свой велосипед(сложно)?
* Математические библиотеки: Eigen, GLM, Armadillo?
* Система сборки: CMake, Meson, Bazel?
* Система управления зависимостями: Conan, vcpkg?
* CI/CD: как будем автоматизировать сборку, тестирование, развертывание?

2.1. Базовый UI  
- Простейший GUI на Qt/ImGui:  
  - открыть/сохранить модель;  
  - список элементов/нагрузок;  
  - запуск расчёта;  
  - выбор результатов для отображения.  
- Не гнаться за идеальным UX: задача — дать удобный инженерный прототип и опорную точку для комьюнити.

2.2. Базовый рендеринг  
- Реализовать простой 3D-просмотрщик каркасной/объёмной сетки и цветовых карт (перемещения, напряжения).  
- Технически это может быть Qt 3D, VTK или лёгкий OpenGL-рендерер; для учебного/open source проекта нет необходимости сразу делать сложную графику уровня game-движка.

2.3. Стабилизация  
- Повысить устойчивость: крэш-репорты, логирование, шаблонные сценарии тестирования.  
- Публичный релиз MVP в open source (GitHub/GitLab), с минимальной документацией: как собрать, как запустить примеры, как написать простой Python-скрипт.
 

Фаза 3. Оптимизация и расширение визуализации

3.1. Профилирование и оптимизация  
- Профилировать Solver и операции с большими моделями; оптимизировать самые горячие участки (структура памяти для матриц, использование внешней библиотеки линейной алгебры, распараллеливание). 
- Для учебного проекта приоритет — "достаточно быстро", для потенциального коммерческого — "масштабируемо и предсказуемо".

3.2. Усиление визуализации  
- Добавить типичные для FEA post-processing функции: сечения, эпюры, графики зависимостей, анимацию деформаций.  
- Чётко ограничить функционал: не превращать MVP в "всё и сразу", а смотреть на запросы от пользователей/комьюнити.

3.3. Дальнейшее планирование по Unity/Unreal (опционально)  
- На этом этапе можно вернуться к идее связки с Unity/Unreal для задач, где действительно надо:  
  - большие BIM-модели;  
  - интерактивные walkthrough;  
  - VR/AR-просмотр результатов расчёта. 
- Сформировать отдельный технико-экономический расчёт: стоимость лицензий, компетенции по C#/C++ внутри команды, added value по сравнению с уже имеющимся десктопным UI.

Фаза 4. Долгосрочные расширения: Unity/BIM/AI (опционально)

Эта фаза не обязательна для учебного/open source ядра, но может стать основой для будущего коммерческого продукта.
 

4.1. PinegaUnity / PinegaUnreal  
- Вынести в отдельный репозиторий/продукт C#-/C++-клиент на Unity/Unreal, который:  
  - подключается к PinegaCore как к вычислительному серверу/библиотеке;  
  - даёт продвинутый UI и визуализацию для презентаций, BIM-контекстов, VR/AR-режимов. 
- Это может быть либо коммерческий продукт на базе open source ядра, либо отдельный модуль с другой лицензией.

4.2. AI Preview  
- Использовать Python API и существующую практику генерации датасетов на базе FEA-решателей:  
  - генерировать обучающие выборки "геометрия + нагрузки → результаты";  
  - обучать модели приближённой оценки напряжений/деформаций;  
  - интегрировать быстрый "AI-черновик" в UI (подсветка горячих зон до точного запуска решателя). 
- Важно не продавать это как "замену МКЭ", а позиционировать как ускорение первых итераций.

4.3. Интеграции и "толстый" десктоп  
- По мере появления стабильного ядра есть смысл думать о расширениях:  
  - BIM-импорт/экспорт (IFC, Revit, Tekla) через существующие открытые библиотеки;  
  - специализированный PinegaDesktop (Qt + VTK) для продвинутого пост-процессинга и отчётов для профессионалов. 

"На win XP и VS 2003 все работает на VM файлы я выложил" - в репе есть, посмотрю потом, чем отличаются

Link to post
Share on other sites
Fedor

Большевикам с их планированием такое и не снилось. :) 

Цитата

• Есть ли у вас план, мистер Фикс? — Есть ли у меня план? Есть ли у меня план? Да у меня целых три плана! 

 

  • Хаха 1
Link to post
Share on other sites
Fedor

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

Написание программ это процесс  создания последовательности.    Это мы видим , например, на Linux или любой другой программе...  

Link to post
Share on other sites
Chardash
Только что, Fedor сказал:

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

Написание программ это процесс  создания последовательности.    Это мы видим , например, на Linux или любой другой программе...  

Без ТЗ как игра в рулетку. Пост выше не результат месячной проработки, но он закрывает основные вопросы.

Пример, почему ТЗ все же важно: 2,5 года назад я выкладывал здесь проект из портфолио - крупный Django-бекенд с кучей приложений (калькуляторы для инженеров, система тестирования знаний, магазин проектов). На тот момент я работал с ним полтора года, но потом заморозил на 2 года.
 

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

Причем тут магазины CRM, мы же говорим про МКЭ. Да, МКЭ ниша уже, магазины и подобные CRUD-приложения ценятся широкой аудиторией. Пока вы делаете сложный проект, можно параллельно зарабатывать на более массовых решениях. Если админы не будут против (рассматривая как рекламу), позже закину сюда пару таких примеров.

Link to post
Share on other sites
Chardash

Федор, на 100% не полагайтесь на ИИ. Нужно проверять код и, тем более, расчеты и формулы. Как помощник да, но не как идеальный исполнитель

Link to post
Share on other sites
Fedor

Нельзя полагаться и на ЕИ :)  метод проб и ошибок единственный надежный метод решения нелинейных задач.  А ошибки еще надо и найти :) 

Цитата

Их можно было избежать, потратив всего пару недель на планирование до начала разработки

Это называется - знал бы где упадешь - соломки подстелил бы :)

Link to post
Share on other sites
Chardash
5 минут назад, Fedor сказал:

метод проб и ошибок единственный надежный метод решения нелинейных задач.

Да, есть Agile, Scrum и прочие гибкие подходы - они спасают, когда задача похожа на "машину времени" с кучей неизвестных. Можно объяснять заказчику новые счета и сроки, ссылаясь на неопределённость. Но МКЭ - не такая задача.

МКЭ- это известная область с чёткими математическими основами, типовыми алгоритмами и проверенными подходами. Здесь не нужно изобретать велосипед с нуля: есть готовые библиотеки (CalculiX, FEniCS), стандартные процессы (препроцессинг - решение - постпроцессинг) и даже типовые архитектурные решения для высокопроизводительных вычислений.

Link to post
Share on other sites
Fedor

Так кажется в отношении любой задачи пока не столкнешься с реальностью :)  Велосипеды всегда надо проектировать с нуля если хочешь проектировать, а не копировать :)

 

Цитата

стандартные процессы (препроцессинг - решение - постпроцессинг)

Ага, как говаривал Гегель - Тезис - Антитезис - Синтез.   Диалектика, однако. Куда же без нее.  ИИ тоже все просто - промпт-обработка где-то - результат .  Или в пятницу - налил - выпил - кайф   :) 

Цитата
Диалектика внутри итерации
Каждый спринт в Agile (например, в Scrum) проходит через триаду:
  1. Тезис: План спринта (что мы хотим сделать).
  2. Антитезис: Реальный процесс разработки (столкновение с ошибками, новыми требованиями, техническими сложностями).
  3. Синтез: Обзор спринта и Ретроспектива. Команда анализирует опыт и создает «новый тезис» — улучшенный процесс для следующего цикла.
 

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

 

Цитата
Резюме
Scrum — это циклическая диалектика. Он официально признает, что мы не можем синтезировать финальный продукт за один раз. Поэтому мы анализируем (дробим), синтезируем (собираем инкремент), получаем «отрицание» (фидбек) и выходим на новый уровень развития.
 

 

Edited by Fedor
Link to post
Share on other sites
Fedor
Цитата
 Эволюция против Революции
Диалектика Kanban более мягкая:
  • Scrum часто требует «революции»: смены ролей (Scrum Master, PO), внедрения ритуалов. Это резкий переход от старого тезиса к новому синтезу.
  • Kanban говорит: «Начни с того, что есть сейчас». Он анализирует текущие процессы и постепенно вносит микро-изменения. Это эволюционный синтез.

 

 

Резюме:
Если вам нужна четкая структура и ритм для создания нового продукта — выбирайте Scrum (диалектика рывками). Если у вас поддерживающий процесс или поток однотипных задач, где важна скорость реакции — лучше подойдет Kanban (диалектика потока).   

Link to post
Share on other sites
Fedor
 Scrumban: Гибридная диалектика
Scrumban — это синтез (в прямом смысле слова) лучших сторон Scrum и Kanban.
  • От Scrum (Тезис): Берем структуру и планирование. Мы анализируем цели на ближайший период (например, на месяц или две недели), чтобы не терять фокус.
  • От Kanban (Антитезис): Берем гибкость потока. Мы отрицаем жесткие рамки спринта, если они мешают. Если задача прилетела сейчас — мы делаем её сейчас, не дожидаясь следующего планирования.
  • Итог (Синтез): Получаем систему, где есть планирование по необходимости (On-demand planning). Мы анализируем бэклог только тогда, когда в нем заканчиваются задачи.
 

и ни строчки кода и ничего по существу, зато солидно и убедительно   :)
 Личная диалектическая триада (Рост над собой)
Используйте триаду Гегеля для саморазвития:
  1. Тезис (Привычка): «Я работаю по 8 часов без перерыва, потому что я продуктивен».
  2. Антитезис (Конфликт): Усталость, ошибки, отсутствие сил вечером. Вы понимаете, что старый метод не работает.
  3. Синтез (Новый уровень): Вы внедряете метод Pomodoro (5 минут работы / 25 отдыха). Это синтез вашей тяги к труду и потребности организма в отдыхе.
Резюме - ешь потей, работай мерзни.  И - хочешь работай, хочешь сачкуй, все равно получишь ...( по штатному расписанию). Если вообще получишь   :) 

 

Помню при большевиках придумали для повышения производительности труда планирование и отчетность. До обеда пишешь план и согласуешь с начальником. После обеда отчитываешься и утверждаешь отчет.  Так и закончился СССР :)  

Edited by Fedor
Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

  • Сообщения

    • kirass
      Из под пользователя с правами админа можно отменить разрегистрацию файлов версии выше первой. Т.е. пользователь регит фаил, фаил получает версию 1, пользователь разрегистрирует фаил и оставляет его в этом состоянии ...... Такой сценарий отменяется только системным админом(красная стрелка)!   Пользователь регит фаил, фаил получает версию 1, пользователь разрегистрирует фаил, работает с ним, снова региг, фаил получает версию 2, пользователь разрегистрирует фаил и оставляет его в этом состоянии ...... Такой сценарий может быть отменен пользователем с правом отмены разрегистрации(черная стрелка)!   В столбце разрегистрировано пользователь будет написан курсивом для файлов где отмена возможна только системным админом и обычным если отмена возможна пользователем с правом отмены разрегистрации.
    • brigval
      Вы можете не купить 1,7 м если Вам предлагают 50 м. Поэтому фактическое закупленной количество может быть и больше, чем указано в спецификации. Можно исходить из этого.     Если нарезка идет по спецификации, то удобнее указать в спецификации. Кому как удобнее для работы, тот так и напишет. Здесь нет смысла упорствовать. )
    • Kelny
      Спецификация это фактически документ на поставку (это не документ о намерениях или договорённостях), если вы записали туда материала меньше чем надо на изделие с учётом допусков, то материала может просто не хватить. Тогда с тем же успехом можно написать только в ТТ и в спецификацию не записывать вовсе, так же как это делается для припоя или клея. Хотя если расход клея или припоя значительный, то его имеет смысл записать в спецификацию.   Конечно графа примечания ваша, но с тем же успехом это можно записать в ТТ или нанести размеры прямо на деталь в сборочном чертеже, что может быть нагляднее и понятнее. Но если есть хотябы небольшая вероятность, что это будут резать не при сборке, то лучше всё таки сделать чертёж детали и не морочить производителю голову.  
    • DanilV
      Я все понимаю ESPRIT наше все. Вы не могли бы посмотреть в библиотеках ПП именно для CITIZEN CINCOM M 20 1999 г. в? Он еще M1, скорее всего называется.
    • MixaIT
      Тут еще интересно посмотреть как DXF надо будет открыть в текстовом редакторе, скопировать содержимое и вставить это содержимое в специальное окошечко. Это же мега удобная технология! 
    • mannul
      Опять вранье, не умеет твой киберолух централизованно обновляться и улучшаться, потому что он не генеративная нейросеть, а набор if then else. DXF нужен специально подготовленный, обычный не подойдет
    • brigval
      Закупать можно больше и без увеличения размеров в КД. Какие есть договоренности. Если договоренностей никаких нет, можно записывать и с запасом конечно.     Это в графе "Кол." Я написал "в примечании", это значит в графе "Примечание"...
    • Kelny
      Суммарная длина должна быть больше с учётом допусков - это нужно для покупки с запасом. Конечная длина в изделии будет меньше.   Раздел материалов не записывается в штуках, там только объём, площадь, длинна и т.п. Даже размеры заготовки там не совсем по закону. БЧ деталь в САПР зло, т.к. на неё есть модель, но нет чертежа, а так конечно можно вообще все детали (даже сложные) выпускать без чертежа при наличии модели. Но хотя бы для нормоконтролёра лучше иметь хотябы упрощённый чертёж с основными размерами.   Друдоёмкость запишут на сборку. Но если заготовка этих строп отдельно от сборки, то логично всё таки создать деталь стропы с исполнениями, что бы заготовка строп была доступна без сборочного чертежа, а на сборке только пристрочить уже готовые детали. С точки зрения ускорения производства будет быстрее, возможно стропы нужной длины будут выходить из автоматизированного автомата, а сборщику надо будет только выбрать правильные стропы с маркировкой и пристрочить по своим местам.   Подход как минимум странный.   А так то можно пойти и вовсе по пути записи толко в ТТ, ведь не пишется ни чего в спецификации о клеях, припоях, а определяется технологом на предприятии.
    • Bot
      Medidata’s Second Annual AI Report Shows a Shift from Pilots to Enterprise Adoption with 72.9% of Early Adopters Seeing a Reduction in Study Timelines Просмотр полной статьи
    • Kelny
      Нормоконтролёру можно сдать не комплект для проверки, если это не связанные документы или по этапам, например, сначала ВП и СХЕМЫ и при необходимости расчёты по элементам (или расчёты позднее), потом ПЛАТЫ И СБОРКИ на них, потом ИЗДЕЛИЕ, потом УПАКОВКА и т.п.   А вот к моменту сдачи должен быть всесь комплект. Если чего-то нет, то исключать из КД (спецификации) и включать позднее по ИИ (не искуственнй интелект).   Проверять можно не комплект, а вот именно СДАВАТЬ, ТОЛЬКО КОМПЛЕКТ, а если что-то не успели, то исключать из КД, а потом вводить извещением.   НК должен делать правильно, а не приспосабливаться к устоявшейся дичи на предприятии.   Это единственно правильный подход для учтённой КД.   Как ни крути СДАННЫМ будет считаться ПОЛНЫЙ КОМПЛЕКТ, можно начать принимать документы на баланс архива без некоторых файлов, но если к МОМЕНТУ Х документ не появился, то именно в сдаваемой спецификации должны исчезнуть все отсутствующие документы и официально сдано только имеющееся.  
×
×
  • Create New...