[nickname2019]

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

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

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

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

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

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

[trir]

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

совместимость с Autocad 2015 обеспечит подключение соответствующего SDK, а не версия VS
писать в древней версии VS - плохая идея

[veb86]

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

Без разработки своих объектов, мне кажется не обойтись, так что смеритесь. С++ отличное решение

[румата]

Сообщение от nickname2019 Плюс производительность здесь будет узким местом.

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

[Нубий-IV]

Сообщение от nickname2019 Для обозначения марки бетона/стали - пусть будут слои.

У меня так скрипт экспорта в Старк из Нанокада устроен. Толщина/высота в свойствах объекта зашиты, а остальное, что не влезло - в слои. Мой список слоев в результате выглядит так:

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

[nickname2019]

Сообщение от trir совместимость с Autocad 2015 обеспечит подключение соответствующего SDK, а не версия VS писать в древней версии VS - плохая идея

SDK для Autocad 2016 и 2015 подключается только к Visual Studio 2012. Разработку можно вести в более новых версиях самой студии, но на компьютере обязательно должна стоять Visual Studio 2012 - тогда можно выбирать версию компилятора.
Т.е. Вы можете править код в любой версии студии, но придется выбрать старую версию компилятора (я так думаю, может еще с настройками придется повозиться).

[румата]

Сообщение от Нубий-IV Кто хочет себе так же - пусть никогда не создает собственные объекты. Миниатюры

Ну для чего собственные proxy в решателе? Расширенных данных(XData) для вывода в автокад не хватает?

[nickname2019]

Сообщение от Нубий-IV У меня так скрипт экспорта в Старк из Нанокада устроен. Толщина/высота в свойствах объекта зашиты, а остальное, что не влезло - в слои. И это я еще не все параметры туда затолкал, из тех, что хочется. Бедный нанокад тормозит, просто открывая список этих слоев. А фильтры слоев его иногда вообще роняют. Даже скопировать нагрузки с этажа на этаж - и то проблема в такой каше. Кто хочет себе так же - пусть никогда не создает собственные объекты.

Есть секрет - пишете в имени слоя "Перекрытие тип 1", а параметры перекрытия описываете в отдельном файле, к которому подключаетесь при необходимости. Т.е. все параметры в имя слоя не обязательно заносить.

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

Сообщение от румата Ну для чего собственные proxy в решателе? Расширенных данных(XData) для вывода в автокад не хватает?

Это может пригодиться для удобства ввода-вывода. Собственно, проект можно делать на нескольких языках.

[Нубий-IV]

Сообщение от румата Расширенных данных(XData) для вывода в автокад не хватает?

Их же еще и просматривать/редактировать надо в удобном виде. Скрыть по этажам. Или раскрасить нагрузки по шкале. Или выбрать все элементы с шарнирами в первом узле. Да даже поворот сечения в стержне проконтролировать. И т.д. и т.п. Как это сделать, если работать палочками в автокаде? На эту тему тут сколько срачей было "как удобно пользовательские свойства в автокаде реализовать?" и "как пользователю использовать XData?". Нашли решение? Если нашли - пусть будет XData.

Сообщение от nickname2019 "Перекрытие тип 1"

Этого мало. Например, в одном перекрытии есть участки с разными размерами сетки, разными координатами начала сетки, и разными углами поворота сетки (я так чистую сетку вокруг колонн делаю). Одно это превращает единственный тип в два десятка разных. И вместо того, чтобы ткнуть в участок, и посмотреть/исправить его характеристики, я вынужден эту городильню со слоями разводить (они, сволочи, даже в ширину списка не влазят, только на панели свойств, растянутой в пол-экрана, можно посмотреть полное название слоя). А если я вместо списка параметров буду шифровки "Тип 362" и "Тип 566" писать, мне еще придется блокнот заводить. Программа-то может по имени в посторонние файлы заглядывать, а для пользователя это издевательство получается.

[румата]

Сообщение от nickname2019 SDK для Autocad 2016 и 2015 подключается только к Visual Studio 2012.

Вы наверно имеете в виду плагин под VS для автоматического создания проекта под расширение ObjectARX. Это пустяк. Не стОит из-за этого использовать дренюю VS

[trir]

SDK для Autocad 2016 и 2015 подключается только к Visual Studio 2012. Разработку можно вести в более новых версиях самой студии, но на компьютере обязательно должна стоять Visual Studio 2012 - тогда можно выбирать версию компилятора.

