Реклама 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
 
Непрочитано 25.09.2021, 22:40
#41
румата


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


Цитата:
Сообщение от nickname2019 Посмотреть сообщение
И Лирой и Скадом очень трудоемко выполнить корректный нелинейный расчет перекрытия, так как исходные данные неудобно задавать.
И у Лиры и у Скада есть текстовые файлы описания модели которые можно править извне и получать модифицированные схемы. Кроме того для скада существует механизм скриптования, который позволяет как задавать данные так и получать из него что нужно. Поэтому задача вычисления жесткостей перекрытия вполне может быть вынесена за рамки скада или лиры, а вычисленные жесткости могут быть "вернуты" в исходную схему. Конечно с наскока не получится это сделать, нужно будет повозиться, но эта задача вполне решаема "малой кровью". Было б у меня побольше времени - было б готовое решение для подобных задач.

----- добавлено через ~6 мин. -----
Цитата:
Сообщение от bigden Посмотреть сообщение
сплошной негатив.
ну куда ж без него. главное не переборщить. на самом деле готовых свободных и открытых библиотек предостаточно. бери и пользуй как тебе нужно.

----- добавлено через ~7 мин. -----
разговоры о верификациях здесь вообще не по теме
румата вне форума  
 
Автор темы   Непрочитано 26.09.2021, 08:13
#42
nickname2019


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


Заметил первую философскую проблему, связанную с хранением данных.
С одной стороны, геометрические объекты, которые описывают контуры конструкций (обычно это отрезки или полилинии) уже хранятся в графическом редакторе. Также после триангуляции образуется достаточно мелкая сетка конечных элементов.
Чтобы не дублировать данные, возникает идея описывать конечную модель непосредственно примитивами (AcDbPolyline, AcDbLine), а не вводить собственные объекты (в некоторой своей внешней БД) - чтобы не дублировать хранение информации.
Но, если КЭ описывать стандартными примитивами, возникает задача "приаттачить" к полилиниям дополнительные свойства, которые описывали бы характеристики КЭ (толщина, модуль упругости и т.д.). Будем использовать XDATA?

Последний раз редактировалось nickname2019, 26.09.2021 в 08:19.
nickname2019 вне форума  
 
Непрочитано 26.09.2021, 08:44
#43
zvezdochiot

маркшейдер
 
Регистрация: 25.09.2021
Москва
Сообщений: 146


Цитата:
Сообщение от nickname2019 Посмотреть сообщение
которые описывали бы характеристики КЭ (толщина, модуль упругости и т.д.).
Толщина и масштаб линии вроде как свободны. Почему бы не их? С толщиной даже "наглядно" получится.
zvezdochiot вне форума  
 
Автор темы   Непрочитано 26.09.2021, 09:19
#44
nickname2019


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


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

Толщина - не факт, что оптимальный вариант, так как при просмотре в аксонометрии Autocad "вытягивает" объекты в высоту. Это может мешать наглядности, если хотим видеть перекрытие "плоским".

Последний раз редактировалось nickname2019, 26.09.2021 в 09:40.
nickname2019 вне форума  
 
Непрочитано 26.09.2021, 09:37
#45
Сергей812


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


пробуйте варианты. С чего вы решили, что с первого раза сделаете все удобным и в работе, и визуально? Тем более пишете не отдельную САПР, а надстройку к "черному ящику" с API. Но, имхо, для служебных данных лучше использовать то - до чего у обычного пользователя не дотянуться руки встроенными средствами программы - XData, словари, внешние БД и т.д.

Цитата:
Сообщение от nickname2019 Посмотреть сообщение
в т.ч. проблемы переноса между nanocad/autocad
а почему тот же брискад игнорируете? Сделали бы тему-опрос - какие программы используют конструкторы-расчетчики помимо специализированных.
Сергей812 вне форума  
 
Автор темы   Непрочитано 26.09.2021, 09:42
#46
nickname2019


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


Цитата:
Сообщение от Сергей812 Посмотреть сообщение
а почему тот же брискад игнорируете? Сделали бы тему-опрос - какие программы используют конструкторы-расчетчики помимо специализированных.
Я никогда не писал под Брискад (т.е. это допзатраты времени). Скорее всего, нужно писать под Autocad, а кому надо - тот сам перекомпилирует.
nickname2019 вне форума  
 
Непрочитано 26.09.2021, 09:42
#47
zvezdochiot

маркшейдер
 
Регистрация: 25.09.2021
Москва
Сообщений: 146


Цитата:
Сообщение от Сергей812 Посмотреть сообщение
до чего у обычного пользователя не дотянуться руки
Может как раз наоборот? Использовать дополнительные возможности по ручной доводке моделей? Автоматика не всегда выдаёт требуемое.
zvezdochiot вне форума  
 
