[nickname2019]

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

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

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

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

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

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

[fktstv]

Сообщение от nickname2019 Как технологически наиболее правильно можно организовать разработку расчетного программного обеспечения с открытым исходным кодом?

Offtop: Ничего себе, вы вопрос подняли. Кажется вы замахнулись на непосильную сообществу задачу.
1. Поиск финансирования
2. Поиск исполнителей
3. Разработка интерфейса ввода-вывода
4. Разработка МКЭ-решателя
5. Разработка конструирующих систем
6. ????
7. PROFIT!!!

[veb86]

https://github.com/zamtmn/zcad - отечественный CAD, с открытым исходным кодом. В нем Вы можете реализовать самые смелые свои идеи.
Плюсы:
- абсолютно бесплатный;
- проект медленно, но развивается (возможно Вы сможете изменить темпы развития);
- кроссплатформенность (автор ее даже на милинке запускал);
- быстро и стабильно работает.
Минусы:
- Ни кто не захочет слезть с (autocad, nanocad и т.д.);
- Ни кто не захочет что то считать и разрабатывать за бесплатно;
- Те кто попробуют упрутся в порог вхождения и сразу осознают, что не такой он уж и "корявый" редактор расчетной программы.

Сообщение от nickname2019 Как технологически наиболее правильно можно организовать разработку расчетного программного обеспечения с открытым исходным кодом?

Все есть, берите и начинайте программировать...

[trir]

сделай MVP, выложи на GitHub - а мы посмотрим...

[VitaKo]

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

я так понимаю, не дают написать программу с ОДНОЙ БОЛЬШОЙ КРАСНОЙ КНОПКОЙ???

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

Offtop: Хотел бы взглянуть одним глазком на проект, где так много простых балок, что их количество серьезно тормозит работу. Маниловщина какая-то, ей богу.

[maratovich]

Сообщение от nickname2019 правильно можно организовать разработку

Найти спонсора.

Сообщение от nickname2019 с открытым исходным кодом?

Никак.
Никогда этого не будет !

[Сергей812]

Решили продолжить тему ?)

[румата]

Сообщение от nickname2019 Как технологически наиболее правильно можно организовать разработку расчетного программного обеспечения с открытым исходным кодом?

Вопрос на миллион
А если серьезно, то кадры решают все. Разработка расчетной программы довольно наукоемкая задача. Кто будет писать мат. МКЭ ядро? Нужны люди со знанием МКЭ. Этим людям нужно за что-то жить.
Даже если взять за основу какой-нибудь opensource МКЭ решатель (коих, к слову сказать не так уж и мало), разобраться с его кодом для написания к нему нормального интерфейса - тоже задача на полмиллиона.
Времени на решение этих задач уйдет очень не мало, что приведет к одному из двух исходов:
1) проект будет развиваться крайне медленно из-за того, что исполнители(в случае их наличия) заняты основной работой
2) возникнет необходимость в финансировании исполнителей(в случае их наличия) для того, что б, закончить проект в каком-то обозримом будущем

А вообще я бы поучаствовал в такой разработке. Некоторые личные наработки по МКЭ и конструтивным расчетам по нормам РФ имеются.

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

Сообщение от Сергей812 Решили продолжить тему ?)

Это не совсем та тема

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

Сообщение от maratovich Никогда этого не будет !

Никогда не говори "никогда". Все возможно.

[nickname2019]

Сообщение от fktstv Offtop: Ничего себе, вы вопрос подняли. Кажется вы замахнулись на непосильную сообществу задачу. 1. Поиск финансирования 2. Поиск исполнителей 3. Разработка интерфейса ввода-вывода 4. Разработка МКЭ-решателя 5. Разработка конструирующих систем 6. ???? 7. PROFIT!!!

Идея нормальная, но никто не даст денег для разработки ПО с открытым исходным кодом.

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

Сообщение от veb86 https://github.com/zamtmn/zcad - отечественный CAD, с открытым исходным кодом. В нем Вы можете реализовать самые смелые свои идеи. Плюсы: - абсолютно бесплатный; - проект медленно, но развивается (возможно Вы сможете изменить темпы развития); - кроссплатформенность (автор ее даже на милинке запускал); - быстро и стабильно работает. Минусы: - Ни кто не захочет слезть с (autocad, nanocad и т.д.); - Ни кто не захочет что то считать и разрабатывать за бесплатно; - Те кто попробуют упрутся в порог вхождения и сразу осознают, что не такой он уж и "корявый" редактор расчетной программы. Все есть, берите и начинайте программировать...

Я бы рад, но, скорее всего, что работать и программировать под zcad в мире могут только несколько человек.

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

Сообщение от Сергей812 Решили продолжить тему ?)

Там речь шла о бесплатном ПО. Бесплатное ПО и ПО с открытым кодом - не совсем одно и тоже.

[Сергей812]

Сообщение от румата Это не совсем та тема

но если в относительно благополучном 2012 не смогли собрать рабочую команду исполнителей - здесь будет тот же результат, имхо) Единственные бесплатные работающие программы тут - от людей, кто не фантазирует о возглавлении команды "единомышленников/спонсоров", а сам потихоньку делает и поддерживает (p.s. спонсоры - не обязательно материально, что свое личное время потратил - это тоже спонсорство).

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

Сообщение от nickname2019 Бесплатное ПО и ПО с открытым кодом - не совсем одно и тоже.

за разработку любого ПО, вне зависимости от типа лицензирования, все равно кто-то платит...

[nickname2019]

Сообщение от румата Вопрос на миллион А если серьезно, то кадры решают все. Разработка расчетной программы довольно наукоемкая задача. Кто будет писать мат. МКЭ ядро? Нужны люди со знанием МКЭ. Этим людям нужно за что-то жить.

Я знаю как. Даже примерно представляю как сделать, чтобы решалось быстро. Но при оптимизации можно кучу времени убить на интересные исследования и ничего не закончить.

Даже если взять за основу какой-нибудь opensource МКЭ решатель

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

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

Интерфейс - это не та задача, которую я имел ввиду. Я имел ввиду написание "решательных" библиотек без привязки к конкретному редактору. Кому нужно - их можно привязать к той программе, с которой работает (или к своему интерфейсу).

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

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

А вообще я бы поучаствовал в такой разработке. Некоторые личные наработки по МКЭ и конструктивным расчетам по нормам РФ имеются.

Я бы сам поучавствовал . Тут важно подумать и автоматизировать так, чтобы была какая-то быстрая оптимизационная выгода за счет сокращения времени, потраченного на расчет (или проект в целом).
Повторять философию и концепцию Лиры и Скада было бы, наверно, неразумно.

[Сергей812]

Сообщение от nickname2019 Даже примерно представляю как сделать, чтобы решалось быстро.

ну так с этого и надо начинать) Создать тему, выложить свои более менее сформулированные соображения по убыстрению расчетов, а там и специалисты-расчетчики с форума подтянуться с критикой и предложениями. Потом если процесс не умрет/не зафлудится - можно уже и ТЗ на программу оформлять и искать финансирование. А то пока это все напоминает один старый анекдот

Чапаев поступает в институт и проваливает экзамен. - На чем срезался-то, Василий Иванович? - На математике. - А что так? - Да понимаешь, Петька, спрашивают меня: сколько будет 0.5 плюс 0.5, а я нутром чую, что литр, а математически выразить не могу!

[nickname2019]

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

Да. Нужно делать MVP (как предлагал trir), а потом будет видно.

[maratovich]

Сообщение от nickname2019 Да. Нужно делать MVP

Может быть уже пора что то сделать, а не демагогию разводить... Глядишь лет через десять уже рабочая версия и будет.

[румата]

Сообщение от nickname2019 Повторять философию и концепцию Лиры и Скада...

Ну ладно Лира... Но СКАД чем не угодил в плане решателя? У него один из самых быстрых решателей на рынке.

----- добавлено через 56 сек. -----

Сообщение от nickname2019 Нужно делать MVP

А что такое MVP? Паттерн Model-View-Presenter?

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

Сообщение от nickname2019 Надо поискать решатель

https://www.dealii.org/
http://sfepy.org/doc-devel/index.html

----- добавлено через ~36 мин. -----
https://getfem.org/

----- добавлено через ~36 мин. -----
https://freefem.org/

----- добавлено через ~37 мин. -----
https://code-aster.org/spip.php?rubrique2

----- добавлено через ~37 мин. -----
http://www.calculix.de/

----- добавлено через ~38 мин. -----
https://ngsolve.org/

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

Сообщение от nickname2019 Кстати, я давно видел опен-сурсный проект по генерации плоской сетки, надо будет заново поискать.

https://gmsh.info/

----- добавлено через ~41 мин. -----
https://habr.com/ru/post/181616/

[fktstv]

Сообщение от румата MVP

Минимально жизнеспособный продукт, as far as i understand.

[utrfm]

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

[veb86]

Как я понял, Вы опять хотите в одной программе чертить объект полностью (автокад, нанокад), а в другой программе чертить, что бы затем рассчитать (аналог scad).
Мое мнение, на реализации графического ядра программы, все полягут. Если хотите хоть что то сделать кроме ля-ля тополя, то вклинивайтесь в уже существующий и хоть как то рабочий CAD.
Например возьмите freecad, он позволяет построить модель здания(визуально, конечно по-любому надо будет что то доделывать, и ваши любимы сетки напряжения там есть уже готовые), а расчеты вы уж сами на питоне оформите или опять скажите что писать под это могут только пару человек?
Вы из тех кто, я же все сам с нуля?

[nickname2019]

Сообщение от veb86 Как я понял, Вы опять хотите в одной программе чертить объект полностью (автокад, нанокад), а в другой программе чертить, что бы затем рассчитать (аналог scad). Мое мнение, на реализации графического ядра программы, все полягут.

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

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

Сообщение от veb86 Если хотите хоть что то сделать кроме ля-ля тополя, то вклинивайтесь в уже существующий и хоть как то рабочий CAD. Например возьмите freecad, он позволяет построить модель здания(визуально, конечно по-любому надо будет что то доделывать, и ваши любимы сетки напряжения там есть уже готовые), а расчеты вы уж сами на питоне оформите или опять скажите что писать под это могут только пару человек?

