Реклама i
Стань нашим партнером - зарабатывай с нами!
| Правила | Регистрация | Пользователи | Поиск | Сообщения за день | Все разделы прочитаны |  Справка по форуму | Файлообменник |

Вернуться   Форум DWG.RU > Программное обеспечение > Программирование > Как создать расчетное программное обеспечение с открытым исходным кодом (конструктивные решения)

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

Ответ
Поиск в этой теме
Непрочитано 24.09.2021, 14:52
Как создать расчетное программное обеспечение с открытым исходным кодом (конструктивные решения)
nickname2019
 
Регистрация: 18.11.2019
Сообщений: 1,492

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

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

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

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

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

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

Последний раз редактировалось nickname2019, 06.10.2021 в 09:07.
Просмотров: 84271
 
Непрочитано 27.09.2021, 10:12
#101
zamtmn

КИПиА
 
Регистрация: 21.03.2005
Tyumen
Сообщений: 1,352
<phrase 1=


Цитата:
Сообщение от румата Посмотреть сообщение
ну это ж не лиспик по изменению цвета слоя. без детального обсуждения стратегии и нюансов такой опенсорс создать не получится
тут нужен опыт, опыт можно получить только одним способом.

Вообще очень странно пытатся делать опенсорс обмазовшись со всех сторон проприетарным дорогущим софтом. не получится
zamtmn вне форума  
 
Непрочитано 27.09.2021, 10:16
#102
Нубий-IV

Инженер-философ
 
Регистрация: 24.04.2019
Хабаровск
Сообщений: 1,868


Цитата:
Сообщение от trir Посмотреть сообщение
совместимость ObjectArx для разных версий AutoCAD
Я игрался в ObjectARX, слепил несколько простейших команд типа суммы объемов, на прошлой работе. Акадов там был зоопарк - от 2008 до 2016. Никаких изменений в исходники для сборки под разные версии вносить не приходилось, только перенастроить проект. Что было создано под 2008 - собралось и под все версии до 2019, и под x32, и под x64.

Были только легкие пляски с бубном при настройке. Например, одна из версий была завязана на библиотеки MFC, а в бесплатной студии их не было - там помогло просто объявить несколько переменных, на которые линкер искал ссылки. Или для сборки версии 2008 в более поздних студиях я подменял в заголовке DLL версию линкера, чтобы автокад разрешил загрузку. Но это все не касалось кода.

Просто SDK для определенной версии акада требует определенную версию студии, иначе при компиляции будут сплошные ошибки в заголовках самого SDK, они там постоянно от новых компиляторов новые фишки тянут, видимо. И статические библиотеки в составе SDK соответствующей версией линкера собраны. При этом в справке по SDK в каждой новой версии есть раздел про новое и удаленное старое. Если залезть глубоко, возможно и в коде придется разные версии делать, но на уровне создания простых пользовательских команд я с этим не столкнулся.
Нубий-IV вне форума  
 
Непрочитано 27.09.2021, 10:16
#103
румата


 
Регистрация: 06.04.2015
Сообщений: 2,673


Цитата:
Сообщение от zamtmn Посмотреть сообщение
тут нужен опыт, опыт можно получить только одним способом.
конечно нужен. но опыт тоже разный бывает. не хочется сразу ехать мордой поасфальту, когда для этого скорей всего уже есть готовые колеса.
румата вне форума  
 
Автор темы   Непрочитано 27.09.2021, 10:18
#104
nickname2019


 
Регистрация: 18.11.2019
Сообщений: 1,492


Цитата:
Сообщение от zamtmn Посмотреть сообщение
тут нужен опыт, опыт можно получить только одним способом.Вообще очень странно пытатся делать опенсорс обмазовшись со всех сторон проприетарным дорогущим софтом. не получится
По итогам обсуждений:
1. Делается опенсурсная расчетная библиотека,которую можно приаттачить к любому проекту.
2. Для визуализации, разработки и отладки используется самый популярный граф. редактор - autocad. Это позволяет вовлечь в отладку и тестирование максимальное количество людей.
3. С учетом сложившейся ситуации, исходный код, написанный даже под Autocad несложно портировать на Nanocad, Bricscad и т.д.
4. Т.е. проект не привязывается с софту, а только его использует.

