[nickname2019]

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

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

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

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

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

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

[trir]

Qt разрешает его использование в open source проектах?

да, там gpl3

[veb86]

Сообщение от derik он кроссплатформенный

Круто, автокад не кроссплатформен, зато библиотека для него кросплатформенна

[румата]

Сообщение от trir да, там gpl3

Это хорошо. Если кто-то надумает писать собственный интерфейс к решателю(которого еще нет) - вариант построения его на фрэймворке Qt будет, наверно, оптимальным.

[dambra]

Я бы тоже был за использование Qt если бы не:
1. У Qt свои специф. классы, т.е. не все могут писать на нем без освоения документации, хотя странно что кто-то пишет на С++ и не знает Qt. Вся идея то - кроссплатформенность?
2. О какой кроссплатформенности идет речь если пишется по AutoCad? Под Мак что-ли? Т.е. смысла нет писать под программу на винде и думать о кроссплатформенности.

[DEM]

Эх ребята..
Если уж автоматизировать то автоматизировать нужно наверное сперва самые простые задачи.
типа расчетов стальных и металлических балок, с формированием расчета сечений и т.е.
Причем разбить это на соответствующие этапы.
1. Определение усилий (модуль 1)
2. Расчет сечений(модули ЖБ/КМ)
3. Расчет по 2му предельному состоянию.
При этом нужна какая то общая платформа для вывода информации в текстовый вид.

По поводу GMSH идея конечно хорошая, но простые здания или многоэтажки, делать сетку проще по старинке в СКАДе, я уже прошел этот путь...
Если нацинаешь экспортировать из Автокада в GMSH появляются не связанные грани, балки которые в уровне перекрытий могут быть не связаны с сеткой и т.е.
Это все можно решить, но нужно определить в каком уровне стержень находится, определить компланарность и включить его в этот суфрейс и т.е.
Для себя я решил GMSH применяю только для формирования сеток сложных поверхностей, где не получается с помощью стандартных методов.
Так же его можно применять для визуализации расчетов.
Например выгрузить данные из СКАДа сформировать msh файл с результатами армирования и потом создать сразу несколько картинок армирования за раз...
Но вот с отображением моментов в КЭ схемах у GMSH беда, он не может отображать в классическом виде эпюры армирования.

[nickname2019]

Сообщение от DEM Эх ребята.. Если уж автоматизировать то автоматизировать нужно наверное сперва самые простые задачи. типа расчетов стальных и металлических балок, с формированием расчета сечений и т.е. Причем разбить это на соответствующие этапы. 1. Определение усилий (модуль 1) 2. Расчет сечений(модули ЖБ/КМ) 3. Расчет по 2му предельному состоянию. При этом нужна какая то общая платформа для вывода информации в текстовый вид.

К понедельнику я планирую создать несколько проектов для разных версий студий (без мфс и прочего) и загружу на гитхаб.
Те, кто захотят поучаствовать смогут разрабатывать отдельные модули независимо с синхронизацией через GitHub.
Для разработки расчетных функций проверки сечений глубоких знаний с++ не требуется. Объектно-ориентированное программирование предусматриваться не будет (задачи простые, ооп только все запутает).
Т.е. это будет старое доброе функциональное процедурное программирование.

Разработка функций проверки элементов может идти параллельно с разработкой функционала решателя. Достаточно разработать функцию с набором входных параметров (РСУ, тип сечения и т.д.), которая проверяет сечение.
Эту функцию потом можно приаттачить к основному проекту или использовать отдельно.

Чтобы не путаться в коде, названия функций, видимо, нужно делать по номеру СП+ номер пункта СП и номера формулы, которая автоматизируется.
Если есть желание автоматизировать на VB или еще на чем-то - можно делать dll, там объявлять функцию как экспортируемую и эту dll подключать к основному проекту.
Но это не рекомендуется.

Также попробую загрузить каталоги проката, которые у меня есть (площади, размеры сечений, графика в файлах и т.д.).

По поводу GMSH идея конечно хорошая, но простые здания или многоэтажки, делать сетку проще по старинке в СКАДе, я уже прошел этот путь... Если нацинаешь экспортировать из Автокада в GMSH появляются не связанные грани, балки которые в уровне перекрытий могут быть не связаны с сеткой и т.е. Это все можно решить, но нужно определить в каком уровне стержень находится, определить компланарность и включить его в этот суфрейс и т.е.

Я думаю, что разберемся.

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

У нас есть графический редактор из-под которого мы пишем. В нем и визуализируем.

Например выгрузить данные из СКАДа сформировать msh файл с результатами армирования и потом создать сразу несколько картинок армирования за раз... Но вот с отображением моментов в КЭ схемах у GMSH беда, он не может отображать в классическом виде эпюры армирования.

Я думаю, нужно попытаться вообще избавиться от кнопок "экспорт" и "импорт", все должно работать из одной среды.