Вангую, что при попытке открыть dwg чертеж с 300...500 тыс. объектов freecad ляжет.

Сообщение от veb86 Вы из тех кто, я же все сам с нуля?

Перечисленные румата в посте #15 ссылки, вероятнее всего, позволят скомпилировать что-то рабочее в течении недели.

[veb86]

Сообщение от nickname2019 Идея - разработать расчетные библиотеки с открытым исходным кодом, которые любой, обладающий соответствующими навыками программирования, может подцепить к своей программе и выполнить свой расчет. Так как для иллюстрации и отлаживания библиотек так или иначе нужен графический редактор, практическое приложение (исполняемый файл) проще всего оформить как приложение под Autocad/Nanocad (наиболее распространены, исходный код на c++ идентичен).

Я инженер-электрик, с моей колокольни все выглядит пока странно. Я бы наверное хотел бы видеть готовое рабочее решение, а не танцевать потом с бубном вокруг вашей библиотеки.

[nickname2019]

Сообщение от румата Ну ладно Лира... Но СКАД чем не угодил в плане решателя? У него один из самых быстрых решателей на рынке.

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

[Сергей812]

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

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

Тут недавно чудики всплывали - типа давайте вы нас проспонсируете по 200т в течении, минимум, 18 месяцев - а мы будем не спеша писать программу)

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

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

у них нет API, чтобы сделать надстройку с более удобным интерфейсом? Ради неудобного интерфейса переписывать основное рабочее расчетное ядро - это сильно, конечно..

[nickname2019]

Сообщение от Сергей812 у них нет API, чтобы сделать надстройку с более удобным интерфейсом?

Нормального API как для Autocad - нет.

Сообщение от Сергей812 Ради неудобного интерфейса переписывать основное рабочее расчетное ядро - это сильно, конечно..

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

[Сергей812]

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

ну так под этим лозунгом сейчас БИМ пропихивают который год: в программе что-то где то подвигали - и все само зашевелилось дальше по цепочке, только сидишь и наблюдаешь - как все сами и само..)

Только сколько будет затрачено человеко-часов на отлаживание этой расчетной библиотеки, включая контрольную верификацию по результатам расчетов с существующими сертифицированными программами?

[nickname2019]

Сообщение от utrfm архитектурно это должно быть максимально модульное по как пример - софистик или опенсис. отдельно препроцессор и мешер, которые готовят схему в текстовом виде отдельно решатель, отдельно постпроцессор, отдельно конструктивные модули.

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

[ГОСТ&ОПОКА]

Что вам не нравится в текущей ситуации вроде бы понятно. Но каким вы видите ее исправление - из ваших слов - не ясно. Вот например (выделение жирным мое):

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

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

Далее:

Сообщение от nickname2019 Прыгать в интерфейсе между "Заданием исходных данных" и "Результатами расчетов" - тоже еще то удовольствие. Какой гений до этого вообще додумался, интересно.

Опять же выходит, что проблему вы видите в интерфейсе пользователя. С этим нельзя не согласиться.

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

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

[nickname2019]

Сообщение от Сергей812 ну так под этим лозунгом сейчас БИМ пропихивают который год: в программе что-то где то подвигали - и все само зашевелилось дальше по цепочке, только сидишь и наблюдаешь - как все сами и само..)

Имхо, БИМ не обладает открытой, доступной и легкомодифицируемой архитектурой. Там как раз все закрыто и проприетарно.

Только сколько будет затрачено человеко-часов на отлаживание этой расчетной библиотеки, включая контрольную верификацию по результатам расчетов с существующими сертифицированными программами?

Трудно сказать.

[dambra]

Создать то Вы создадите, кто проверять/нести ответственность будет за Ваши наработки? Кто-то допилит "открытый код" или нарошно ошибки допустит чтобы комерческий софт конкурента покупали. А обновления интерфейса и т.д. Вы сравните программы 7-8 летней давности.
Нужен исходный открытый код - Libre Office как альтернатива Excel и простой калькулятор - наше все .

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

Я бы лично хотел видеть софт на платформе Unix, а конкретно на примере Linux Debian как образец стабильности. Далее код чтобы был не на C#, Visual Basic и прочей глючной темы винды, а C++ (на библиотеках Qt) или подобном с обеспечением кросс-платформенности. Чтобы код работал как на Unix так и на Windows. Это принципиальное решение, которое бы позволило пересадить инженеров с Виндовс на отечественную ОП, насколько мне известно базирующуюся на том же Debian.
За основу лучше всего бы было взять уже имеющуюся наработку. Как пример - отличный, функциональный но умирающий проект СКАД (по моему личному мнению), переработать интерфейс, визуальное отображение объектов, добавить удобство работать интуитивно в 1 окне т.е. переписать полностью код визуальной части, добавить возможности экспорта в 3Д чертилку. О самой 3Д чертилке, сейчас создают клоны Ревит - тот же Нанокад, Регна и т.д. По моему мнению выглядит это - убого и неэффективно. Сам Ревит довольно требователен к железу, а эффективность вызывает сомнения и споры. Почему не создать клонн хотябы той же Теклы? Написать его под ту же ОП отечественную + адаптировать к выпуску фалов .nc и .dstv ? Таким образом крупнейшие заводы, где как раз и есть деньги подвязать к отечественным решениям? Лет через 10 и деньги пойдут, т.е. окупаемость этого проекта - лет 10-15, не менее.

Как Вы видите - это комплексное решение и без участия Гос-ва тут никак. Бизнесс что - заинтересованн в мин. вложениях и получении выгоде здесь и сейчас, создадут сырой продукт по подписке, а года через 1-2 - пофиксят баги предыдущей версии, выпустят "обновления". Клонн американского системы ведения бизнесса. И зачем им создавать софт под новую безопасную ОП, им же за это не заплатят да и стоить это дороже будет в разы?
Одна надежда, что рано или поздно там наверху люди примут соответствующие решение, привлекут ведущие НИИ и создадут решение для отрасли как таковой.

[nickname2019]

Сообщение от ГОСТ&ОПОКА Получается, что здесь этот любой - это любой из тех, кто имеет 100 тыс. долларов на покупку графического ядра или разработку (если навыки есть) своей программы...

100 тыс. $ - это цена лицензирования графического ядра в случае, если Вы собираетесь написать свой Autocad/Nanocad и порвать Autodesk.
А если Вы юзер - Nanocad сейчас стоит 14 500руб. И к этому Nanocadу Вы можете прикрутить расчетную библиотеку со своими кнопками (панель команд будет дополнительная).

Сообщение от ГОСТ&ОПОКА Опять же выходит, что проблему вы видите в интерфейсе пользователя. С этим нельзя не согласиться.

Проблема в отсутствии нормального API для существующих программ. Т.е. это проект для программистов и для тех, кто хотел бы разобраться как это работает.

Сообщение от ГОСТ&ОПОКА Если идеализировать ситуацию, то есть единственный верный способ создать расчетное ядро (библиотеку), так все расчетные ядра должны пройти верификационные тесты одинаково.

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

Сообщение от ГОСТ&ОПОКА Но нет единственно верного способа проектирования интерфейса пользователя. Взаимодействие человека и машины - самая сложная и важная часть программного обеспечения в силу того, что задача эта почти гуманитарная и не имеет точного решения. Ведь мы о программе для всех, для множества разных людей, а не для одного автора, который точно знает, как ему лучше, и который простит сам себе то, что сделать не удалось.

Эта задача создания открытого ПО подразумевает создание открытого кода расчетных библиотек. Создание функциональной программы "с интерфейсом" - задача вспомогательная, для отладки и верификации.

[veb86]

Сообщение от nickname2019 Имхо, БИМ не обладает открытой, доступной и легкомодифицируемой архитектурой. Там как раз все закрыто и проприетарно

Открой код ZCAD-а и посмотри, это написал один человек за десятки лет и это всего лишь двухмерная, с зачатками 3-х мерной CAD системы. BIM в разы сложнее и крупнее. О какой доступности идет речь. Вам правильно человек сказал, вы хотите написать библиотеку которую смогут подключить единицы к автокаду. А если на основе Вашей библиотеки что то сделать более крупное то это упрется в покупку за 100 тыс долларов лицензии. Если что то делать так делать на основе готовой программы и более менее рабочей программы. Под вашу задачу я бы выбрал FreeCAD, я понимаю что Вы хотите AutoCAD, но Вы же сами сказали что он не обладает открытой, доступной и легкомодифицируемой архитектурой.
FreeCAD падает от 44 тысяч отрезков. Но так ВЫ же работаете с семействами, с плитами или колоннами. А для Freecad-а они как я понимаю будут одним элементом. Так хоть готовое решение будет открытое и свободное, которое продвинет человечество в сторону свободного ПО. А так вон зайдите на github и посмотрите на кучу непонятных библиотек, может там уже есть Ваша, готовая и рабочая, только Вы об этом не знаете.

[nickname2019]

Сообщение от veb86 Открой код ZCAD-а и посмотри, это написал один человек за десятки лет и это всего лишь двухмерная, с зачатками 3-х мерной CAD системы. BIM в разы сложнее и крупнее. О какой доступности идет речь. Вам правильно человек сказал, вы хотите написать библиотеку которую смогут подключить единицы к автокаду. А если на основе Вашей библиотеки что то сделать более крупное то это упрется в покупку за 100 тыс долларов лицензии.

Нет. Будет бесплатная objectarx библиотека, которую можно будет подключить к Автокаду.

Сообщение от veb86 Если что то делать так делать на основе готовой программы и более менее рабочей программы. Под вашу задачу я бы выбрал FreeCAD, я понимаю что Вы хотите AutoCAD, но Вы же сами сказали что он не обладает открытой, доступной и легкомодифицируемой архитектурой.

Он обладает достаточно развитым API. Кроме того, приложения под Autocad, написанные на c++, достаточно легко переносятся на Nanocad (обратную совместимость лично не проверял).

