[nickname2019]

На мой взгляд, основными проблемами российского рынка расчетного программного обеспечения являются:
- отсутствие нормальной возможности программной автоматизации по решению расчетных задач
(в расчетных программах отсутствует возможность для нормального программирования, т.е. невозможно написать программу для полностью автоматического создания расчетной схемы (нескольких расчетных схем), автоматического выполнения расчета, автоматического получения результатов и их автоматического анализа);
- закрытый исходный код по подбору расчетных параметров несущих элементов
(различные программы дают различные результаты при решении одинаковых задач, сравнение алгоритмов подбора различных между собой невозможно, так как код закрыт, общепринятых и одобренных алгоритмов нет, каждый пользуется своим "черным ящиком", который иногда может выдать ошибочное решение);
- для людей, которые занимаются автоматизацией на Лисп, C# и т.д. отсутствуют инструменты, которые позволяли бы программно "по-простому" вызвать готовую библиотечную функцию (например, по подбору сечения какой-то простой балки непосредственно из графического редактора), что вызывает необходимость вызова отдельной расчетной программы, что серьезно тормозит работу;
- "корявый" интерфейс, ужасно неудобная и медленная работа в существующих российских (и украинских) расчетных программах;
(фактически при наличии нормального графического редактора (autocad, nanocad и т.д.) приходится экспортировать данные в в "корявый" редактор расчетной программы и длительное в нем работать (задавать нагрузки, связи и т.д.), а встроить расчетную программу в нормальный графический редактор через автоматизацию невозможно).

В связи с вышеизложенным, назрел вопрос:
Как технологически наиболее правильно можно организовать разработку расчетного программного обеспечения с открытым исходным кодом?

Для совместной разработки кода создано общее хранилище на GitHub, используя которое каждый может поучаствовать в разработке :
https://github.com/chaosEagleOwl/source

На данным момент работа находится в стадии тестирования возможности совместной разработки.
Требования к программному обеспечению изложены в файле (ссылка README.md на GitHub): https://github.com/chaosEagleOwl/source/README.md

ТЗ на модуль формирования КЭ-сеток сформировано и помещено на GitHub.
На весь комплекс ТЗ формировать долго, видимо, будет чуть позже.

Сформирована доска для управления проектом, туда добавлены наиболее актуальные задачи.
Задачи проекта.

[румата]

Сообщение от nickname2019 -прямоугольная пластина;

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

----- добавлено через 51 сек. -----

Сообщение от nickname2019 Вряд ли использовать их "в лоб" хорошая идея.

Это нужно пробовать варианты. Тогда можно будет наверняка сказать какая идея лучше

----- добавлено через ~2 мин. -----

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

Хорошо, пусть пока будет так

----- добавлено через ~3 мин. -----
Здесь в библиотеке была книжка Агапова от 2002-го года с готовыми выведенными МЖ для нелинейных стержневых и слоистых оболочечных КЭ

[veb86]

Сообщение от nickname2019 Да. Точно. Толщиной можно задавать толщины плит. Для обозначения марки бетона/стали - пусть будут слои. Можно, конечно, сделать собственные proxy-объекты для КЭ, но это, скорее всего, приведет к тому, что памяти будет много уходить + будут тормоза + будут проблемы с совместимостью в других версиях графического редактора (в т.ч. проблемы переноса между nanocad/autocad). Масштаб лучше "приберечь" для оформительских целей.

Звучит как в фильме ужасов. Я не знаю что такое XDATA(подозреваю что это атрибуты), я бы делал через них. Толщина линий, масштаб, слои, цвет, и прочее... Вы шутите, этой программой роботы что ли пользоваться будут. На то что бы провести тесты и полюбоваться своей работой этого хватит, но в реальной работе, это будет капец (чисто мое мнение). Хотя для начала лучше хоть как бы реализовать, а там уж до пилите.

[румата]

https://russiaos.ru/summit/

[lenivec]

Сообщение от nickname2019 Как создать расчетное программное обеспечение с открытым исходным кодом (конструктивные решения)

А MathCAD приспособить никак? (я не вкурсе, только понаслышке)