Автор темы   Непрочитано 26.09.2021, 09:48
#48
nickname2019


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


Цитата:
Сообщение от Сергей812 Посмотреть сообщение
Но, имхо, для служебных данных лучше использовать то - до чего у обычного пользователя не дотянуться руки встроенными средствами программы - XData, словари, внешние БД и т.д.
Пока воспользуемся советом Оккама: ""Сущности не следует умножать сверх необходимости".
nickname2019 вне форума  
 
Непрочитано 26.09.2021, 09:49
#49
Сергей812


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


Цитата:
Сообщение от zvezdochiot Посмотреть сообщение
Может как раз наоборот? Использовать дополнительные возможности по ручной доводке моделей? Автоматика не всегда выдаёт требуемое.
усложнять код дополнительными проверками валидности данных (а это ресурсы и быстродействие) ради нескольких человек, которые вместо программирования будут пытаться строить очередные велосипеды? А для остальных - это лишь человеческий фактор, в запарке такие вещи на чертежах вытворяют, что слой/толщину сменить - это вообще детские шалости.
Сергей812 вне форума  
 
Непрочитано 26.09.2021, 09:53
#50
zvezdochiot

маркшейдер
 
Регистрация: 25.09.2021
Москва
Сообщений: 146


Цитата:
Сообщение от Сергей812 Посмотреть сообщение
что слой/толщину сменить - это вообще детские шалости.
Но ты предлагаешь "вещь в себе"! Как ты подкорректируешь модель в случае необходимости? Геморрой на пустом месте. А ручные корректировки зачастую важнее самой модели.

PS: Простая ситуация: тебе надо изучить поведение одного конкретного элемента без изменения всей остальной модели.
zvezdochiot вне форума  
 
Непрочитано 26.09.2021, 10:06
#51
Сергей812


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


Цитата:
Сообщение от zvezdochiot Посмотреть сообщение
Простая ситуация: тебе надо изучить поведение одного конкретного элемента без изменения всей остальной модели.
так надо предусмотреть в надстройке возможность корректного изменения этого одного элемента. Не надо полагаться, что пользователь будет действовать именно в нужной последовательности, контролируя свои действия - он (пользователь) непредсказуем даже во вменяемом достаточно состоянии)
Сергей812 вне форума  
 
Непрочитано 26.09.2021, 10:08
#52
zvezdochiot

маркшейдер
 
Регистрация: 25.09.2021
Москва
Сообщений: 146


Цитата:
Сообщение от Сергей812 Посмотреть сообщение
так надо предусмотреть в надстройке возможность
Я так и сказал - геморрой!

PS: На каждый "чих" предусмотреть "возможность"?
zvezdochiot вне форума  
 
Непрочитано 26.09.2021, 10:23
#53
Сергей812


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


Цитата:
Сообщение от zvezdochiot Посмотреть сообщение
Я так и сказал - геморрой!

PS: На каждый "чих" предусмотреть "возможность"?
Просто когда только появились компьютеры, люди были с ними на Вы, и психологически были внимательны к своим действиям на компьютере. Сейчас страх перед ПК пропал + стресс регулярный + измотанность - среднестатистический пользователь будет периодически "жать" мимо не из-за желания испортить жизнь разработчику суперпрограммы, а просто потому что в голове параллельно еще куча других мыслей. Люди не роботы - пришли на работу, щелк - все остальное осталось за порогом: это лишь в фантазиях руководства.

Поэтому да, в процессе эксплуатации придется дополнять функционал
Цитата:
Сообщение от Сергей812 Посмотреть сообщение
С чего вы решили, что с первого раза сделаете все удобным и в работе, и визуально?
Сергей812 вне форума  
 
Непрочитано 26.09.2021, 10:49
#54
zvezdochiot

маркшейдер
 
Регистрация: 25.09.2021
Москва
Сообщений: 146


Цитата:
Сообщение от Сергей812 Посмотреть сообщение
люди были
"Давно это было. Так давно, что и как бы не было вовсе. Но коли не было, не стал бы об этом вспоминать".

Люди те же самые. "Защита от дурака" говоришь? Рассмотрим крайние случаи:

1. Опытный пользователь может допустить ляп. Но по результатам расчёта он его заметит и исправит. Поэтому предобработчик отсекает только заведомо некорректные параметры.

2. Все пользователи - дураки. Опытные пользователи - миф. Единственное, что предоставляется "дураку" - это большая красная кнопка "Сделать красиво".
zvezdochiot вне форума  
 
Автор темы   Непрочитано 26.09.2021, 10:50
#55
nickname2019


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