Сообщение от veb86 FreeCAD падает от 44 тысяч отрезков. Но так ВЫ же работаете с семействами, с плитами или колоннами. А для Freecad-а они как я понимаю будут одним элементом. Так хоть готовое решение будет открытое и свободное, которое продвинет человечество в сторону свободного ПО.

Имхо, Вы путаете свободное и бесплатное ПО. Свободное ПО не синоним бесплатного ПО. ПО с открытым исходным кодом может работать на нормальном платном ПО.

Сообщение от veb86 А так вон зайдите на github и посмотрите на кучу непонятных библиотек, может там уже есть Ваша, готовая и рабочая, только Вы об этом не знаете.

Собственно сейчас как раз этим и занимаемся (отдельное большое спасибо румата).

[Сергей812]

Свободное программное обеспечение (СПО) — программное обеспечение, распространяемое на условиях свободного лицензионного договора, на основании которого пользователь получает право использовать программу в любых, не запрещенных законом целях; получать доступ к исходным текстам (кодам) программы как в целях её изучения и адаптации, так и в целях переработки, распространять программу (бесплатно или за плату, по своему усмотрению), вносить изменения в программу (перерабатывать) и распространять.

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

Та же ЛИРА имеет 50+ лет истории развития - а тут резко придут и напишут бесплатную библиотеку, которая окажется быстрее и удобнее многолетнего опыта набивания шишек.

[nickname2019]

Сообщение от dambra Создать то Вы создадите, кто проверять/нести ответственность будет за Ваши наработки? Кто-то допилит "открытый код" или нарошно ошибки допустит чтобы комерческий софт конкурента покупали.

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

Сообщение от dambra Без соответствующей конкретно поставленной задачи и финансирования не получится. Сегодня у Вас есть энтузиазм, а через неделю - нет. Следовательно данное решение имеет смысл как ограниченная в возможностях маленькая программа или набор программ-утилит. Может Вам самим создать программу-утилиту в сотрудничестве с Лирой или Скад? Для начала создать что-то наподобии бесплатного NormCad с открытым кодом? Или после создания захотите продать тк Ваше время потраченно?

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

Сообщение от dambra Я бы лично хотел видеть софт на платформе Unix, а конкретно на примере Linux Debian как образец стабильности. Далее код чтобы был не на C#, Visual Basic и прочей глючной темы винды, а C++ (на библиотеках Qt) или подобном с обеспечением кросс-платформенности. Чтобы код работал как на Unix так и на Windows. Это принципиальное решение, которое бы позволило пересадить инженеров с Виндовс на отечественную ОП, насколько мне известно базирующуюся на том же Debian.

Библиотека будет на c++. Насколько я понимаю, это означает, что ее можно перекомпилировать куда угодно. Т.е. интерфейс идет отдельно.

Сообщение от dambra За основу лучше всего бы было взять уже имеющуюся наработку. Как пример - отличный, функциональный но умирающий проект СКАД (по моему личному мнению), переработать интерфейс, визуальное отображение объектов, добавить удобство работать интуитивно в 1 окне т.е. переписать полностью код визуальной части, добавить возможности экспорта в 3Д чертилку. О самой 3Д чертилке, сейчас создают клоны Ревит - тот же Нанокад, Регна и т.д. По моему мнению выглядит это - убого и неэффективно. Сам Ревит довольно требователен к железу, а эффективность вызывает сомнения и споры. Почему не создать клонн хотябы той же Теклы? Написать его под ту же ОП отечественную + адаптировать к выпуску фалов .nc и .dstv ? Таким образом крупнейшие заводы, где как раз и есть деньги подвязать к отечественным решениям? Лет через 10 и деньги пойдут, т.е. окупаемость этого проекта - лет 10-15, не менее.

Пока я планирую потратить недели две чистого времени в течении полугода на решение небольшой задачи по расчету плит перекрытий. Создание "клонов" коммерческих ПО в задачу не входит.

Сообщение от dambra Как Вы видите - это комплексное решение и без участия Гос-ва тут никак. Бизнесс что - заинтересованн в мин. вложениях и получении выгоде здесь и сейчас, создадут сырой продукт по подписке, а года через 1-2 - пофиксят баги предыдущей версии, выпустят "обновления". Клонн американского системы ведения бизнесса. И зачем им создавать софт под новую безопасную ОП, им же за это не заплатят да и стоить это дороже будет в разы? Одна надежда, что рано или поздно там наверху люди примут соответствующие решение, привлекут ведущие НИИ и создадут решение для отрасли как таковой.

Нет. Решение может быть принято только в виде "обязаловки" по приобретению кривого отечественного ПО с целью в очередной раз ограбить бизнес. Все помним введение СРО, обучений, сертификаций. Теперь "обязаловка" по приобретению БИМ. Сверху разумные инициативы невозможны.

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

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

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

[dambra]

Сообщение от nickname2019 Можно подумать, что Скад или Лира берут на себя ответственность за результаты расчета. Крупными буквами в лицензии идет отказ от ответственности.

Ответственность в данном случае подразумневает то, что инженер принимает собственное решение на основании опыта и знаний а также полученной информации из конкретного ПО.
Ответственность же этих фирм - ЛИРА, СКАД подразумневает репутационные потери как компании так и конкретных лиц, несравнимые с вариантом ответсвенности описанным Вами, где лежит кусок кода и никто ни за что не отвечает. GitHab - это только файлопомойка в хор. понимании слова, позволяющая записывать версии кода.
Предположем что Вы написали и закончили кусок программы, дальше то что? Нужны соответствующие тесты, особенно когда дело касается железобетона. У НИИ есть возможность построить здание, пару перекрытий и разрушить их, замерив датчиками реальные прогибы, перемещения, усилия и т.д., подвести теорию т.е. нужен научно-иследовательский потенциал и ресурс. Это в 2 словах. А у Вас что? Т.е. максимум что возможно в Вашем варианте, написать утилиту и выслать в оффис той же Лиры/Скада/Старка с надеждой, что это кого-то заинтересует своей уникальностью и будут произведены испытания, на основании которых введут изменения в программу.
Желаю успехов в Вашем нелегком деле. С Уважением,

[zvezdochiot]

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

Странно, но всё говорит в обратную сторону. Те же самые AutoCad и NanoCad - это куча библиотек и интерфейс к ним.
Но может это так раньше делали? Может щаз по-другому?
Смотрим LiteCad и видим ту же самую картину.

[bigden]

nickname2019, не спрашивай ты тут ничего. сплошной негатив. слов поддержки и дельных советов ты не получишь. делай как сам видишь

[Сергей812]

Сообщение от zvezdochiot Те же самые AutoCad и NanoCad - это куча библиотек и интерфейс к ним.

это куча связанных библиотек, "подключенных" к исполняемому файлу..

Сообщение от bigden слов поддержки и дельных советов ты не получишь.

к чему слова поддержки то

Сообщение от nickname2019 Даже примерно представляю как сделать, чтобы решалось быстро.

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

Сообщение от nickname2019 Проблема в отсутствии нормального API для существующих программ. Т.е. это проект для программистов и для тех, кто хотел бы разобраться как это работает.

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

Сообщение от nickname2019 Библиотека будет на c++. Насколько я понимаю, это означает, что ее можно перекомпилировать куда угодно.

Ну хоть в этом плюс - нет десятков страниц выбора ЯП...

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

удачи. И пожелание, чтобы эти две недели не переросли в два+ месяца в процессе отладки и корректировки...

[zvezdochiot]

Сообщение от Сергей812 это куча связанных библиотек, "подключенных" к исполняемому файлу..

Со стороны может и выглядит всё подобным образом. Но на самом деле всё в точности до наоборот. Терпеть не могу "птичий" язык.

[Сергей812]

Сообщение от zvezdochiot Со стороны может и выглядит всё подобным образом. Но на самом деле всё в точности до наоборот. Терпеть не могу "птичий" язык.

библиотеку запустить нельзя. Ее можно статически подключить / динамически загрузить в пространство приложения (как, например *.arx / *.dll в пространство акада) и вызывать определенные в ней функции, ресурсы и т.д. Поэтому библиотеки все-таки вторичны, как и интерфейс - это все должно быть загружено и запущено в основном потоке приложения.

[zvezdochiot]

Сообщение от Сергей812 Ее можно статически подключить

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

Сообщение от Сергей812 загрузить в пространство приложения

Не в "пространство приложения", а в общее адресное пространство. Иначе работать не будет.

Сообщение от Сергей812 Поэтому библиотеки все-таки вторичны

Наоборот. Приложение не запустится, пока не загружены все библиотеки. Линковщик пошлёт лесом.

Сообщение от Сергей812 в основном потоке приложения.

Потоки то здесь вообще при чём?

[румата]

Сообщение от nickname2019 И Лирой и Скадом очень трудоемко выполнить корректный нелинейный расчет перекрытия, так как исходные данные неудобно задавать.

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

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

Сообщение от bigden сплошной негатив.

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

----- добавлено через ~7 мин. -----
разговоры о верификациях здесь вообще не по теме

[nickname2019]

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

[zvezdochiot]

Сообщение от nickname2019 которые описывали бы характеристики КЭ (толщина, модуль упругости и т.д.).

Толщина и масштаб линии вроде как свободны. Почему бы не их? С толщиной даже "наглядно" получится.

[nickname2019]

Сообщение от zvezdochiot Толщина и масштаб линии вроде как свободны. Почему бы не их? С толщиной даже "наглядно" получится.

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

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

[Сергей812]

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

Сообщение от nickname2019 в т.ч. проблемы переноса между nanocad/autocad

а почему тот же брискад игнорируете? Сделали бы тему-опрос - какие программы используют конструкторы-расчетчики помимо специализированных.

[nickname2019]

Сообщение от Сергей812 а почему тот же брискад игнорируете? Сделали бы тему-опрос - какие программы используют конструкторы-расчетчики помимо специализированных.

Я никогда не писал под Брискад (т.е. это допзатраты времени). Скорее всего, нужно писать под Autocad, а кому надо - тот сам перекомпилирует.

[zvezdochiot]

Сообщение от Сергей812 до чего у обычного пользователя не дотянуться руки