----- добавлено через ~6 мин. -----
Цитата:
Сообщение от Нубий-IV Посмотреть сообщение
Если залезть глубоко, возможно и в коде придется разные версии делать, но на уровне создания простых пользовательских команд я с этим не столкнулся.
Да. Блин, я вспомнил. Требования к строгости кода менялось в новых версиях студии. Кажется типы стали объявляться более строго.
Видимо, по ходу разработки код нужно периодически тестировать на соответствие новым версиям студии.

Не хочется писать для новых автокадов, так как привлекаемое сообщество уменьшится.

Последний раз редактировалось nickname2019, 27.09.2021 в 10:25.
nickname2019 вне форума  
 
Непрочитано 27.09.2021, 10:25
#105
румата


 
Регистрация: 06.04.2015
Сообщений: 2,673


Цитата:
Сообщение от nickname2019 Посмотреть сообщение
Видимо, по ходу разработки код нужно периодически тестировать на соответствие новым версиям студии.
Вот дался вам это арх. Зачем такие сложности для ввода-вывода?
румата вне форума  
 
Автор темы   Непрочитано 27.09.2021, 10:27
#106
nickname2019


 
Регистрация: 18.11.2019
Сообщений: 1,492


Цитата:
Сообщение от румата Посмотреть сообщение
Вот дался вам это арх. Зачем такие сложности для ввода-вывода?
Расчетную библиотеку на c++ удобно отлаживать при подключении ее к оболочке на objectarx, так как objectarx тоже использует c++. Готовую библиотеку лучше "обернуть" через c#.
nickname2019 вне форума  
 
Непрочитано 27.09.2021, 10:29
#107
румата


 
Регистрация: 06.04.2015
Сообщений: 2,673


Цитата:
Сообщение от nickname2019 Посмотреть сообщение
Расчетную библиотеку на c++ удобно отлаживать при подключении ее к оболочке на objectarx, так как обе написаны на c++.
тогда сразу нужно и ядро писать и обертки

----- добавлено через ~1 мин. -----
лично мне удобнее для тестирования будут .net dll расширения
румата вне форума  
 
Автор темы   Непрочитано 27.09.2021, 10:31
#108
nickname2019


 
Регистрация: 18.11.2019
Сообщений: 1,492


Цитата:
Сообщение от румата Посмотреть сообщение
тогда сразу нужно и ядро писать и обертки
Расчетный код на c++ будет намного быстрее + его можно скопипастить из gmsh. Математику нужно писать на c++, может быть с применением ассемблера на перспективу.
Цитата:
Сообщение от румата Посмотреть сообщение
лично мне удобнее для тестирования будут .net dll расширения
надо подумать, как это сразу сделать.
nickname2019 вне форума  
 
Непрочитано 27.09.2021, 10:40
#109
румата


 
Регистрация: 06.04.2015
Сообщений: 2,673


Цитата:
Сообщение от nickname2019 Посмотреть сообщение
Расчетный код на c++ будет намного быстрее...
На самом деле очень не намного быстрее, если не параллелить алгоритмы решения и использовать математику уже в виде оберток над готовыми фортрановскими мат. библиотеками
румата вне форума  
 
Автор темы   Непрочитано 27.09.2021, 11:00
#110
nickname2019


 
Регистрация: 18.11.2019
Сообщений: 1,492


Цитата:
Сообщение от румата Посмотреть сообщение
На самом деле очень не намного быстрее, если не параллелить алгоритмы решения и использовать математику уже в виде оберток над готовыми фортрановскими мат. библиотеками
Мультифронтальный метод решения надо запускать в нескольких потоках (по количеству физических процессоров).
nickname2019 вне форума  
 