[zvezdochiot]

Сообщение от lenivec А MathCAD приспособить никак?

Проще тогда NumPy и SciPy "приспособить" (Python).

[lenivec]

Сообщение от zvezdochiot Проще тогда NumPy и SciPy "приспособить" (Python).

На самом деле проще?
Я так думал, что MathCAD считывает сами формулы и знание языков программирования (вроде Python) не требуется. Написал формулу, любой может подправить, доработать, скопипастить, не выискивая цепочку алгоритма в коде.

Вместо чистого Python, я бы тогда предложил:
Dynamo (в связке с учебным Revit), либо Grasshopher. Есть еще open source Dynamo Sandbox (пока не знаю что он может). Вот еще нашел open source: GRevit

[nickname2019]

Предлагается следующий перечень задач (пока собираем литературу):
1. Процедура формирование локальных матриц жесткостей стержней и оболочек (на один КЭ)
1.1. В линейной постановке
1.2. В физически нелинейной постановке
(геометрически нелинейные пока рассматривать не будем, так как для массового проектирования это не так актуально, а прогибы ж.б. перекрытий определять нужно в физ. нелинейной постановке)
2. Написание процедуры по генерации плоских КЭ сеток (вероятнее всего, следует воспользоваться кодом от проекта GMSH)
3. Написание процедуры оптимизации нумерации узлов таким образом, чтобы ширина ленты матрицы была минимальной (для т.н. многофронтального метода)
4. Написание процедуры решения СЛАУ с обращением матрицы жесткости
5. Написание процедуры получения РСУ
6. Визуализация
7. Подбор расчетных параметров сечений по РСУ

[zamtmn]

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

[румата]

Сообщение от lenivec А MathCAD приспособить никак? (я не вкурсе, только понаслышке)

Никак. Загнется он на первой более-менее серьезной расчетной модельке.

----- добавлено через 48 сек. -----

Сообщение от zvezdochiot Проще тогда NumPy и SciPy "приспособить" (Python).

Как вариант. Но получится некоторое снижение производительности по сравнению с нативным си.

----- добавлено через ~2 мин. -----

Сообщение от lenivec Вместо чистого Python, я бы тогда предложил: Dynamo (в связке с учебным Revit), либо Grasshopher. Есть еще open source Dynamo Sandbox (пока не знаю что он может). Вот еще нашел open source: GRevit

Нет, не то. Это все геометрическоие параметризаторы.

----- добавлено через ~4 мин. -----

Сообщение от zamtmn начать его делать, а не говорить-обсуждать-выбирать

ну это ж не лиспик по изменению цвета слоя. без детального обсуждения стратегии и нюансов такой опенсорс создать не получится

----- добавлено через ~6 мин. -----

Сообщение от nickname2019 1.2. В физически нелинейной постановке (геометрически нелинейные пока рассматривать не будем, так как для массового проектирования это не так актуально, а прогибы ж.б. перекрытий определять нужно в физ. нелинейной постановке)

И в геометрической тоже нужно. Почему только ЖБ? Сталь уже не нужна?

----- добавлено через ~7 мин. -----

Сообщение от nickname2019 6. Визуализация

Здесь все же лучше смотреть в сторону OpenGL, а не автокада

[nickname2019]

Сообщение от румата И в геометрической тоже нужно. Почему только ЖБ? Сталь уже не нужна?

Сталь обычно все считают в линейной постановке (кроме мачт), но мачты тоже линеаризуются нормально. Но очень мало людей правильно считают прогибы ж.б.к. Хотелось бы этот пробел устранить.

Сообщение от румата Здесь все же лучше смотреть в сторону OpenGL, а не автокада

Может быть. Но написание нормального графического движка - задача более сложная, чем расчетного комплекса. Здесь вопрос не в 3д визуализации а в задаче эффективного обсчета 2-д текста и графики в больших объемах.

[veb86]

Сообщение от румата Цитата: Сообщение от lenivec Посмотреть сообщение А MathCAD приспособить никак? (я не вкурсе, только понаслышке) Никак. Загнется он на первой более-менее серьезной расчетной модельке.