[trir]

это будет старое доброе функциональное программирование

ты путаешь, это Структурное программирование

[nickname2019]

Сообщение от trir ты путаешь, это Структурное программирование

Спасибо. Я неверно выразился.
Я имел ввиду процедурное программирование
Частным случаем которого, видимо, является структурное программирование.

[DEM]

Так ты мне обьясни пожалуйста...
1. Ты хочешь заменить СКАД и поиметь свой блэкджек с прочими атрибутами?
2. Ты просто хочешь иметь систему из которой можно спокойно выгружать в СКАД/ЛИРУ/РОБОТ?

[zamtmn]

>>К понедельнику я планирую создать несколько проектов для разных версий студий (без мфс и прочего) и загружу на гитхаб.
10 страниц до создания файлов проектов?
топик обещает быть длиннее предыдущего))

>>Т.е. это будет старое доброе функциональное процедурное программирование.
а нахрена с++? стильно модно молодежно?

[nickname2019]

Сообщение от zamtmn >>К понедельнику я планирую создать несколько проектов для разных версий студий (без мфс и прочего) и загружу на гитхаб. 10 страниц до создания файлов проектов? топик обещает быть длиннее предыдущего))

Лучше 10 страниц обсуждения потом несколько дней на создание кода, чем пять минут обсуждения и тысячи страниц кода в мусор. По ветке можно отследить как менялась концепция от самостоятельной разработки проекта до выбора "доноров" с открытым исходным кодом.
Также мы решили отказаться от mfc (пока так пусть будет). Т.е. концепция реально является продуктом коллективного творчества.

Сообщение от zamtmn >>Т.е. это будет старое доброе функциональное процедурное программирование. а нахрена с++? стильно модно молодежно?

Надежно, функционально, масштабируемо, по-стариковски. Большинство нормальных программ (в т.ч. с открытым исходным кодом, математические библиотеки, генераторы сеток, автокады, нанокады и т.д.) написаны на с++.

[DEM]

Повторяю...
Какая конечная цель???
Своя расчетная программа аналог СКАД/ЛИРА и т.п.?

[zamtmn]

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

>>По ветке можно отследить как менялась концепция
есть коммиты, есть коменты к коммитам. отслеживать надо по ним, а не по мусору на форуме

>>Также мы решили отказаться от mfc (пока так пусть будет).
эти решения ничего не стоят. решать надо реальные проблемы

>>Т.е. концепция реально является продуктом коллективного творчества.
Современное извращенное понимание как творчества, так и коллективного

>>Надежно, функционально, масштабируемо, по-стариковски. Большинство нормальных программ (в т.ч.
Делай на том на чем умеешь, а не на в трендах. Так будет лучше, если ты не проф программист

[румата]

Сообщение от DEM Своя расчетная программа аналог СКАД/ЛИРА и т.п.?

Да, своя открытая библиотека для расчетов по МКЭ

[DEM]

Так твои расчеты ни одна экспертиза не примет.

[румата]

Сообщение от DEM Так твои расчеты ни одна экспертиза не примет.

Это еще почему?

[DEM]

О господи!
Господа вы бы хотя бы узнали бы что программа должна иметь сертификаты.
Пройти верификационные тесты и т.е.

[nickname2019]

Сообщение от DEM О господи!Господа вы бы хотя бы узнали бы что программа должна иметь сертификаты.Пройти верификационные тесты и т.е.

Спасибо за вопрос. Можно оформлять расчеты в виде примерно вот такого отчетика прямо в формате dwg (см. вложение). Даже, пожалуй, так и нужно оформлять.
Реализация очень простая - делается шаблон с именами переменных, который заполняется значениями после расчета.
Кроме того, на программу можно получить сертификат.
Сертификат получить явно не сложнее, чем написать код.

[румата]

Сообщение от DEM Господа вы бы хотя бы узнали бы что программа должна иметь сертификаты.

Сертификаты выдаются только на соответсвие нормам РФ в части конструктивных расчетов. К математике вычисления усилий эти сертификаты никакого отношения не имеют.

Сообщение от DEM Пройти верификационные тесты и т.е.

Ничего не мешает любой гипотетической открытой библиотеке пройти набор верификационных тестов. Но, повторюсь, ничего общего с сертификатом, которые выдаются на строительное ПО такая верификация не имеет.

[Сергей812]

Сообщение от zamtmn запал кончится уже тут, на форуме))

мой вопрос про

Сообщение от Сергей812 Техзадание опосля напишите?

был проигнорирован, похоже.. Ребята настолько увлеклись "чтобы было все по взрослому" (под все версии, на каком языке чтобы было круче, ветки, коммиты), что забыли - любая совместная работа начинается с ТЗ в том или ином виде: чтобы было понятно - кто что делает и чего другие участники ожидают увидеть в конечном итоге. И все это должно быть сведено в один документ - а не "размазано" по десяткам постов...