Непрочитано 27.09.2021, 11:09
#111
румата


 
Регистрация: 06.04.2015
Сообщений: 2,673


Цитата:
Сообщение от nickname2019 Посмотреть сообщение
Мультифронтальный метод решения надо запускать в нескольких потоках (по количеству физических процессоров).
Главное, что б для этого знаний хватило. У меня вот точно не хватит знаний для многопоточного программирования на С++
румата вне форума  
 
Автор темы   Непрочитано 27.09.2021, 11:24
#112
nickname2019


 
Регистрация: 18.11.2019
Сообщений: 1,492


Цитата:
Сообщение от румата Посмотреть сообщение
Главное, что б для этого знаний хватило. У меня вот точно не хватит знаний для многопоточного программирования на С++
Я думаю, что цели нужно сразу ставить серьезные, а там как пойдет.
nickname2019 вне форума  
 
Непрочитано 27.09.2021, 11:29
#113
румата


 
Регистрация: 06.04.2015
Сообщений: 2,673


Цитата:
Сообщение от nickname2019 Посмотреть сообщение
Я думаю, что цели нужно сразу ставить серьезные, а там как пойдет.
А я думаю нужно использовать готовые библиотеки для эффективного решения СЛАУ. SciPy, Math.Net и пр.

----- добавлено через ~6 мин. -----
Пусть они немного медленне будут работать чем нативный си. но так будет сэкономлена уйма времени на разработку

Последний раз редактировалось румата, 27.09.2021 в 11:36.
румата вне форума  
 
Автор темы   Непрочитано 27.09.2021, 11:59
#114
nickname2019


 
Регистрация: 18.11.2019
Сообщений: 1,492


Цитата:
Сообщение от румата Посмотреть сообщение
А я думаю нужно использовать готовые библиотеки для эффективного решения СЛАУ. SciPy, Math.Net и пр.----- добавлено через ~6 мин. -----
Пусть они немного медленне будут работать чем нативный си. но так будет сэкономлена уйма времени на разработку
Надо будет протестировать. Разница во времени может быть огромна. c++ библиотек тоже много.
nickname2019 вне форума  
 
Непрочитано 27.09.2021, 12:03
#115
румата


 
Регистрация: 06.04.2015
Сообщений: 2,673


Цитата:
Сообщение от nickname2019 Посмотреть сообщение
Надо будет протестировать. Разница во времени может быть огромна.
Я уже тестировал. Нет там никакой огромной разницы. Все эти библиотеки по сути обертки над давнишними фортрановскими библиотеками. По моим тестам OpenBLAS был самым медленным. .net обертка над IntelMKL, SCiPy/NumPy. Julia примерно одинаково по скорости работают.

----- добавлено через ~10 мин. -----
http://fseps.blogspot.com/2017/02/blog-post.html

Последний раз редактировалось румата, 27.09.2021 в 12:25.
румата вне форума  
 
Непрочитано 27.09.2021, 12:19
#116
румата


 
Регистрация: 06.04.2015
Сообщений: 2,673


Вот графики сравнения
Миниатюры
Нажмите на изображение для увеличения
Название: Безымянный.png
Просмотров: 65
Размер:	114.1 Кб
ID:	241119  
румата вне форума  
 
Автор темы   Непрочитано 27.09.2021, 12:32
#117
nickname2019


 
Регистрация: 18.11.2019
Сообщений: 1,492


Цитата:
Сообщение от румата Посмотреть сообщение
Вот графики сравнения
https://gitlab.com/libeigen/eigen
Вроде у них были решения для разреженных матриц (чтобы не оптимизировать нумерацию узлов и не уменьшать размер ленты).
Также подозреваю, что они матрицы раскладывают с использованием видеокарты.
nickname2019 вне форума  
 