Цитата:
Сообщение от Сергей812 Посмотреть сообщение
пробуйте варианты. С чего вы решили, что с первого раза сделаете все удобным и в работе, и визуально?
Не с первого. Я раньше уже писал КЭ- расчетчик. Но это было давно и на Делфи.
Потом было потрачено много времени, чтобы результаты из Лиры и Скада можно было выводить в каком-то более удобоваримом виде (чтобы неделю отчеты в pdf вручную не выводить).
Сейчас я начинаю подозревать, что трудозатраты на организацию нормального вывода/ввода становятся сравнимы с тем, чтобы написать сам расчетный модуль (в необходимом объеме).
nickname2019 вне форума  
 
Непрочитано 26.09.2021, 10:56
#56
zvezdochiot

маркшейдер
 
Регистрация: 25.09.2021
Москва
Сообщений: 146


Цитата:
Сообщение от nickname2019 Посмотреть сообщение
в каком-то более удобоваримом виде (чтобы неделю отчеты в pdf вручную не выводить).
Это потому, что не пользовал SVG для графического представления. Он же текстовой и простой.
zvezdochiot вне форума  
 
Непрочитано 26.09.2021, 12:14
#57
румата


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


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

----- добавлено через ~8 мин. -----
Цитата:
Сообщение от nickname2019 Посмотреть сообщение
Я раньше уже писал КЭ- расчетчик. Но это было давно и на Делфи.
Ну так давайте его перепишем под .Net в виде подключаемых к автокаду плагинов. Если, конечно, исходники на паскале еще сохранились.

----- добавлено через ~2 мин. -----
Цитата:
Сообщение от nickname2019 Посмотреть сообщение
Потом было потрачено много времени, чтобы результаты из Лиры и Скада можно было выводить в каком-то более удобоваримом виде (чтобы неделю отчеты в pdf вручную не выводить).
Сейчас результаты из ЛирыСАПР можно выводить даже в демоверсии легко и непринужденно

Последний раз редактировалось румата, 26.09.2021 в 12:24.
румата вне форума  
 
Автор темы   Непрочитано 26.09.2021, 12:37
#58
nickname2019


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


Цитата:
Сообщение от румата Посмотреть сообщение
Ну так давайте его перепишем под .Net в виде подключаемых к автокаду плагинов. Если, конечно, исходники на паскале еще сохранились.
Там были прямоугольные пространственные КЭ (паралелепипеды). Программа не была универсальной и не была оптимальной по производительности. Что-то можно взять, но мало.
Оптимизацию нумерации узлов,в частности, я не делал. Матрицы получались с широкой лентой иногда.

Можно взять процедуру обращения матрицы. Там была более-менее эффективная с хранением половины матрицы жесткости (с учетом симметрии). Сейчас, говорят, итерационные алгоритмы более эффективны, но если делать нелинейное решение или с большим количеством вариантов нагрузок - думаю, лучше иметь обращенную матрицу жесткости.
nickname2019 вне форума  
 
Непрочитано 26.09.2021, 12:55
#59
румата


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


Цитата:
Сообщение от nickname2019 Посмотреть сообщение
Там были прямоугольные пространственные КЭ (паралелепипеды). Программа не была универсальной...
Значит нужно взять книжку Клованича и пр. и переписать матрицы жесткости разных типов КЭ с фортрана. Дело, в общем-то не сложное, но довольно затратное по времени.
Цитата:
Сообщение от nickname2019 Посмотреть сообщение
Можно взять процедуру обращения матрицы.
Для этого есть готовые математические библиотеки, располагающие инструментарием разреженных матриц и многопоточного вычисления.
Цитата:
Сообщение от nickname2019 Посмотреть сообщение
...если делать нелинейное решение
если делать нелинейный решатель то все равно прийдется решать СЛАУ(обращать глобальную матрицу) на каждом шаге
румата вне форума  
 
Автор темы   Непрочитано 26.09.2021, 13:17
#60
nickname2019


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


Цитата:
Сообщение от румата Посмотреть сообщение
Значит нужно взять книжку Клованича и пр. и переписать матрицы жесткости разных типов КЭ с фортрана. Дело, в общем-то не сложное, но довольно затратное по времени.
Имхо, для практики нужны:
-стержнень;
-прямоугольная пластина;
-треугольная пластина.

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

Цитата:
Сообщение от румата Посмотреть сообщение
если делать нелинейный решатель то все равно прийдется решать СЛАУ(обращать глобальную матрицу) на каждом шаге
Нет. Самое эффективное - обратить начальную матрицу жесткости один раз, потом ее многократно использовать в итерациях. Это самый быстрый способ. Я лично проверял. Касательную матрицу не нужно строить и обращать. Это долго.
nickname2019 вне форума  
Ответ
Вернуться   Форум 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