[nickname2019]

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

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

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

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

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

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

[nickname2019]

Сообщение от radistMorze В принципе на гитхабе есть открытые проекты, которые сейчас пишутся. Например калькулятор сечений НДМ: https://github.com/RedikultsevEvg/StructureHelper Это не мкэ, но в целом уже готовая программа с нужным функционалом

Есть проблема выбора "донора". Обсуждали выше. Есть проекты более высокой степени готовности.

[radistMorze]

По мкэ для жб видел один проект открытый. Там программа скорее как приложение к книге написано, но функционал удивляет. По сути открытая реализация Idea Statica Concrete
https://concrete-fem.com/download/
Дописать мешер, графическую оболочку и в целом готово=)

[nickname2019]

Сообщение от radistMorze По мкэ для жб видел один проект открытый. Там программа скорее как приложение к книге написано, но функционал удивляет. По сути открытая реализация Idea Statica Concrete https://concrete-fem.com/download/ Дописать мешер, графическую оболочку и в целом готово=)

Графическая оболочка есть - автокад. Мешер - gmsh. В кучу только собрать надо.

[Gustavson]

Сообщение от nickname2019 Проблематику на данный момент вижу так: 1. Для расчетного ПО нужен скриптовый язык. 2. Для скриптового языка нужен компилятор с возможностью отладки. 3. Скриптовый язык должен позволять коллективную разработку. 4. Коллективная разработка должна иметь возможность автоматически отслеживать авторство кода построчно (наличия форков недостаточно). Т.е. если человек изменил строку кода - общество должно знать, кто это сделал и почему. 5. Разработчики должны иметь возможность влиять на развитие продукта, поэтому нужен рейтинг полезности разработчиков при голосованиях через учет "кармы". Карма разработчика учитывается через подсчет строк созданного им кода.

сначала по пп. 3-5: чем вас не устраивает какая-нибудь система управления версиями типа github, gitlab и т.п.?

теперь по пп. 1-2: В каком смысле нужен? Для разработки самого ПО или для работы в нем? По всей видимости имеется в виду разработка. Существует множество готовых языков, нет никаких проблем для их использования. Тот же python нынче в трендах. Можно взять Tcl или один из диалектов Lisp вроде Scheme, Guile.
Или вы хотите разработать сам язык и сделать интерпретатор под него, что-то вроде APDL для ансиса? Если так, то можно ставить сразу крест на всем проекте.

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

Что то вроде OpenSCAD? Не уверен что это удобно, лучше работу с геометрией организовать кнопками на интерфейсе пользователя, хоткеи, может быть предусмотреть что-то типа шаблонов

[nickname2019]

Сообщение от Gustavson сначала по пп. 3-5: чем вас не устраивает какая-нибудь система управления версиями типа github, gitlab и т.п.?

Устраивает до момента, пока не отключат.

Сообщение от Gustavson теперь по пп. 1-2: В каком смысле нужен? Для разработки самого ПО или для работы в нем? По всей видимости имеется в виду разработка. Существует множество готовых языков, нет никаких проблем для их использования. Тот же python нынче в трендах. Можно взять Tcl или один из диалектов Lisp вроде Scheme, Guile.

Сергей812 прав. Не нужно никакие скрипты приплетать на этапе разработки ядра.

Сообщение от Gustavson Или вы хотите разработать сам язык и сделать интерпретатор под него, что-то вроде APDL для ансиса? Если так, то можно ставить сразу крест на всем проекте.

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

Сообщение от Gustavson Что то вроде OpenSCAD? Не уверен что это удобно, лучше работу с геометрией организовать кнопками на интерфейсе пользователя, хоткеи, может быть предусмотреть что-то типа шаблонов

Пока толком не заработает, публиковать не хочу.

[radistMorze]

OpenScad звучит довольно тяжеловесно. Небольшой 2d/3d редактор проще наверно свой написать.
Последние полгода делаю небольшой pet-проект, графику пишу на opengl, в целом все красиво выводится. Планирую в таком же стиле добавить простые инструменты редактирования, импорт dxf
https://github.com/radistMorze-constr/FEMmini

[nickname2019]

Сообщение от radistMorze OpenScad звучит довольно тяжеловесно. Небольшой 2d/3d редактор проще наверно свой написать. Последние полгода делаю небольшой pet-проект, графику пишу на opengl, в целом все красиво выводится. Планирую в таком же стиле добавить простые инструменты редактирования, импорт dxf https://github.com/radistMorze-constr/FEMmini