жесть, ещё бы узнать совместимость ObjectArx для разных версий AutoCAD

[румата]

Сообщение от trir жесть, ещё бы узнать совместимость ObjectArx для разных версий AutoCAD

Библиотеки решателя в принципе нельзя завязывать на автокад. это тупиковый путь. потом все равно прийдется развязывать

[lenivec]

----- добавлено через ~2 мин. -----
Нет, не то. Это все геометрическоие параметризаторы.

Надо вывести текст, например в таблицу? Думаю, в Dynamo это можно реализовать, в Ревите же спецификации есть. Написать чистый код на Python? Точно есть, можно блоки кода вставлять.
А уж геометрическая (графическая) модель нужна точно. И хорошо, что параметризуемая. Если еще концепт с openBIM завязать, то вообще круто будет.

[nickname2019]

Сообщение от trir жесть, ещё бы узнать совместимость ObjectArx для разных версий AutoCAD

Acad|Studio
2021 Visual Studio 2019 v.16.0
2020 Visual Studio 2017 (Platform Toolset: Visual Studio 2017 (v141)) v.15.7
2019 Visual Studio 2017 (Platform Toolset: Visual Studio 2017 (v141)) v.15.3
2018 Visual Studio 2015
2017 Visual Studio 2015
2016 Microsoft Visual Studio 2012 (Update 4)
2015-
2016 Microsoft® Visual Studio® 2012 (Update 4)
2014 2010 SP1
2014 2010 SP1
2012 2008 SP1
2011,
2012 2008 SP1

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

Сообщение от румата Библиотеки решателя в принципе нельзя завязывать на автокад. это тупиковый путь. потом все равно прийдется развязывать

Библиотеки решателя мы ни в коем случае не будет завязывать на Autocad (описание типов будет свое).
Autocad - только как графический редактор для ввода и вывода.

[румата]

Сообщение от Нубий-IV Их же еще и просматривать/редактировать надо в удобном виде.

Ну так команды в виде ObjectARX расширеня для этого написать. Это верно. Но только не решатель в виде .arx

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

Сообщение от nickname2019 2021 Visual Studio 2019 v.16.0 2020 Visual Studio 2017 (Platform Toolset: Visual Studio 2017 (v141)) v.15.7 2019 Visual Studio 2017 (Platform Toolset: Visual Studio 2017 (v141)) v.15.3 2018 Visual Studio 2015 2017 Visual Studio 2015 2016 Microsoft Visual Studio 2012 (Update 4) 2015- 2016 Microsoft® Visual Studio® 2012 (Update 4) 2014 2010 SP1 2014 2010 SP1 2012 2008 SP1 2011, 2012 2008 SP1

Ну это уж действительно слишком. net-плагины можно создавать в любой версии VS под любую версию ACAD

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

Сообщение от lenivec Надо вывести текст, например в таблицу? Думаю, в Dynamo это можно реализовать, в Ревите же спецификации есть. Написать чистый код на Python? Точно есть, можно блоки кода вставлять. А уж геометрическая (графическая) модель нужна точно. И хорошо, что параметризуемая. Если еще концепт с openBIM завязать, то вообще круто будет

Как это все поможет эффективному формированию глобальной матрицы жесткости рассчитываемой системы?

[nickname2019]

Сообщение от румата Ну это уж действительно слишком. net-плагины можно создавать в любой версии VS под любую версию ACAD

Если писать расчетные модули на c++, то отлаживать тоже лучше на c++.
А распространяемую программу тогда лучше делать на шарп с подключением dll на c++.

[румата]

Сообщение от nickname2019 Если писать расчетные модули на c++, то отлаживать тоже лучше на c++. А распространяемую программу тогда лучше делать на шарп с подключением dll на c++.

Верно. Ядро на плюсах, обертки на шарпе и питоне

[lenivec]

Сообщение от румата Как это все поможет эффективному формированию глобальной матрицы жесткости рассчитываемой системы?

Создаете элементы с заданными параметрами, соединяете их связями. Остальное - дело кода.

[румата]

Сообщение от lenivec Создаете элементы с заданными параметрами, соединяете их связями. Остальное - дело кода.

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

[trir]

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

[nickname2019]

Сообщение от lenivec Создаете элементы с заданными параметрами, соединяете их связями. Остальное - дело кода.

Когда ядро gmsh перепишут на dynamo - вот тогда и посмотрим. Визуальный язык - это пока не совсем то, что нужно.