Может как раз наоборот? Использовать дополнительные возможности по ручной доводке моделей? Автоматика не всегда выдаёт требуемое.

[nickname2019]

Сообщение от Сергей812 Но, имхо, для служебных данных лучше использовать то - до чего у обычного пользователя не дотянуться руки встроенными средствами программы - XData, словари, внешние БД и т.д.

Пока воспользуемся советом Оккама: ""Сущности не следует умножать сверх необходимости".

[Сергей812]

Сообщение от zvezdochiot Может как раз наоборот? Использовать дополнительные возможности по ручной доводке моделей? Автоматика не всегда выдаёт требуемое.

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

[zvezdochiot]

Сообщение от Сергей812 что слой/толщину сменить - это вообще детские шалости.

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

PS: Простая ситуация: тебе надо изучить поведение одного конкретного элемента без изменения всей остальной модели.

[Сергей812]

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

так надо предусмотреть в надстройке возможность корректного изменения этого одного элемента. Не надо полагаться, что пользователь будет действовать именно в нужной последовательности, контролируя свои действия - он (пользователь) непредсказуем даже во вменяемом достаточно состоянии)

[zvezdochiot]

Сообщение от Сергей812 так надо предусмотреть в надстройке возможность

Я так и сказал - геморрой!

PS: На каждый "чих" предусмотреть "возможность"?

[Сергей812]

Сообщение от zvezdochiot Я так и сказал - геморрой! PS: На каждый "чих" предусмотреть "возможность"?

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

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

Сообщение от Сергей812 С чего вы решили, что с первого раза сделаете все удобным и в работе, и визуально?

[zvezdochiot]

Сообщение от Сергей812 люди были

"Давно это было. Так давно, что и как бы не было вовсе. Но коли не было, не стал бы об этом вспоминать".

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

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

2. Все пользователи - дураки. Опытные пользователи - миф. Единственное, что предоставляется "дураку" - это большая красная кнопка "Сделать красиво".

[nickname2019]

Сообщение от Сергей812 пробуйте варианты. С чего вы решили, что с первого раза сделаете все удобным и в работе, и визуально?

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

[zvezdochiot]

Сообщение от nickname2019 в каком-то более удобоваримом виде (чтобы неделю отчеты в pdf вручную не выводить).

Это потому, что не пользовал SVG для графического представления. Он же текстовой и простой.

[румата]

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

так я вам об этом еще в #8 пытался сказать

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

Сообщение от nickname2019 Я раньше уже писал КЭ- расчетчик. Но это было давно и на Делфи.

Ну так давайте его перепишем под .Net в виде подключаемых к автокаду плагинов. Если, конечно, исходники на паскале еще сохранились.

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

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

Сейчас результаты из ЛирыСАПР можно выводить даже в демоверсии легко и непринужденно

[nickname2019]

Сообщение от румата Ну так давайте его перепишем под .Net в виде подключаемых к автокаду плагинов. Если, конечно, исходники на паскале еще сохранились.

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

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

[румата]

Сообщение от nickname2019 Там были прямоугольные пространственные КЭ (паралелепипеды). Программа не была универсальной...

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

Сообщение от nickname2019 Можно взять процедуру обращения матрицы.

Для этого есть готовые математические библиотеки, располагающие инструментарием разреженных матриц и многопоточного вычисления.

Сообщение от nickname2019 ...если делать нелинейное решение

если делать нелинейный решатель то все равно прийдется решать СЛАУ(обращать глобальную матрицу) на каждом шаге

[nickname2019]

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

Имхо, для практики нужны:
-стержнень;
-прямоугольная пластина;
-треугольная пластина.

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

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

Сообщение от румата если делать нелинейный решатель то все равно прийдется решать СЛАУ(обращать глобальную матрицу) на каждом шаге

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

[румата]

Сообщение от nickname2019 -прямоугольная пластина;

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

----- добавлено через 51 сек. -----

Сообщение от nickname2019 Вряд ли использовать их "в лоб" хорошая идея.

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

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

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

Хорошо, пусть пока будет так

----- добавлено через ~3 мин. -----
Здесь в библиотеке была книжка Агапова от 2002-го года с готовыми выведенными МЖ для нелинейных стержневых и слоистых оболочечных КЭ

[veb86]

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

Звучит как в фильме ужасов. Я не знаю что такое XDATA(подозреваю что это атрибуты), я бы делал через них. Толщина линий, масштаб, слои, цвет, и прочее... Вы шутите, этой программой роботы что ли пользоваться будут. На то что бы провести тесты и полюбоваться своей работой этого хватит, но в реальной работе, это будет капец (чисто мое мнение). Хотя для начала лучше хоть как бы реализовать, а там уж до пилите.

[румата]

https://russiaos.ru/summit/

[lenivec]

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

А MathCAD приспособить никак? (я не вкурсе, только понаслышке)

[zvezdochiot]

Сообщение от lenivec А MathCAD приспособить никак?

Проще тогда NumPy и SciPy "приспособить" (Python).

[lenivec]

Сообщение от zvezdochiot Проще тогда NumPy и SciPy "приспособить" (Python).

На самом деле проще?
Я так думал, что MathCAD считывает сами формулы и знание языков программирования (вроде Python) не требуется. Написал формулу, любой может подправить, доработать, скопипастить, не выискивая цепочку алгоритма в коде.

Вместо чистого Python, я бы тогда предложил:
Dynamo (в связке с учебным Revit), либо Grasshopher. Есть еще open source Dynamo Sandbox (пока не знаю что он может). Вот еще нашел open source: GRevit

[nickname2019]

Предлагается следующий перечень задач (пока собираем литературу):
1. Процедура формирование локальных матриц жесткостей стержней и оболочек (на один КЭ)
1.1. В линейной постановке
1.2. В физически нелинейной постановке
(геометрически нелинейные пока рассматривать не будем, так как для массового проектирования это не так актуально, а прогибы ж.б. перекрытий определять нужно в физ. нелинейной постановке)
2. Написание процедуры по генерации плоских КЭ сеток (вероятнее всего, следует воспользоваться кодом от проекта GMSH)
3. Написание процедуры оптимизации нумерации узлов таким образом, чтобы ширина ленты матрицы была минимальной (для т.н. многофронтального метода)
4. Написание процедуры решения СЛАУ с обращением матрицы жесткости
5. Написание процедуры получения РСУ
6. Визуализация
7. Подбор расчетных параметров сечений по РСУ

[zamtmn]

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

[румата]

Сообщение от lenivec А MathCAD приспособить никак? (я не вкурсе, только понаслышке)

Никак. Загнется он на первой более-менее серьезной расчетной модельке.

----- добавлено через 48 сек. -----

Сообщение от zvezdochiot Проще тогда NumPy и SciPy "приспособить" (Python).

Как вариант. Но получится некоторое снижение производительности по сравнению с нативным си.

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

Сообщение от lenivec Вместо чистого Python, я бы тогда предложил: Dynamo (в связке с учебным Revit), либо Grasshopher. Есть еще open source Dynamo Sandbox (пока не знаю что он может). Вот еще нашел open source: GRevit

Нет, не то. Это все геометрическоие параметризаторы.

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

Сообщение от zamtmn начать его делать, а не говорить-обсуждать-выбирать

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

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

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

И в геометрической тоже нужно. Почему только ЖБ? Сталь уже не нужна?

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

Сообщение от nickname2019 6. Визуализация

Здесь все же лучше смотреть в сторону OpenGL, а не автокада

[nickname2019]

Сообщение от румата И в геометрической тоже нужно. Почему только ЖБ? Сталь уже не нужна?

Сталь обычно все считают в линейной постановке (кроме мачт), но мачты тоже линеаризуются нормально. Но очень мало людей правильно считают прогибы ж.б.к. Хотелось бы этот пробел устранить.

Сообщение от румата Здесь все же лучше смотреть в сторону OpenGL, а не автокада

Может быть. Но написание нормального графического движка - задача более сложная, чем расчетного комплекса. Здесь вопрос не в 3д визуализации а в задаче эффективного обсчета 2-д текста и графики в больших объемах.

[veb86]

Сообщение от румата Цитата: Сообщение от lenivec Посмотреть сообщение А MathCAD приспособить никак? (я не вкурсе, только понаслышке) Никак. Загнется он на первой более-менее серьезной расчетной модельке.

Я для подобных расчетов пользуюсь Smath (бесплатный потому что, и расчеты небольшие). Посчитать в Mathcad можно много чего, но считает он действительно долго. Но зато все наглядно, легко потом будет проводить проверки расчета созданного в программе. Или как Вы предлагаете проверять расчеты?
В идеале было бы здорово, если группа матерых специалистов, начали делать расчет в Маткаде(Питон, Javascript или просто на бумажке), а nickname2019 начнет готовить библиотеку для автокада. Специалисты по воюют за правильность расчета, а nickname2019 просто переписал формулы из программы в программу, а не изучал математику расчетов

[nickname2019]

Сообщение от veb86 Я для подобных расчетов пользуюсь Smath (бесплатный потому что, и расчеты небольшие). Посчитать в Mathcad можно много чего, но считает он действительно долго. Но зато все наглядно, легко потом будет проводить проверки расчета созданного в программе. Или как Вы предлагаете проверять расчеты? В идеале было бы здорово, если группа матерых специалистов, начали делать расчет в Маткаде(Питон, Javascript или просто на бумажке), а nickname2019 начнет готовить библиотеку для автокада. Специалисты по воюют за правильность расчета, а nickname2019 просто переписал формулы из программы в программу, а не изучал математику расчетов

Вероятнее всего, nickname2019 на этой неделе напишет скелет на objectarx и напишет как сделать так, чтобы его компилировать и запустить для всех желающих приобщиться.
Для написания расчетных модулей c++ кроме как оформление циклов и объявления переменных типа double и string знать ничего не надо.

Предлагается писать программу для visual studio 2012, это позволит запускать приложение на autocad 2015, 2016. Также эту версию желающие смогут перекомпилировать под nanocad.

Имхо, при желании портировать с visual studio 2012 на более новые версии провести проще, чем наоборот.