Не, ну круто. Только написание нормального графического редактора сожрет 99% ресурсов. Имхо, овчинка с графикой не стоит выделки.
Схему можно импортировать из текстового файла схемы SCAD или Лиры, а сосредоточится на написании расчетного кода.
Я может попозже подтянусь, попробую решить задачу генерации сетки в Автокаде и вывод ее в формате SCADа в txt.

У меня висят в работе два монолитных домика с кучей стен. Так и так придется что-то кумекать по быстрой генерации сетки. Руками я буду дольше мучиться.

[veb86]

Я электрик-слаботочник. Хочу тоже поделится своим взглядом на проблему множественных расчетов.
В конце прошлого года, я открыл для себя такую связку CAD -> EXCEL -> CAD. В нашем опенсоурсном CADе уже давно была реализована система автоматической укладки кабелей и получение модели(дерева) соединений(типа диспетчер инженерных систем из ревита). Имея полную взаимосвязь всех электрических устройств объекта, я сразу кинулся реализовать все расчеты внутри КАДа, что оказалось ошибкой. Вывод который я сделал, то что подходит для черчения, не значит что подойдет для расчетов. Уныние, грусть, и дальше поиск решения, ну и как результат прозрение. Основываясь на модели(дереве) соединений из CAD, я выполняю генерацию эксельки. Причем спец команд, которые задают правила генерации эксельки не много (есть большая вероятность увеличения их количества). Пока генератор в стадии разработки, но один проект сдал, использовал свой генератор. Во время разработки проекта выявлены недостатки (надо сохранять все коэффициенты между перегенерациями, сейчас этим занимаюсь), концепция теперь меняется CAD<->EXCEL. Я прям доволен данной связкой. Писать расчеты в Экселе большинство умеет, плюс эксель позволяет легко вместить в себя большой структурированный расчет и пересчитывать его на лету. Я понимаю, что Эксель упирается в потолок в определенных местах, но используя язык Pascal, я могу выполнить промежуточную или пост обработку так, как мне надо. Сейчас делаю генератор для электрики, но вижу, что он так же подойдет для слаботочки СКС, ОПС, ЭТ, ЧС и прочее

Вывод:
Я предлагаю Вам подумать над связкой CAD<->EXCEL, причем именно генерации Эксель(без ручного переноса данных). Я не конструктор, Ваших расчетов я не знаю.
Наш опенсоурсный кад по сути это 2д ревит. И конечно, в будущем алгоритмы генерации планирую перетянуть в ревит. Очень хотелось бы тоже найти команду энтузиастов, но за годы поисков понял что главным спонсором разработки буду я сам, тратить свое собственное время.

На рисунки результат вывода информации из эксель обратно в КАД

[nickname2019]

Сообщение от veb86 Я предлагаю Вам подумать над связкой CAD<->EXCEL, причем именно генерации Эксель(без ручного переноса данных). Я не конструктор, Ваших расчетов я не знаю. Наш опенсоурсный кад по сути это 2д ревит. И конечно, в будущем алгоритмы генерации планирую перетянуть в ревит. Очень хотелось бы тоже найти команду энтузиастов, но за годы поисков понял что главным спонсором разработки буду я сам, тратить свое собственное время.

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

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

[veb86]

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

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

[nickname2019]

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

Спасибо за мнение. Кто-то считает в экселе. Я с института считал в маткаде, поэтому эксель вообще не знаю. Проблема расчетов в экселе (и с маткадом) - их практически невозможно объединить в единую систему с графикой для более-менее сложных объектов (я рисую, и что-то автоматически считается).
А Вы не работали с #Net сборками или objectarx?
А с динамическими блоками у Вас в электрике как? Используете их?

[veb86]

Сообщение от nickname2019 А Вы не работали с #Net сборками или objectarx?

C# знаю постольку поскольку. Могу обращаться к объектам на чертеже и считывать с них данные, ну и соответственно обрабатывать информацию.
objectarx - С++, не пробовал, напрягла сложность. Да и потом нашел опенсоурсный КАД...

Сообщение от nickname2019 А с динамическими блоками у Вас в электрике как? Используете их?

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

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

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

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