Я для подобных расчетов пользуюсь Smath (бесплатный потому что, и расчеты небольшие). Посчитать в Mathcad можно много чего, но считает он действительно долго. Но зато все наглядно, легко потом будет проводить проверки расчета созданного в программе. Или как Вы предлагаете проверять расчеты?
В идеале было бы здорово, если группа матерых специалистов, начали делать расчет в Маткаде(Питон, Javascript или просто на бумажке), а nickname2019 начнет готовить библиотеку для автокада. Специалисты по воюют за правильность расчета, а nickname2019 просто переписал формулы из программы в программу, а не изучал математику расчетов

[nickname2019]

Сообщение от veb86 Я для подобных расчетов пользуюсь Smath (бесплатный потому что, и расчеты небольшие). Посчитать в Mathcad можно много чего, но считает он действительно долго. Но зато все наглядно, легко потом будет проводить проверки расчета созданного в программе. Или как Вы предлагаете проверять расчеты? В идеале было бы здорово, если группа матерых специалистов, начали делать расчет в Маткаде(Питон, Javascript или просто на бумажке), а nickname2019 начнет готовить библиотеку для автокада. Специалисты по воюют за правильность расчета, а nickname2019 просто переписал формулы из программы в программу, а не изучал математику расчетов

Вероятнее всего, nickname2019 на этой неделе напишет скелет на objectarx и напишет как сделать так, чтобы его компилировать и запустить для всех желающих приобщиться.
Для написания расчетных модулей c++ кроме как оформление циклов и объявления переменных типа double и string знать ничего не надо.

Предлагается писать программу для visual studio 2012, это позволит запускать приложение на autocad 2015, 2016. Также эту версию желающие смогут перекомпилировать под nanocad.

Имхо, при желании портировать с visual studio 2012 на более новые версии провести проще, чем наоборот.

Есть возражения?

[румата]

Сообщение от nickname2019 Сталь обычно все считают в линейной постановке...

Даже в СП16 есть пункт, говорящий о том, что расчет хорошо бы выполнять с учетом обеих нелинейностей в случае затруднения с определением расчетных длин элементов сисеты

[Ziabz]

А что не то с Mathcad? Я никогда в жизни не изучал программирование, без проблем создаю алгоритм проверки по нормам ..

[румата]

Сообщение от nickname2019 Предлагается писать программу для visual studio 2012...

А почему в таком древнем VS?

----- добавлено через ~4 мин. -----

Сообщение от Ziabz А что не то с Mathcad? Я никогда в жизни не изучал программирование, без проблем создаю алгоритм проверки по нормам .

С ним все нормально. Только:
1) он платный
2) он не будет работать с матрицами объемом в гигабайты

[nickname2019]

Сообщение от румата А почему в таком древнем VS?

Я думаю, что так проще обеспечить совместимость с Autocad 2015...Autocad 2021. (версию повысить проще, чем понизить)

[румата]

Сообщение от nickname2019 Есть возражения?

есть. я бы делал решатель на .net или python без завязки на .arx расширения автокада. dxf никто не отменял

[nickname2019]

Сообщение от румата есть. я бы делал на .net или python без завязки на .arx расширения автокада. dxf никто не отменял

Есть вероятность, что в процессе разработки придется прибегнуть к созданию своих объектов, на .net или python это сделать будет сложно. Плюс производительность здесь будет узким местом.

arx - это нужно для визуализации и отладки, чтобы не писать свой граф. редактор.

[румата]

Эти языки более распространены и предпочтительны для opensource

----- добавлено через ~1 мин. -----

Сообщение от nickname2019 Есть вероятность, что в процессе разработки придется прибегнуть к созданию своих объектов...

только не proxy. это все погубит

[nickname2019]

Сообщение от румата Эти языки более распространены и предпочтительны для opensource

gmsh написан на c++. Скорее всего оттуда можно много чего взять вообще без переделок.

----- добавлено через 31 сек. -----

Сообщение от румата только не proxy. это все погубит

согласен. Это на крайний случай.