Есть возражения?

[румата]

Сообщение от nickname2019 Сталь обычно все считают в линейной постановке...

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

[Ziabz]

А что не то с Mathcad? Я никогда в жизни не изучал программирование, без проблем создаю алгоритм проверки по нормам ..

[румата]

Сообщение от nickname2019 Предлагается писать программу для visual studio 2012...

А почему в таком древнем VS?

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

Сообщение от Ziabz А что не то с Mathcad? Я никогда в жизни не изучал программирование, без проблем создаю алгоритм проверки по нормам .

С ним все нормально. Только:
1) он платный
2) он не будет работать с матрицами объемом в гигабайты

[nickname2019]

Сообщение от румата А почему в таком древнем VS?

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

[румата]

Сообщение от nickname2019 Есть возражения?

есть. я бы делал решатель на .net или python без завязки на .arx расширения автокада. dxf никто не отменял

[nickname2019]

Сообщение от румата есть. я бы делал на .net или python без завязки на .arx расширения автокада. dxf никто не отменял

Есть вероятность, что в процессе разработки придется прибегнуть к созданию своих объектов, на .net или python это сделать будет сложно. Плюс производительность здесь будет узким местом.

arx - это нужно для визуализации и отладки, чтобы не писать свой граф. редактор.

[румата]

Эти языки более распространены и предпочтительны для opensource

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

Сообщение от nickname2019 Есть вероятность, что в процессе разработки придется прибегнуть к созданию своих объектов...

только не proxy. это все погубит

[nickname2019]

Сообщение от румата Эти языки более распространены и предпочтительны для opensource

gmsh написан на c++. Скорее всего оттуда можно много чего взять вообще без переделок.

----- добавлено через 31 сек. -----

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

согласен. Это на крайний случай.

[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 - вот тогда и посмотрим. Визуальный язык - это пока не совсем то, что нужно.

[zamtmn]

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

тут нужен опыт, опыт можно получить только одним способом.

Вообще очень странно пытатся делать опенсорс обмазовшись со всех сторон проприетарным дорогущим софтом. не получится

[Нубий-IV]

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

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

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

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

[румата]

Сообщение от zamtmn тут нужен опыт, опыт можно получить только одним способом.

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

[nickname2019]

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

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

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

Сообщение от Нубий-IV Если залезть глубоко, возможно и в коде придется разные версии делать, но на уровне создания простых пользовательских команд я с этим не столкнулся.

Да. Блин, я вспомнил. Требования к строгости кода менялось в новых версиях студии. Кажется типы стали объявляться более строго.
Видимо, по ходу разработки код нужно периодически тестировать на соответствие новым версиям студии.

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

[румата]

Сообщение от nickname2019 Видимо, по ходу разработки код нужно периодически тестировать на соответствие новым версиям студии.

Вот дался вам это арх. Зачем такие сложности для ввода-вывода?

[nickname2019]

Сообщение от румата Вот дался вам это арх. Зачем такие сложности для ввода-вывода?

Расчетную библиотеку на c++ удобно отлаживать при подключении ее к оболочке на objectarx, так как objectarx тоже использует c++. Готовую библиотеку лучше "обернуть" через c#.

[румата]

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

тогда сразу нужно и ядро писать и обертки

----- добавлено через ~1 мин. -----
лично мне удобнее для тестирования будут .net dll расширения

[nickname2019]

Сообщение от румата тогда сразу нужно и ядро писать и обертки

Расчетный код на c++ будет намного быстрее + его можно скопипастить из gmsh. Математику нужно писать на c++, может быть с применением ассемблера на перспективу.

Сообщение от румата лично мне удобнее для тестирования будут .net dll расширения

надо подумать, как это сразу сделать.

[румата]

Сообщение от nickname2019 Расчетный код на c++ будет намного быстрее...

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

[nickname2019]

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

Мультифронтальный метод решения надо запускать в нескольких потоках (по количеству физических процессоров).

[румата]

Сообщение от nickname2019 Мультифронтальный метод решения надо запускать в нескольких потоках (по количеству физических процессоров).

Главное, что б для этого знаний хватило. У меня вот точно не хватит знаний для многопоточного программирования на С++

[nickname2019]

Сообщение от румата Главное, что б для этого знаний хватило. У меня вот точно не хватит знаний для многопоточного программирования на С++

Я думаю, что цели нужно сразу ставить серьезные, а там как пойдет.

[румата]

Сообщение от nickname2019 Я думаю, что цели нужно сразу ставить серьезные, а там как пойдет.

А я думаю нужно использовать готовые библиотеки для эффективного решения СЛАУ. SciPy, Math.Net и пр.

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

[nickname2019]

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

Надо будет протестировать. Разница во времени может быть огромна. c++ библиотек тоже много.

[румата]

Сообщение от nickname2019 Надо будет протестировать. Разница во времени может быть огромна.

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

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

[румата]

Вот графики сравнения

[nickname2019]

Сообщение от румата Вот графики сравнения

https://gitlab.com/libeigen/eigen
Вроде у них были решения для разреженных матриц (чтобы не оптимизировать нумерацию узлов и не уменьшать размер ленты).
Также подозреваю, что они матрицы раскладывают с использованием видеокарты.

[румата]

Сообщение от nickname2019 Вроде у них были решения для разреженных матриц (чтобы не оптимизировать нумерацию узлов и не уменьшать размер ленты).

решения для разреженных матриц есть везде. без этого сейчас никакая нормальная библиотека не обходится

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

Сообщение от nickname2019 Также подозреваю, что они матрицы раскладывают с использованием видеокарты.

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

[veb86]

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

nickname2019 - я думаю туда надо просто смерится и принять, что в итоге все равно тебе одному все пилить придется) ты кашу заварил, тебе и кушать. Никогда не работал с с++, но знаю точно, что возможностей во много больше.

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

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

Сообщение от румата Главное, что б для этого знаний хватило. У меня вот точно не хватит знаний для многопоточного программирования на С++

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

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

[Сергей812]

Сообщение от veb86 Потом как румата решит nickname2019 перепишет на С++ или наоборот. Языки очень похожи.

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

[zvezdochiot]

Сообщение от Сергей812 в .Net - массивы постоянные

Аллокатора совсем нету?

[румата]

Сообщение от zvezdochiot Аллокатора совсем нету?

в .net есть изменяемые массивы в виде списков, словарей, стеков, очередей и множеств.

[Сергей812]

Сообщение от zvezdochiot Аллокатора совсем нету?

очень даже есть, но .Net управляемый язык и управления ресурсами пытается брать полностью на себя. Т.е. есть, например, базовый класс работы с массивами Array и там есть метод изменения размерности массива Resize. Но на самом деле под "капотом"

Код:

[Выделить все]

 // Если текущая емкость массива не равна новому значению
if (larray.Length != newSize) 
{
    // Запрашиваем выделение массива новой размерности
    T[] newArray = new T[newSize];
    // Копируем содержимое старого массива в новый
    Array.Copy(larray, 0, newArray, 0,  larray.Length > newSize? newSize : larray.Length);
    // Подменяем ссылку исходного массива на новый 
    array = newArray;
}

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

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

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

угу, только если посмотреть их реализацию - например базовый типизированный список List<T> - метод установки значения Capacity

Код:

[Выделить все]

  
if (value != _items.Length) 
{
     if (value > 0) 
    {
         T[] newItems = new T[value];
         if (_size > 0) 
         {
              Array.Copy(_items, 0, newItems, 0, _size);
         }
         _items = newItems;
     }
     else 
    {
         _items = _emptyArray;
    }
}

абсолютно то же - массивы фиксированной размерности.

[zvezdochiot]

Сообщение от Сергей812 T[] newArray = new T[newSize];

От того, что аллокатор маскируется, и заворачивается в объект класса, он не перестаёт быть аллокатором. Только паразитные затраты увеличиваете.

[Сергей812]

Сообщение от zvezdochiot От того, что аллокатор маскируется, и заворачивается в объект класса, он не перестаёт быть аллокатором. Только паразитные затраты увеличиваете.

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

В любом случае, если нужна именно скорость вычислений - имхо, .Net съест часть ресурсов из-за идеологии управляемого кода.

[румата]

Сообщение от Сергей812 .Net съест часть ресурсов из-за идеологии управляемого кода.

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

[nickname2019]

Остается решить как вносить изменения в "проверенный" код на сайте.
Варианты:
1. Каждый вносит имзенения код на GitHub, потом изменения объединяются через функционал GitHub (это не сложно для обычного юзера, который нашел ошибку в расчетном и хочет немного поправить код?).
2. Каждый размечает специальными метками места, где он вносил изменения, специальной программой код будем периодически объединять в "главный" файл.

[румата]

Сообщение от nickname2019 Остается решить как вносить изменения в "проверенный" код на сайте.

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

[румата]

Вот что что пишет создатель AlgLib по поводу использования сторонней библиотеки для решения задач линейной алгебры https://www.alglib.net/articles/a001_alglibandmkl.php

[dambra]

Сообщение от nickname2019 Остается решить как вносить изменения в "проверенный" код на сайте. Варианты: 1. Каждый вносит имзенения код на GitHub, потом изменения объединяются через функционал GitHub (это не сложно для обычного юзера, который нашел ошибку в расчетном и хочет немного поправить код?). 2. Каждый размечает специальными метками места, где он вносил изменения, специальной программой код будем периодически объединять в "главный" файл.

Привет.
Предлагаю тебе как автору задачу разбить на подзадачи и изложить что ребуется, т.е. чтобы участнику оставалось реализовать код зная конкретную задачу.
2. Можно спросить о среде разработки - IDE? Я так понял что пишешь на чистом С++?
3. Хорошо бы было определится с библиотеками которые ещё ужны, как советовали другие и на основании их уже реализовывать задачи. Можешь проанализировать или кого-то подключить кто знает. Или все на cmath писать вручную? Может получиться зоопарк.
4. Я бы мог помочь написать часть кода зная задачу. Если есть возможность делегировать часть кода - пиши в личку. С уважением,

[nickname2019]