Непрочитано 27.09.2021, 12:35
#118
румата


 
Регистрация: 06.04.2015
Сообщений: 2,673


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

----- добавлено через ~22 мин. -----
Цитата:
Сообщение от nickname2019 Посмотреть сообщение
Также подозреваю, что они матрицы раскладывают с использованием видеокарты.
Видеокарты, реально ускоряющие решение на числах с плавающей запятой двойной точности стОят непомерно дорого. Не стОит этим обольщаться.
румата вне форума  
 
Непрочитано 27.09.2021, 13:34
#119
veb86

Проектировщик электрических сетей
 
Регистрация: 17.01.2014
Пенза
Сообщений: 176


Цитата:
Сообщение от румата Посмотреть сообщение
Цитата:
Сообщение от nickname2019 Посмотреть сообщение
Плюс производительность здесь будет узким местом.
Если вы будете одни-единственным разработчиком этого решателя, то все в порядке. Иначе помощников в написании будет крайне трудно отыскать
nickname2019 - я думаю туда надо просто смерится и принять, что в итоге все равно тебе одному все пилить придется) ты кашу заварил, тебе и кушать. Никогда не работал с с++, но знаю точно, что возможностей во много больше.
Цитата:
Сообщение от Нубий-IV Посмотреть сообщение
Толщина/высота в свойствах объекта зашиты, а остальное, что не влезло - в слои. Мой список слоев в результате выглядит так:
Спасибо за демонстрацию. Вот такой ужас мне один раз приходилось наблюдать в слоях. Это тот случай когда все завязывается на масштаб, вес, цвет, слой, шрифт...
Цитата:
Сообщение от румата Посмотреть сообщение
Главное, что б для этого знаний хватило. У меня вот точно не хватит знаний для многопоточного программирования на С++
Страшно представить какие вы задачи (математика высшего уровня) решили решать, если вам понадобилась многопоточности...

У Вас уже команда собралась. румата пускай решает одну задачу на С#, а nickname2019 на С++. Потом как румата решит nickname2019 перепишет на С++ или наоборот. Языки очень похожи. И вообще мне кажется основной проблемой и там где реально придется по шевелить серым веществом это будет математика. Считать вес линии, ее цвет и название слоя, нарисовать линию или еще что - это все ерунда. А вот царица наук...
veb86 вне форума  
 
Непрочитано 27.09.2021, 15:46
#120
Сергей812


 
Регистрация: 10.08.2013
Сообщений: 11,004


Цитата:
Сообщение от veb86 Посмотреть сообщение
Потом как румата решит nickname2019 перепишет на С++ или наоборот. Языки очень похожи.
только базовым синтаксисом похожи очень) Например, в .Net - массивы постоянные (можно только создать новый массив и туда скопировать из старого), строки постоянные (там вообще прикручен механизм хеширования) и т.д. Ну и отсутствие множественного наследования (хотя в последних версиях языка что-то начали делать в этом направлении, насколько видел)
Сергей812 вне форума  
Ответ
Вернуться   Форум DWG.RU > Программное обеспечение > Программирование > Как создать расчетное программное обеспечение с открытым исходным кодом (конструктивные решения)

Размещение рекламы
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
СП 335.1325800.2017 «Крупнопанельные конструктивные системы. Правила проектирования» (Обсуждение) Armin Прочее. Архитектура и строительство 37 07.11.2018 06:55
Фирменные решения по пропуску коммуникаций через стены подвала Regby Конструкции зданий и сооружений 2 07.04.2010 20:43
устройство и возможные конструктивные решения вентфасада из кирпича Ivansobaka Каменные и армокаменные конструкции 1 16.12.2009 06:38
Конструктивные решения по перемычкам в многослойных кирпичных стенах! Westroy Архитектура 16 30.11.2009 13:57
Конструктивные решения монтажных соединений многоэтажных зданий на высокопрочных болтах VoRoNoFF Конструкции зданий и сооружений 1 04.04.2009 00:41