Сообщение от dambra Привет. Предлагаю тебе как автору задачу разбить на подзадачи и изложить что ребуется, т.е. чтобы участнику оставалось реализовать код зная конкретную задачу. 2. Можно спросить о среде разработки - IDE? Я так понял что пишешь на чистом С++? 3. Хорошо бы было определится с библиотеками которые ещё ужны, как советовали другие и на основании их уже реализовывать задачи. Можешь проанализировать или кого-то подключить кто знает. Или все на cmath писать вручную? Может получиться зоопарк. 4. Я бы мог помочь написать часть кода зная задачу. Если есть возможность делегировать часть кода - пиши в личку. С уважением,

Сейчас идет анализ материалов. Всем отписавшимся большое спасибо.

По результатам анализа ситуации напрашиваются следующие выводы (предварительно):
1. Вся математика написана до нас (кроме проверки конструкций по нашим СП). Есть несколько законченных проектов, которые имеют открытый исходный код. Улучшать можно, но это отнесем "на потом".
2. Работа сводится к выбору существующего проекта с открытым исходным кодом для его локализации.
3. Мне пока нравиться gmsh (импорт из gmsh поддерживает SCAD, вероятнее всего это оптимальный "донор" для кода).

Я пока пытаюсь разобраться как его скомпилировать и зпустить на исполнение в одной из версий Microsoft Visual Studio.

(прошу понять меня правильно, мое время ограниченно, и я не могу на 100 процентов себя посвятить этой задаче)

Если кто-то разберется как это сделать (какие настройки поставить и т.д.) и поделиться этим с сообществом, было бы прекрасно.

Сайт:
https://gmsh.info/

P.s. вообще, видимо, нужно с функционалом gmsh ознакомиться. Я раньше с ним не встречался.

[Нубий-IV]

Сообщение от nickname2019 Мне пока нравиться gmsh

Навскидку пара проблем с ним:

• Тормозит даже на не очень больших задачах. Хорошо, если это тормозит графика. А если сам движок - то у нас проблема. Это первое, что надо проверить.
• Для контуров, которые касаются друг друга сторонами, не создает совместную сетку. Там есть в разделе MESH режим Define/Embedded, но он работает только если точка или линия попадает на поверхность; для точки, попавшей на контур, генерится битая сетка, или сетка не создается вообще, или GMSH вылетает. Есть режим слияния геометрии, но он удаляет только совпавшие точки, или полностью совпавшие отрезки; порезать линию узлами то ли он не умеет, то ли я не умею.

Сообщение от nickname2019 импорт из gmsh поддерживает SCAD

Еще импорт вроде как есть у Лиры, но в версии 2016Free я не смог его заставить работать. Формат MSH несколько раз менялся, видимо, импорт был рабочим только в одной из старых версий. Для Лиры и Старка я себе сваял простые программки на C#, перегоняют *.MSH в *.SLI и в *.FEA. MSH сохранять командой "File/Export/Gmsh MSH" и выбирать формат "Version 1". Программки консольные. Кто работает в Total Commander / Double Commander - можно вытащить значок на панель, и перетаскивать файлы MSH на значок. Кто работает в проводнике - можно создать ярлык к программе, и перетаскивать файлы MSH на ярлык. Рядом с исходной сеткой запишется SLI или FEA с тем же именем.

Сообщение от nickname2019 Работа сводится к выбору существующего проекта

Еще из открытого знаю Elmer FEM - аналог Ансисов/Комсолов и т.п. - мультифизика. Есть механика, теплотехника, электростатика и т.п. Есть забавные фишки, типа адаптивных сеток, которые в процессе решения под градиенты уточняются. Есть и линейные решатели, и нелинейные, и API под пользовательские типы КЭ. Были и глюки - в многопоточной версии нарушалась синхронизация записи результатов, и получались битые файлы, с секциями, записанными не по порядку; при слишком большом числе шагов по времени переполнялся счетчик номеров файлов данных и расчет прерывался. Исходники не смотрел, там может оказаться фортран.

[румата]

Сообщение от nickname2019 3. Мне пока нравиться gmsh (импорт из gmsh поддерживает SCAD, вероятнее всего это оптимальный "донор" для кода).

GMSH это, в основном, мешер, т.е. генератор КЭ сеток. Да, у него есть свой решатель, но насколько мне известно это очень ускоспециализированный решатель на правленный на решение задач толи электромагнетизма, толи акустики.

Сообщение от nickname2019 Я пока пытаюсь разобраться как его скомпилировать и зпустить на исполнение в одной из версий Microsoft Visual Studio.

Зачем? Он уже есть скомпилированный в виде .exe и не требующий установки. Поддерживает работу из командной строки, т.е. его можно вызывать на исполнение практически из любого программого кода.

Сообщение от nickname2019 вообще, видимо, нужно с функционалом gmsh ознакомиться.

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

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

Сообщение от Нубий-IV Для контуров, которые касаются друг друга сторонами, не создает совместную сетку.

Да, это нужно научится обходить.

Сообщение от Нубий-IV Тормозит даже на не очень больших задачах.

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

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

Сообщение от nickname2019 2. Работа сводится к выбору существующего проекта с открытым исходным кодом для его локализации.

Написание своей библиотеки КЭ может оказаться более простым, чем адаптация чужого кода под свои нужды

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

Сообщение от nickname2019 (прошу понять меня правильно, мое время ограниченно, и я не могу на 100 процентов себя посвятить этой задаче

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

[Нубий-IV]

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

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

Сообщение от румата GMSH это, в основном, мешер, т.е. генератор КЭ сеток.

Формально у него есть родной решатель - GetDP, и возможность подключить свой. Плюс есть постобработка - просмотр результатов и какие-никакие фильтры для обработки результатов. Теоретически можно и его вместо автокада как редактор и визуализатор по первости использовать.

Сообщение от румата При правильно созданном скрипте очень быстро работает

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

[nickname2019]

Сообщение от румата Написание своей библиотеки КЭ может оказаться более простым, чем адаптация чужого кода под свои нужды

КЭ мешер, я думаю, мы уже нашли. Осталось найти в нем процедуру генерации сеток и скопипастить. У них SDK вроде есть, нужно только разобраться. С нуля писать плоский мешер - это может быть надолго (не менее мясяца-двух чистого времени). Необходимости создания 3д-мешера я пока вообще не вижу (для строительства это слишком узкая задача, кроме расчетов тел плотин мне в голову ничего не приходит).

Наверняка также есть уже написанные процедуры генерации локальных матриц жесткостей отдельных КЭ (открытый код).

[румата]

Сообщение от nickname2019 Осталось найти в нем процедуру генерации сеток и скопипастить.

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

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

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

Сообщение от nickname2019 Наверняка также есть уже написанные процедуры генерации локальных матриц жесткостей отдельных КЭ (открытый код).

Есть, но они все, преимущественно на фортране (как в книжках по МКЭ), реже на питоне.

[nickname2019]

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

Потом запускать gmsh через командную строку для расчета? А результаты обратно в граф. редактор импортировать?

----- добавлено через 41 сек. -----

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

Это круто. Но пока проанализируем все возможные варианты.

P.s.
Вот ссылка с примером работы с библиотекой Eigen

https://habr.com/ru/post/271723/

[румата]

Сообщение от nickname2019 Потом запускать gmsh через командную строку для расчета?

Да хоть как запускать. Можно открыть руками через графический интерфейс GMSH.

Сообщение от nickname2019 А результаты обратно в граф. редактор импортировать?

Да, ничего сложного в этом нет.

Сообщение от nickname2019 Это круто.

Крутого мало. Пока только один метод генерации сетки реализован.

Сообщение от nickname2019 Вот ссылка с примером работы с библиотекой Eigen

Да, спасибо, я это давно видел.

[nickname2019]

После некоторого размышления над комментариями, проект, видимо, будем делать на Visual Studio 2019.
Желающим присоединиться к проекту старые версии студий найти может быть трудно.
Т.е. результирующий проект будет совместим с Autocad 2021.
Результирующий вариант потом перекомпилируем под другие версии.

[Нубий-IV]

Сообщение от nickname2019 какие настройки поставить

Похоже, никакие вообще не надо. В свежескачаной VS2019Community (16.11.3):

• Если нужно просто собрать exe:
  - "Файл / Открыть / Папка", выбрать папку "gmsh-4.8.4-source".
  - После того, как VS подумает несколько минут с импортом, "Сборка / Собрать решение"
  - В папке "gmsh-4.8.4-source\out\build\x64-Debug" собрался gmsh.exe (консольная версия). Тестовая команда "gmsh.exe Test.geo -2 -o Test.msh" работает и сохраняет сгенерированную сетку.
• Если нужно настроенное решение:
  - Зайти в папку "gmsh-4.8.4-source" и запустить CMake (ставится с VS) с ключом -G для генерации проекта VS:
  
  Код:

  [Выделить все]

  "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -G "Visual Studio 16 2019" .

  - В VS открыть решение "gmsh-4.8.4-source\gmsh.sln" и собрать через "Сборка / Собрать решение"
  - В папке "gmsh-4.8.4-source\Debug\" - собранный gmsh.exe.

[nickname2019]

Создал тестовый проект:
https://github.com/chaosEagleOwl/source

Проект создан пока для тестирования возможности совместной разработки.
В проекте прописаны пути из учета, что Visual Studio 2019 установлена на диске C:

Чтобы не думать о том, как назвать проект, название принято по умолчанию- ArxProject1.

В проекте три каталога:
VS2019(c++)ac2021- проект для Visual Studio 2019 и Acad 2021
ArxLib - библиотеки arx.
common - это для общих модулей в случае, если будут компилироваться исполняемые arx для других версий графического редактора.

Чтобы не возникали проблемы с локальными путями
локальный репозиторий думаю лучше хранить как
C:\GitHub\

Таким образом, после синхронизации с GitHub, локальный путь к проекту должен быть
C:\GitHub\source\VS2019(c++)ac2021\ArxProject1\ArxProject1.sln

До начала работы, думаю, следует установит ObjectARXWizard

Путь для запуска установки (после синхронизации):
C:\GitHub\source\ArxLib\ObjectARX_for_AutoCAD_2021_Win_64bit_dlm\ObjectARXWizard2021.msi

После запуска установки в качестве пути для SDK следует указать:
C:\GitHub\source\ArxLib\ObjectARX_for_AutoCAD_2021_Win_64bit_dlm\
(если указать другой путь - наверняка не найдет библиотеки при компиляции)

Для возможности отладки командой _appload в список автозагрузки Autocad должен быть добавлен файл:
C:\GitHub\source\VS2019(c++)ac2021\ArxProject1\x64\Debug\ArxProject1.arx

Для тестирования реализована только команда (из командной строки) -
MYHELLO
которая приветствует мир.

Желающим присоединиться к проекту можно пробовать устанавливать GitHub и тестировать возможности запуска и компиляции.

Можно также посмотреть настройки проекта, покритиковать, может что-то поправить надо.

[trir]

почитай про gitignore - Debug'у в репозитории не место
для примера https://github.com/triroakenshield/R...ter/.gitignore

[nickname2019]

Сообщение от trir почитай про gitignore - Debug'у в репозитории не место для примера https://github.com/triroakenshield/R...ter/.gitignore

Спасибо. Я первый раз столкнулся с репозиторием. Самые большие файлы исключил, про debug "в целом" не догадался.
Поправлю.
Также добавил библиотеки objectarx в полном составе. Это, наверно, не самая удачная идея, но это должно обеспечить совместимость путей + простое обновление в случае, если библиотека поменяется.

[Кулик Алексей aka kpblc]

А в проекты на плюсах NuGet пакеты не подтягиваются, что ли?

[trir]

А в проекты на плюсах NuGet пакеты не подтягиваются, что ли?

ObjectArx можно скачать только с сайта доски

[nickname2019]

Если кто хочет участвовать - подключайтесь к редактированию (заодно можно с c++ разобраться, кто не знает).
Там как-то запрос на GitHube делать вроде надо.

[trir]

можно из VS изменения сразу на GitHub отправлять

[nickname2019]

Если возникают проблемы с компиляцией - прошу сообщать.

[румата]

Сообщение от Кулик Алексей aka kpblc А в проекты на плюсах NuGet пакеты не подтягиваются, что ли?

Крнечно нет. В том числе и поэтому я был против плюсов для автокада

[nickname2019]

Сообщение от румата Крнечно нет. В том числе и поэтому я был против плюсов для автокада

Я просто не работал с #Net.

Планируется:
на objectarx будет писаться только интерфейсная часть (взаимодействие с граф. редактором), а расчетные процедуры могут быть запакованы в *.dll и подключены к #Net. На c++ оказывается проще брать и модифицировать сторонний исходный код (в основном математика написана на c++).
Кроме того, отдельные модули можно писать на #Net, если кому-то так удобнее.

Если кто-то желает создать интерфейсную часть на #Net, я не против. Код можно писать параллельно.
Нужно создать второй каталог и в нем решение на #Net. Потом гитхабом синхронизируем с основным каталогом. На #Net я не смогу эффективно писать.

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

[trir]

под NET API можно и на плюсах писать

[nickname2019]

Сообщение от trir под NET API можно и на плюсах писать

При создании проекта я не включил поддержку #Net и не включил поддержку COM.

Думаете, нужно пересоздать решение и включить поддержку Net и COM?
(в настройках проекта наверно будет очень трудно это поменять).

Пока, наверное, оставлю как есть.

[trir]

можно сделать отдельные проекты

[Сергей812]

Техзадание опосля напишите?

[румата]

Сообщение от trir под NET API можно и на плюсах писать

Можно, но тем, кто привык к написанию в нативном си(пусть даже с плюсами) такое написание будет ударом "по дых"

[Нубий-IV]

Сообщение от nickname2019 Если возникают проблемы с компиляцией

Может, это просто кривые руки... Я сижу под бесплатным пятым нанокадом, и автокадовская версия мне не интересна. Я проверил возможность собрать это все под нанокад в двух версиях студии. В обоих случаях до моего кода дело не доходит - сотня ошибок набирается прямо в SDK, и компиляция останавливается.

VS 2019 Community не желает собирать даже пустой проект (в котором есть только точка входа в dll и ничего больше) - идет сплошная ругань на SDK-шные заголовки (они предназначены в оригинале для VS 2008). Например, "fabs не найдена в пространстве имен std". Если по советам из гугла сделать "std { #include <stdlib> }", то появляется противоположное требование - "operator new не может быть переопределен в std". И таких сообщений там сотни.

VS 2008 Express до сих пор доступна для скачивания с сайта Microsoft. И пустая DLL под автокад, с заголовками из ObjectARX 2011, в ней собирается без проблем. Но для нанокада опять фокусы с заголовками SDK - как минимум в одном из них классы определяются с использованием CStringW; в других есть ссылки на "afxwin.h". Как я понимаю, это значит, что для сборки нужна VS 2008 Professional, с библиотеками ATL и MFC. Можно в opensource-проекте иметь ссылки на коммерческие библиотеки, которые сегодня, похоже, и купить уже нельзя?

[nickname2019]

Сообщение от Нубий-IV Может, это просто кривые руки... Я сижу под бесплатным пятым нанокадом, и автокадовская версия мне не интересна. Я проверил возможность собрать это все под нанокад в двух версиях студии. В обоих случаях до моего кода дело не доходит - сотня ошибок набирается прямо в SDK, и компиляция останавливается. VS 2019 Community не желает собирать даже пустой проект (в котором есть только точка входа в dll и ничего больше) - идет сплошная ругань на SDK-шные заголовки (они предназначены в оригинале для VS 2008). Например, "fabs не найдена в пространстве имен std". Если по советам из гугла сделать "std { #include <stdlib> }", то появляется противоположное требование - "operator new не может быть переопределен в std". И таких сообщений там сотни. VS 2008 Express до сих пор доступна для скачивания с сайта Microsoft. И пустая DLL под автокад, с заголовками из ObjectARX 2011, в ней собирается без проблем. Но для нанокада опять фокусы с заголовками SDK - как минимум в одном из них классы определяются с использованием CStringW; в других есть ссылки на "afxwin.h". Как я понимаю, это значит, что для сборки нужна VS 2008 Professional, с библиотеками ATL и MFC. Можно в opensource-проекте иметь ссылки на коммерческие библиотеки, которые сегодня, похоже, и купить уже нельзя?

Я думаю, что мы можем включать что угодно.
Мы пишем не бесплатное, а максимально открытое рабочее ПО.
Или мы напишем полностью открытое и бесплатное, но не рабочее ПО.
Nanocad раньше предоставлял бесплатную лицензию на Nanocad для разработчиков ПО (и SDK). Вы уверены, что нет смысла переходить на Nanocad более новой версии?
P.S.
Может проект перезамутить на Nanocad 10?

[Нубий-IV]

Сообщение от nickname2019 Может проект перезамутить на Nanocad 10?

Зачем? Все равно его надо собирать под разные версии. В моем наборе команд была папка с исходниками (одна-единственная, неизменная), и несколько файлов VS-2008.sln, VS-2012.sln, VS-2017.sln, VS-2018.sln, VS-2019.sln, в каждом из которых были свои настройки для акадов с 2005 по 2019, в каждом по несколько проектов, для всех поддерживаемых версий. Тут можно сделать так же, только еще и под нанокад настройки добавятся (теоретически они должны те же исходники переваривать, только я это еще не проверил, у меня студии не Pro).

Вот так оно должно выглядеть: "Портирование С++ приложений на платформу nanoCAD, использование страниц свойств проекта"

[nickname2019]

Сообщение от Нубий-IV Зачем? Все равно его надо собирать под разные версии. В моем наборе команд была папка с исходниками (одна-единственная, неизменная), и несколько файлов VS-2008.sln, VS-2012.sln, VS-2017.sln, VS-2018.sln, VS-2019.sln, в каждом из которых были свои настройки для акадов с 2005 по 2019, в каждом по несколько проектов, для всех поддерживаемых версий. Тут можно сделать так же, только еще и под нанокад настройки добавятся (теоретически они должны те же исходники переваривать, только я это еще не проверил, у меня студии не Pro).

Оставляем пока проект как есть? Нубий-IV сможет в нем участвовать?
Может версию студии понизить?

[Нубий-IV]

Сообщение от nickname2019 Может версию студии понизить?

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

В моих командах единственная вещь, которую пришлось сделать в исходниках - поставить в общем заголовке условную компиляцию, подменяющую один-единственный тип данных, который при смене версий в ObjectARX поменялся:

Код:

[Выделить все]

 #if	defined(RK_2008x32) || \
	defined(RK_2009x32) || \
	defined(RK_2010x32) || \
	defined(RK_2008x64) || \
	defined(RK_2009x64) || \
	defined(RK_2010x64)
		#define AdInt32 long
#endif

И в файлах проектов был задан соответствующий DEFINE для каждой версии. И тут должно быть что-то такое же.

Кстати, по ссылке выше описано использование страниц свойств для быстрой подмены настроек проекта. Если у каждого будет своя локальная страница свойств, можно не привязываться и к конкретным путям и версиям ObjectARX или автокада. А возможность один локальный файл настроек не синхронизировать наверняка есть у гитхаба.

[trir]

Нубий-IV может свою ветку сделать

[nickname2019]

Сообщение от Нубий-IV Исходники должны оставаться одними и теми же (по крайней мере, так обещают). А студию каждый может использовать какую хочет. Точнее, какую надо под свою версию акада или нанокада. Просто можно накидать несколько файлов SLN рядом, каждый под свою версию студии. В моих командах единственная вещь, которую пришлось сделать в исходниках - поставить в общем заголовке условную компиляцию, подменяющую один-единственный тип данных, который при смене версий в ObjectARX поменялся: Код: [Выделить все] #if defined(RK_2008x32) || \ defined(RK_2009x32) || \ defined(RK_2010x32) || \ defined(RK_2008x64) || \ defined(RK_2009x64) || \ defined(RK_2010x64) #define AdInt32 long #endif И в файлах проектов был задан соответствующий DEFINE для каждой версии. И тут должно быть что-то такое же.

Ясно. Создаем пустые проекты в студиях с 2008 по 2019, потом рабочие файлы (включая acrxEntryPoint.cpp) переносим в директорию common и оттуда подключаем к каждой версии студии + проставляем директивы условной компиляции, если что-то не заработает.
Т.е. делаем так, чтобы при редактировании каждым исходного кода каждым из своей версии студии редактировался каждый раз один и тот-же общий для всех студий файл.

[Нубий-IV]

Еще тонкость была. Все версии у меня собирались в студиях Express и Community. У них, в отличие от Pro, в комплекте нет библиотеки MFC, а ссылки на нее кое-где из ObjectARX есть (в палитрах, или еще где - не знаю, не добирался туда). И некоторые версии ObjectARX из-за этого не собирались, даже если я не использовал MFC явно. Причем компиляция проходила, а компоновщик останавливался, ссылаясь на пару не найденных символов. Помог трюк - эти переменные я объявил сам в файле StdAfx.cpp, и компоновщик стал использовать их. Компиляция на бесплатных версиях студий пошла. Кто для тех же версий ObjectARX будет собирать - может сделать так же.

Код:

[Выделить все]

 
#include "StdAfx.h"


#if defined(RK_2008x32) || defined(RK_2009x32) || defined(RK_2010x32)
	extern "C" int _afxForceEXCLUDE = 0;
	extern "C" int _afxForceSTDAFX  = 0;
#endif


#if defined(RK_2008x64) || defined(RK_2009x64) || defined(RK_2010x64)
	extern "C" int __afxForceEXCLUDE = 0;
	extern "C" int __afxForceSTDAFX  = 0;
#endif

[румата]

Сообщение от Нубий-IV У них, в отличие от Pro, в комплекте нет библиотеки MFC,

MFC есть в комплекте Community. Просто ее нужно доустановить

[nickname2019]

Сообщение от румата MFC есть в комплекте Community. Просто ее нужно доустановить

Т.е. поддержку MFC оставляем?
Диалоги из мфс удобно же брать.

[румата]

Сообщение от nickname2019 Т.е. поддержку MFC оставляем?

Как по мне, даром он не нужен в этом проекте

[nickname2019]

Сообщение от румата Как по мне, даром он не нужен в этом проекте

А диалоги на чем будем делать?
P.S. В древности я диалоги делал на дельфи, закидивал в dll, делал функцию вызова диалога внутри dll и вызвал как эту функцию из c++.
Но имхо, это не наш метод.
Мы не должны множить сущности, тем более микрософт мфс поддерживать вряд ли прекратит.

[3MEi86]

Нубий-IV, Посмотри личные сообщения

[румата]

Сообщение от nickname2019 А диалоги на чем будем делать?

При жуткой надобности диалога под рукой всегда есть WPF или WinForm

----- добавлено через ~3 мин. -----
Про такие диалоги идет речь?

[Сергей812]

Сообщение от румата При жуткой надобности диалога под рукой всегда есть WPF или WinForm

так MFC вроде и есть WinForm для плюсов.

[nickname2019]

Сообщение от румата При жуткой надобности диалога под рукой всегда есть WPF или WinForm

Ладно. Будем делать без mfc. А там как пойдет.
P.s. На горизонте замаячили скрипты и командная строка. Может быть, так и лучше.

[Akim_1989]

Всю тему не читал. Автору советую обратить внимание на Code Aster. Мощный решатель. Где-то даже находил пользовательские плагины для него по подбору армирования по EN.
Там по сути и препроцессор есть Salome. Осталось только нормальное задание жесткостей и материалов и прочее сделать.

----- добавлено через ~5 мин. -----
https://code-aster.org/UPLOAD/DOC/Fo...ementsce-2.pdf

[derik]

а чем Qt не устраивает? там есть простой дизайнер гуя

[румата]

Сообщение от Akim_1989 Автору советую обратить внимание на Code Aster. Мощный решатель.

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


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

Сообщение от derik а чем Qt не устраивает? там есть простой дизайнер гуя

Только Qt в винде не хватало

[Akim_1989]

Сообщение от румата Еще б кто рассказал по-русски как им пользоваться, куда вводить и что значат такие скрипты

По-русски по решателю мало инфы. Есть английское руководство по решателю на 3000 или 5000 стр. Не помню. Но нам то только нужны только стержни и пластины и относительно простая механика (а это я думаю листов 100-200). Можно разобраться, если время есть. У меня никак руки не доходят. Я только пару вводных примеров делал когда-то давно.
Тут основной минус, что команды на французском. Нужно привыкнуть.

----- добавлено через ~4 мин. -----
Ещё на видосы от индусов натыкался. Если базовый английский есть, то можно разобраться. Хотя индийский английский - это нечто

Нажмите для просмотра

https://www.youtube.com/watch?v=qZxoJVP0L98

[derik]

Сообщение от румата Только Qt в винде не хватало

он кроссплатформенный

[румата]

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

Понятно, я к тому, что для виндовс есть ничем не хуже, но родной WPF(с простым дизайнером гуя и пр.) идущий в комплекте с VS. Для чего таскать за собой по виндовс гигабайтный Qt?

[trir]

Только Qt в винде не хватало

Qt и AutoCAD

[румата]

Сообщение от trir Qt и AutoCAD

Для профессионального написания автокада или лиры, конечно, стОит купить Qt. А для написания дополнений к автокаду Qt точно избыточный. Кроме того, разве лицензия Qt разрешает его использование в open source проектах?

[zvezdochiot]

Сообщение от румата разве лицензия Qt разрешает его использование в open source проектах?

Так пользуй Qt4. И весить гораздо меньше будет.

[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 Техзадание опосля напишите?

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

[DEM]

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

Ну вот сперва нужно будет МКЭ считалку верифицировать...
Потом на расчеты строительных конструкций.
Практически это вряд ли выполнимо, без денежных вливаний и админтстративного ресурса.

[румата]

Сообщение от DEM Ну вот сперва нужно будет МКЭ считалку верифицировать...

Будет считалка - будет верификация. Просто взять любой набор примеров из любого коммерческого ПО и прогнать. А сертификация пусть идет боком. Выполнение конструктивных расчетов просто нужно сделать с открытой трассировкой, т.е. исключить закрытость нормативных расчетных алгоритмов.

[nickname2019]

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

На мой взгляд, эта задача является достаточно простой по логике, но весьма объемной в части количества простых задач.
Т.е. можно с понедельника потихоньку автоматизировать отдельные расчетные задачи по подбору сечений с составлением отчетов и ими можно уже начинать пользоваться по ходу дела.
Потом подтянется КЭ-решатель + сбор РСУ.
ТЗ как таковое будет составляться в процессе.
Конечно, неплохо бы было иметь какую-то автоматизированную систему, где можно бы было написать задачи, которые стоят перед разработчиками, чтобы желающие могли бы решить те задачи, которые хотят решить. Задач может быть много, начиная от оформления кнопок панелей инструментов или ленты.
Фактически может сложиться ситуация, что несколько человек делают одну задачу, что приведет к дублированию работ (и проблемам с объединением в единый проект, ибо непонятно какое решение лучше).
Т.е. ТЗ в данном случае может выглядеть как список задач.
Отсюда вопрос - в какой программе можно расписать стоящие задачи, чтобы она позволяла брать исполнителю ту задачу, которую он желает? Типа открытого общественного таскменеджера.

[румата]

Сообщение от nickname2019 Отсюда вопрос - в какой программе можно расписать стоящие задачи, чтобы она позволяла брать исполнителю ту задачу, которую он желает? Типа открытого общественного таскменеджера.

https://www.google.ru/intl/ru/sheets/about/

----- добавлено через ~3 мин. -----
https://www.office.com/launch/excel?...U&rs=RU&auth=1

[IBZ]

Ты можешь ходить как запущенный сад,
А можешь всё наголо сбрить,
И то и другое я видел не раз,
Кого ты хотел удивить ? (c)

Искренне желаю всем заинтересованным участникам успеха, но я был свидетелем таких начинаний не один раз. Ни в одном из случаев ничего путного, увы, не получилось ... Но поживем - увидим.

[румата]

Сообщение от IBZ но я был свидетелем таких начинаний не один раз.

Оно не удивительно, что ничего путного не выходит, удивительно будет, если что-то путное действительно выйдет. Не будьте просто свидетелем - присоединяйтесь в меру своих возможностей. У Вас достаточный багаж знаний и опыта для этого. Творите историю, так сказать

[zamtmn]

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

[IBZ]

Сообщение от румата Не будьте просто свидетелем - присоединяйтесь в меру своих возможностей.

Да нет, своё я уже много лет назад написал. А сейчас уже нет ни времени, ни желания даже написать новую "морду лица" - работаем спокойненько с Dos интерфейсом

Сообщение от румата У Вас достаточный багаж знаний и опыта для этого.

И они не вполне приемлют предлагаемую идеологию ...

Сообщение от румата Творите историю, так сказать

О как, ни больше, ни меньше .

[veb86]

Я полностью согласен с zamtmn и Сергей812, параллельно с форумом, надо весть онлайн блокнотик. Так что бы доступ на чтение имели все, а редактирование избранные. Без технического задания тяжело работать. В любом случае, как бы участники не рвали тельняшки, и не рвались в бой, данный поход за славой будет долгий! Краткое техническое задание, разбитое над подпункты просто необходимо, это как ориентир для движения(что бы народ не расползся по своим хотелкам). Там напротив каждого пункта, впишете имя героя кто будет ее решать

[fktstv]

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

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

Вот, например, если бы я хотел присоединиться к проекту:
Как выглядят исходные данные для расчета?
Отчет планируется формировать как в #198?
С помощью чего он сформирован?
Если в дальнейшем планируется прикрутить КЭ-решатель, значит расчет должен выполняться для каждого конечного/конструктивного элемента. Для каждого из них планируется выводить аналитический отчет с формулами?

В случае чего, прошу извинить мое невежество. Чукча совсем не программист.