[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?
С помощью чего он сформирован?
Если в дальнейшем планируется прикрутить КЭ-решатель, значит расчет должен выполняться для каждого конечного/конструктивного элемента. Для каждого из них планируется выводить аналитический отчет с формулами?

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

[Нубий-IV]

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

Если есть еще братья по халяве, краткая инструкция:

Visual Studio и SDK:

1. Версия Visual Studio - 2008 Professional, обязательно поставить Service Pack 1. Оба ISO-образа можно забрать с сайта Microsoft. Искать VS2008ProEdition90dayTrialENUX1435622.iso и VS2008SP1ENUX1512962.iso.
2. SDK ставится вместе с нанокадом (скачивать отдельно не нужно), и лежит рядом с ним в папке NanoCAD\SDK.

Настройка проекта:

1. Создать пустой проект. Добавить в него существующие *.h, *.cpp, *.def, которые раньше собирались под автокад.
2. Общие настройки проекта:
   Configuration type = Dynamic Library (.dll)
   Use of MFC = Use MFC in a Shared DLL
   Use of ATL = Not Using ATL
   Character set = Use Unicode Character Set
3. Настройки компилятора:
   Runtime Library = Multi-threaded DLL (/MD)
   Additional Include Directories = *\SDK\include;*\SDK\include\MAPI;*\SDK\include\TD;*\SDK\include\arxgate (вместо звездочки - свой путь к SDK)
   Additional options=/Zm115 (если компиляция обрывается с сообщением о нехватке памяти для прекомпилированных заголовков)
4. Настройки компоновщика:
   Additional Library Dictionaries=*\SDK\lib;*\SDK\lib\TD
   Additional Dependencies=nrxgate.lib
   Module Definition File=*.def

Изменения в коде:

1. Из заголовочных файлов нанокада автоматически подключаются заголовки MFC, а из них - windows.h. Если файл windows.h был подключен ранее, при компиляции будет ошибка "не включай два раза". Придется либо убрать windows.h из своих заголовков, либо вставить его в условную компиляцию:
   
   Код:

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

    
   #ifdef AUTOCAD
   	#include <windows.h>
   #endif
   

2. Макрос ACRX_T, которым в ObjectARX создают текст, в заголовках нанокада почему-то называется _ACRX_T. В stdafx.h придется задать переопределение:
   
   Код:

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

    
   #ifdef NANOCAD
   	#define ACRX_T _ACRX_T
   #endif
   

3. В DEF-файле имена экспортируемых функций надо исправить:
   acrxEntryPoint - заменить на ncrxEntryPoint (собственно, в заголовках SDK везде делается автоматическая замена префикса "ac" на "nc" - см. файл SDK\include\nrxgate\nc2ac.h, но DEF не обрабатывается препроцессором)
   acrxGetApiVersion - удалить, не используется

Проблемы:

• Попадаются функции, которые есть в ObjectARX, но отсутствуют в nanoCAD SDK. У меня это была только ads_regen(), но наверняка есть еще. Вызовы придется либо убирать вообще, либо переопределять функции, иначе компиляция невозможна.
• Попадаются классы, которые есть в ObjectARX, но отсутствуют в nanoCAD SDK. У меня - AcDbMline и AcDbMLeader. Видимо, будут еще. Компиляция невозможна. Вряд ли мы их переопределим, придется либо не реализовывать в нанокаде, либо отказываться от них и в автокаде.
• Самое неприятное - попадаются функции, которые формально есть в SDK, но фактически не реализованы в nanoCAD. То есть они компилируются, но при запуске команды с таким вызовом срабатывает заглушка, и выдается диалоговое окно с предложением "прервать/пропустить/всегда игнорировать". Команда при этом, разумеется, ничего полезного сделать уже не сможет. У меня это были:
  acrxRegisterAppMDIAware - не страшно, и без нее многооконный режим работает
  acedUndef - пока не понял, надо ли оно вообще
  acedSSGet - самое обидное, из-за нее половина моих команд просто не работает. Причем функция частично рабочая, с параметром ":$" выполняется, с параметром ":$:L" - нет.
• Замечена некорректная работа acutPrintf - в ней явно не опознается флаг форматирования %g - вместо числа выводится сам флаг: "Текущий шаг равен %g".

[nickname2019]

Сообщение от Нубий-IV Удалось собрать и заставить работать под бесплатным нанокадом мою старую подборку команд для автокада. Тест на собираемость в целом пройден, хотя и с оговорками. Если есть еще братья по халяве, краткая инструкция: ... Use of MFC = Use MFC in a Shared DLL ...

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

[zvezdochiot]

Сообщение от Нубий-IV Если файл windows.h был подключен ранее, при компиляции будет ошибка "не включай два раза".

Что за дела? Содержимое windows.h не завёрнуто в #ifndef ?

[Нубий-IV]

Сообщение от zvezdochiot Что за дела? Содержимое windows.h не завёрнуто в #ifndef ?

Можно придумать защиту от дурака, но только от неизобретательного (с) Мерфи

Цитата из MFC-шного заголовка:

Код:

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

 
#ifdef _WINDOWS_
	#error WINDOWS.H already included.  MFC apps must not #include <windows.h>
#endif

[nickname2019]

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

Конечная цель - создать открытый код программы по расчету конструкций, чтобы каждый мог им воспользоваться.
Т.е. мы пишем программу. Пишем, в основном, на с++.
Я бы хотел, чтобы к разработке мог подключиться любой желающий через GitHub.
Для этого я к понедельнику постараюсь подготовить исходные коды проекта для разных версий студий и загрузить их на PornHub GitHub.
Желающей должен самостоятельно скачать и установить одну из доступных ему версий студий и библиотеки для взаимодействия с граф. редактором.
Это будет описано в шапке темы.
В шапке будут приведены ссылки на нужные ресурсы.

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

Пишем процедуры для проверки на с++, сами определяемся какие исходные данные нужны. В коде процедуры все подробно описываем каждую строчку.

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

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

[zvezdochiot]

Сообщение от Нубий-IV Можно придумать защиту от дурака

Какая к чорту "защита от дурака"? Это стандартная схема построения хэдов общих либ.

[Нубий-IV]

Сообщение от zvezdochiot Это стандартная схема построения хэдов

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

[Сергей812]

Сообщение от nickname2019 Пишем процедуры для проверки на с++, сами определяемся какие исходные данные нужны. В коде процедуры все подробно описываем каждую строчку.

шикарное ТЗ. Наверно, ветку пока ещё читают опытные расчетчики без навыков программирования - и их просто выкидывают за борт: каждый "конструктор-программист" реализует свое виденье расчетов и не более того...

[nickname2019]

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

Убедили. ТЗ будет во вторник 05.10.2021.
Я сейчас пытаюсь решить проблему с совместимость проекта с Autocad 2015-2021.
Для ТЗ нужно придумать типы данных и набросать пример расчета какой-нибудь, чтобы можно было его обсудить и дальше по-аналогии делать.


Upd: по состоянию на текущий момент (02.10.2021) проект подготовлен для разработки для следующих версий:
...\source\VS2012(c++)ac2016\ - папка с проектом для Visual Studio 2012 и Acad 2016
...\GitHub\source\VS2015(c++)ac2018\ - папка с проектом для Visual Studio 2015 и Acad 2018
...\GitHub\source\VS2017(c++)ac2020\ - папка с проектом для Visual Studio 2017 и Acad 2020
...\GitHub\source\VS2019(c++)ac2021\ - папка с проектом для Visual Studio 2021 и Acad 2021

У этих сборок общий файл acrxEntryPoint.cpp, т.е. содержательная часть кода будет общая.

Также общим я сделал файл resource.h.

Можно пробовать подключаться, компилировать и проверять на наличие ошибок компиляции.
Обязательно нужно прочитать файл readme.md на GitHb для правильной настройки путей.

[Нубий-IV]

Для сборки понадобилось дополнительно подключить "extension.h" из include\nrxgate - это файл из нанокадовского SDK, без него InitAcUiDLL() не опознается. Таки нужен способ способ в исходниках отличать сборку под акад от сборки под нанокад.

Несколько вопросов к тем, про программирует по-большому:

1. Сейчас в проекте есть папка ArxLib с ObjectARX 2015-2021. Если туда накидать еще и "нанокад / брикскад / и все остальные" - будет несколько гигабайт библиотек, одна из которых и так должна быть у любого, кто взялся за сборку, а оставшаяся часть из них ему лично не нужна. Так вообще делают?
2. Абсолютные пути в проекте - это правильно? Наверняка принято пути делать относительными, и как-то переопределять настройки для локальной копии проекта.

[nickname2019]

Несколько вопросов к тем, про программирует по-большому:[list=1][*]Сейчас в проекте есть папка ArxLib с ObjectARX 2015-2021. Если туда накидать еще и "нанокад / брикскад / и все остальные" - будет несколько гигабайт библиотек, одна из которых и так должна быть у любого, кто взялся за сборку, а оставшаяся часть из них ему лично не нужна. Так вообще делают?

Я подумал, что будет удобно, если библиотеки разместить на общем репозитории, чтобы участнику не приходилось заниматься самостоятельным поиском, установкой библиотек и прописыванием к ним путей.
Я думаю, что не нужные библиотеки можно попробовать отключить от загрузки.
Может попробовать воспользоваться .gitignore, чтобы прописать пути к библиотекам, которые игнорируются?
Или воспользоваться импортном части репозитория https://pro-prof.com/forums/topic/git-subtree (кажется, там нужно действовать командами через консольную программу GitHub).

Абсолютные пути в проекте - это правильно? Наверняка принято пути делать относительными, и как-то переопределять настройки для локальной копии проекта.

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

[zvezdochiot]

Сообщение от nickname2019 библиотеки разместить на общем репозитории

Да Вас Autodesk и Nano распнут за копирайт! Ссылки в README указывайте и не более того.

[nickname2019]

Сообщение от zvezdochiot Да Вас Autodesk и Nano распнут за копирайт! Ссылки в README указывайте и не более того.

Свободное использование библиотек ObjectArx в проектом с открытым исходным кодом не нарушает лицензию Autodesk.
Формально библиотеки Autodesk нельзя использовать для разработки под NanoCad и т.д., но это согласие подписывается при вступлении в "клуб разработчиков". В этом смысле, на общем репозитории совместно размещать библиотеки от Autodesk и других вендоров, пожалуй, не стоит.
Кто хочет что-то свое не под автодеск - тот пусть действует исключительно на свой страх и риск.

[zvezdochiot]

Сообщение от nickname2019 Свободное использование библиотек ObjectArx в проектом с открытым исходным кодом не нарушает лицензию Autodesk.

В суде сможешь это доказать? "Бережёного Бог бережёт"

[nickname2019]

Сообщение от zvezdochiot В суде сможешь это доказать? "Бережёного Бог бережёт"

Во всех файлах с кодом ObjectArx прописана лицензия сверху с начала файла.

[zvezdochiot]

Сообщение от nickname2019 Во всех файлах

Я "слегка" другое спросил. Проконсультируйся для начала, а уж потом "Гоп".

[nickname2019]

Сообщение от zvezdochiot Я "слегка" другое спросил. Проконсультируйся для начала, а уж потом "Гоп".

Пока работаем. Если захотят закрыть - закроют просто на основании запрета на использование имени вендора в проекте.

[Сергей812]

nickname2019, кстати - а собственный скриптовый язык будете интегрировать в проект?

[nickname2019]

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

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

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

Сообщение от zvezdochiot Я "слегка" другое спросил. Проконсультируйся для начала, а уж потом "Гоп".

Спасибо. Библиотеки убраны с общего репозитория. Порядок их установки прописан в readme.md.
Это, видимо, создаст некоторые проблемы, так как придется отдельно скачивать и устанавливать библиотеки, но , наверное, это правильно.

[nickname2019]

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

[zamtmn]

>>ТЗ рекомендуется читать в Word'е
на гитхабе рекомендуется использовать md

при создании опенсурса рекомендуется использовать опенсурс инструменты

[zvezdochiot]

Сообщение от nickname2019 Задачи проекта.

Слишком много бинарного "мусора" в репе. Рекомендую переименовать репу в "mycop-bin", и на его базе сделать новую репу "mycop" только с сырцой и документацией.

[nickname2019]

Сообщение от zamtmn >>ТЗ рекомендуется читать в Word'е на гитхабе рекомендуется использовать md

спасибо. Сделано.

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

Сообщение от zvezdochiot Слишком много бинарного "мусора" в репе. Рекомендую переименовать репу в "mycop-bin", и на его базе сделать новую репу "mycop" только с сырцой и документацией.

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

[румата]

Сообщение от nickname2019 Задачи проекта.

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

[nickname2019]

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

В стандартной проводнике Windows создать директорию .Net не получилось - проводник пишет, что ошибка и нужно ввести имя файла.
Чтобы избежать этой проблемы создал папку Net (без точки в начале).
К сожалению, я не писал под Net, поэтому будет трудно создать рабочий проект с нужными настройками. Поэтому директория пока пустая.

[Нубий-IV]

Сообщение от nickname2019 В стандартной проводнике Windows создать директорию .Net не получилось

Можно запустить командный файл (или просто вставить это в командной строке):

Код:

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

c:
cd C:\GitHub\source\
md .Net

Сообщение от nickname2019 Может кто-то создаст нужный проект

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

Потому что если обсуждалась "библиотека" или "модульность" - то структура каталогов сейчас для этого очень странная. Многоязычная библиотека подразумевает папку с библиотекой МКЭ (и в ней подпапки плагинов импорта-экспорта в разные форматы); промежуточную библиотеку описания геометрии в своей папке (потому что начерченное в автокаде, например, не совпадает с тем, что передается в GMSH - нужен анализ и преобразование геометрии), к ней же - api под шарпы, питоны и язык текстового описания геометрии, позволяющий в блокноте в десять строк задать расчет серийного здания; библиотеку форматирования результатов (с плагинами под html, rtf, dxf и т.п.). И отдельно - ARX модуль; вот на него сейчас происходящее и похоже. Но, пока в нем нет вообще никакого реального содержания - непонятно даже, зачем замусоривать репозиторий всеми возможными вариантами пустых проектов (да еще и содержащими копии одних и тех же файлов)?

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

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

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

[trir]

Можно запустить командный файл (или просто вставить это в командной строке):

так и систему уронить можно

[nickname2019]

Сообщение от Нубий-IV Я пока вообще не понимаю что планируется сделать.

На данном этапе - генератор сеток как прописано в ТЗ + автоматическое задание нагрузок (ТЗ пока не готово). Если полученную сетку экспортировать в SCAD - это само по себе может существенно снизить трудоемкость.

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

Да. По идее, нужно создать схему программы в целом, чтобы потом каждый модуль дорабатывать. Раньше это делалось на UML (универсальный язык разметки), но он заточен на ООП и я с ним никогда не работал.

Сообщение от Нубий-IV Потому что если обсуждалась "библиотека" или "модульность" - то структура каталогов сейчас для этого очень странная. Многоязычная библиотека подразумевает папку с библиотекой МКЭ (и в ней подпапки плагинов импорта-экспорта в разные форматы); промежуточную библиотеку описания геометрии в своей папке (потому что начерченное в автокаде, например, не совпадает с тем, что передается в GMSH - нужен анализ и преобразование геометрии), к ней же - api под шарпы, питоны и язык текстового описания геометрии, позволяющий в блокноте в десять строк задать расчет серийного здания; библиотеку форматирования результатов (с плагинами под html, rtf, dxf и т.п.). И отдельно - ARX модуль; вот на него сейчас происходящее и похоже. Но, пока в нем нет вообще никакого реального содержания - непонятно даже, зачем замусоривать репозиторий всеми возможными вариантами пустых проектов (да еще и содержащими копии одних и тех же файлов)?

Я в любом случае планирую закночить проект на С++ и включить все в один файл ARX.
Были созданы несколько проектов для простой компиляции для нескольких версий Autocad. Это намного проще, чем писать для одной версии Autocad, потом заниматься переносом проекта на другую версию.
А если выпускать релизы с 2015 по 2021 autocad, то желающих протестировать будет много больше, чем если выпустить тестовый релиз под одну версию.

Сообщение от Нубий-IV По-моему, надо структуру программы определить, да начать заголовки с функциями накидывать. Будут у нас, например, суперэлементы для перекрытий (или вообще библиотечные суперэлементы с заранее обращенной матрицей для сверхбыстрого расчета панельных зданий)?

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

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

Суперэлементы это позволяют.

Сообщение от Нубий-IV Нестандартные КЭ для расчета ребер (а не городильня из несовместимых стержней-с-вставками-под-оболочкой)?

Это научно-исследовательская задача. Ее решение не гарантируется. Но вставки лучше не делать.

Сообщение от Нубий-IV Элемент надколонного участка с логарифмическими функциями формы?

Это бессмысленно для ЖБК. Пластика там все пики выравнивает.

Сообщение от Нубий-IV Узлы с пользовательским набором степеней свободы?

Да. Тип, который описывает степени свободы в узле должен содержать не только вектор типа double, но и ссылку на структуру, которая описывает, какую именно степень свободы описывает каждый элемент вектора. Это нужно, чтобы в одной схеме не путать механические КЭ и КЭ, которые, например, считают теплопроводность. Т.е. каждый КЭ должен проверять к тому ли типу узла он присоединен.

Сообщение от Нубий-IV Смешивание расчетов на разных сетках? И т.п. От этого зависит API и возможности расширения в будущем.

Сетки в любом случае примерно одинаковые. Имеется ввиду подключение расчетов различных полей (температурных, воздушных и т.д.)?

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

Это начинает упираться в детальное ТЗ по каждой процедуре и их взаимодействию. Видимо, это и есть самая трудоемкая задача.

[Сергей812]

Сообщение от nickname2019 Это начинает упираться в детальное ТЗ по каждой процедуре и их взаимодействию. Видимо, это и есть самая трудоемкая задача.

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

[румата]

Сообщение от nickname2019 К сожалению, я не писал под Net, поэтому будет трудно создать рабочий проект с нужными настройками. Поэтому директория пока пустая.

Спасибо. Я сам создам преднастроенный проект плагина к AutoCAD 2020-2021. Проект будет называться AcGmsh. Этот проект для реализации 1-го пункта ТЗ

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

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

А как будут осуществляться фиксации(коммиты)? Наверно стоит дать права для этого участникам проекта. Для добавления меня в команду разработчиков найдите на гитхабе пользователя rumata-ap.

[nickname2019]

Сообщение от румата Спасибо. Я сам создам преднастроенный проект плагина к AutoCAD 2020-2021. Проект будет называться AcGmsh. Этот проект для реализации 1-го пункта ТЗ А как будут осуществляться фиксации(коммиты)? Наверно стоит дать права для этого участникам проекта. Для добавления меня в команду разработчиков найдите на гитхабе пользователя rumata-ap.

Добавил (вроде бы).
Если что-то не работает - скажите, что делать. Я пока не сильно разобрался в GitHube.

[Нубий-IV]

Сообщение от nickname2019 На данном этапе - генератор сеток как прописано в ТЗ

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

Сообщение от nickname2019 Я в любом случае планирую закночить проект на С++ и включить все в один файл ARX.

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

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

По моему куцему опыту с автокадом на плюсах было еще проще. Одна версия студии позволяла сборку для трех версий акада (сейчас под vs2019 вроде как можно поставить еще старые компиляторы от предыдущих студий и зацепить еще больше версий). И у меня в VS2008 прямо в одном решении были несколько конфигураций сразу - 2008,2009,2010,2011,2012. Там вроде даже пакетная сборка была - можно поставить сразу несколько галочек и собрать все сразу. Формально 2008 и 2009 требуют студию 2005, но оказалось, что можно просто в готовом arx-файле, собранном в более поздней студии, подменить ссылки c msvcr90 на msvcr80, и все будет работать. А писать и отлаживать все равно будет один человек (и мы все догадываемся кто это), и вряд ли у него стоят сразу все версии акадов, нанокадов, и всех других кадов сразу. Вот уже собранное - протестируют многие. Но писаться-то оно будет под одну версию.

Сообщение от nickname2019 Суперэлементы это позволяют.

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

Сообщение от nickname2019 Это бессмысленно для ЖБК. Пластика там все пики выравнивает.

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

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

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

Сообщение от nickname2019 Т.е. каждый КЭ должен проверять к тому ли типу узла он присоединен.

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

[nickname2019]

Сообщение от Нубий-IV Тогда не нужны никакие шарпы или питоны, или что там еще упоминали. Если есть пользовательская команда, которая после выбора объекта сразу возвращает готовый результат - то она на одном языке и будет. Что там планируется в NET-папке держать? Пользовательскую команду на шарпе, которая вызовет единственную команду на плюсах?

Я думаю, что есть много людей, которые хотели бы писать на .Net. Скорее всего, их больше, чем желающих писать на c++. Код более-менее близок, я думаю, что можно как-то скооперироваться. Кроме того, команды, написанные на .Net (например- проверка сечений), можно вызвать из c++.
Так как код c++ и .Net похож, наверняка логическую часть будет несложно переносить туда-сюда.

А теплотехника разве предполагается?

Проще сразу прописать тип данных, который бы позволял определить любое количество степеней свободы в узле (температуру, скорость и т.п.). Это несложно, но даст гибкость.
Т.е. степень свободы определяется
- именем степени свободы (CString); - фактически это будет ссылка на уникальный тип КЭ, а не значение для каждого узла;
- значением (double).

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

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

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

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

Т.е. если два плоских КЭ элемента соприкасаются в общем узле - очевидно, что этот узел тоже будет "плоским".

Щас думаю, как описать эти типы данных.

[Сергей812]

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

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

[Нубий-IV]

Сообщение от nickname2019 Так как код c++ и .Net похож, наверняка логическую часть будет несложно переносить туда-сюда.

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

Сообщение от nickname2019 команды, написанные на .Net (например- проверка сечений), можно вызвать из c++.

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

Сообщение от nickname2019 Щас думаю, как описать эти типы данных.

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

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

[DEM]

Че за танцы с бубнами, есть же FreeCAD в который уже встроен GMSH как плагин.
Там правда пайтон как внутренний скриптовый язык, но за то есть огромный плюс, можно библиотеки с помощью танцев с бубнами подцеплять.

[румата]

Сообщение от nickname2019 Добавил (вроде бы).

Спасибо. "Болванка" проекта создалась.

Сообщение от nickname2019 Если что-то не работает - скажите, что делать.

Все хорошо работает даже с мастер-веткой.

[Сергей812]

Сообщение от Нубий-IV Здесь совсем нет мелких библиотечных функций, через которые потом лисперы, шарперы и плюсера смогут "подбирать сечение балки". И соответственно, нет мелкой работы, которую смогли бы выполнить решившие немного поучаствовать - тут только большие объемы на одного.

и в конечном итоге

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

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

[румата]

Сообщение от Нубий-IV Что там планируется в NET-папке держать?

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

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

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

Это да, пробел. Но пока библиотеки еще никто не начал писать.

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

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

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

[veb86]

Читаю и офигиваю. Критики полно. Все спецы просто в пятом поколении, все знают, все советают, nickname2019 дай это, nickname2019 сделай то, но сами ничего не делают. А как он Вам сделает если он выступает в роли исследователя, для него все в новинку. Вот Нубий-IV ты столько умных расчетов предложил, по советовал сразу подготовить все названия функций, как вам первопроходец это даст, он сам не знает. nickname2019 - напиши им названия функции bigRedButton('plan.dwg').

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

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

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

Вот и Сергей812 себе задачу нашел, прям прекрасно уже вижу пункт в ТЗ:"API будущих библиотек". Всяко лучше обсуждать, то что уже хоть кем то продумано, особенно специалистом по API (если я не прав то поправте)

nickname2019 постарайтесь не обращать внимание на критику, диванные бойцы(сам такой) они это любят. Если бы zamtmn в свое время начал собирать народ и обсуждать с ним все аспекты и нюансы коллективного убийцы автокада, то кода было бы сейчас написано ровно на "hello world".
Вы им и так уже все дали (репу и коротенькое ТЗ), и все обсудили с ними. Те кто хотят что то сделать, начнут сами ставить себе задачи, обсуждать их с вами, выбирать направление их решения и решать их.

PS. Ни кого не хотел обидеть, если что извините. Это чисто критика критиков. nickname2019 удачи Вам!

[Сергей812]

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

только зачем тогда ТС в роли дебютирующего тимлида, если сами себе задачу поставили и сами решили на требуемом ЯП под рабочую программную платформу?)

[Нубий-IV]

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

Код:

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

 
#if AUTOCAD
	using Autodesk.AutoCAD.ApplicationServices;
	using Autodesk.AutoCAD.EditorInput;
	using Autodesk.AutoCAD.Runtime;
	using Autodesk.AutoCAD.DatabaseServices;
#elif NANOCAD
	using HostMgd.ApplicationServices;
	using HostMgd.EditorInput;
	using Teigha.Runtime;
	using Teigha.DatabaseServices;
#endif

Сообщение от nickname2019 Щас думаю, как описать эти типы данных.

Вспомнил, где видел похожее - в программе "Fem Models". Там и в узле разные физические параметры есть, и пользовательские КЭ, и API для них. Есть демка с исходниками на паскале. Станица загрузки вроде тут: http://georeconstruction.net/index.p...d=57&Itemid=63

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

Это не расчеты. Это предложения, которые противоречат ТЗ. Например, надколонный элемент возле края плиты и тавровый элемент - оба шестиузловые; как их отличить, если элементы хранятся в виде полилиний? А если даже надколонный элемент выбросить, и убрать неопределенность - как размеры ребра определить по "просто полилинии"? А элемент свайного поля - вообще не требует генерации сетки, он состоит из уже существующих узлов схемы, и такой вообще сейчас задать нельзя. Отсюда и вопрос - работаем по ТЗ и отбрасываем эти идеи сразу, или будут какие-то изменения? Это не критика, это уточнение.

Сообщение от veb86 что тебя надо что бы выполнить данный расчет?

Соглашения о входных и выходных данных. Сначала нужно посчитать матрицу жесткости элемента и куда-то ее записать. Где и в каком виде она хранится - в XData, во внешнем файле, во временно выделенной памяти? Это массив; список; что-то еще? Это часть объекта КЭ, или отдельный объект? А решатель должен эту матрицу прочитать и вставить в глобальную матрицу. Или элемент сам должен себя туда записать? А результаты расчета я забираю в элемент, или решатель их туда заносит? Решатель разрабатывает кто-то другой. Как он сможет использовать мой КЭ, если мы с ним об этом не договорились заранее? Ответ один - ждать, пока все, кто пишет свои элементы, не напишут их полностью, и только потом начать что-то делать. То же - с тем, кто оформляет расчет: ему нужен доступ и к элементам, и к результатам; надо опять ждать, пока их не напишут.

Сообщение от румата Это да, пробел.

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

Сообщение от veb86 nickname2019 - напиши им названия функции bigRedButton('plan.dwg').

См. файл https://github.com/chaosEagleOwl/sou...EntryPoint.cpp - там именно это и сделано. Задана единственная функция, которая запрашивает ввод, делает расчеты и оформляет результаты. Не могут одну функцию одновременно писать десять человек, даже в системе контроля версий.

[veb86]

Сообщение от Сергей812 только зачем тогда ТС в роли дебютирующего тимлида, если сами себе задачу поставили и сами решили на требуемом ЯП под рабочую программную платформу?)

Так остальные крутые тимлиды сидят и ждут когда все появится, он с 2019 года на форуме, а Вы?

Сообщение от Нубий-IV Это не расчеты. Это предложения, которые противоречат ТЗ. Например, надколонный элемент возле края плиты и тавровый элемент - оба шестиузловые; как их отличить, если элементы хранятся в виде полилиний? А если даже надколонный элемент выбросить, и убрать неопределенность - как размеры ребра определить по "просто полилинии"? А элемент свайного поля - вообще не требует генерации сетки, он состоит из уже существующих узлов схемы, и такой вообще сейчас задать нельзя. Отсюда и вопрос - работаем по ТЗ и отбрасываем эти идеи сразу, или будут какие-то изменения? Это не критика, это уточнение.

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

Сообщение от Нубий-IV Сначала нужно посчитать матрицу жесткости элемента и куда-то ее записать. Где и в каком виде она хранится - в XData, во внешнем файле, во временно выделенной памяти? Это массив; список; что-то еще?

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

Сообщение от Нубий-IV Это часть объекта КЭ, или отдельный объект?

Начните с отдельного объекта, закончите сделайте часть объекта. Сделайте то что точно будет нужно в модуле.

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

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

Сообщение от Нубий-IV То же - с тем, кто оформляет расчет: ему нужен доступ и к элементам, и к результатам; надо опять ждать, пока их не напишут.

Вот блин даже он не может работать. У Вас вся проблема в исходных данных

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

[румата]

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

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

[nickname2019]

Сообщение от Нубий-IV Соглашения о входных и выходных данных. Сначала нужно посчитать матрицу жесткости элемента и куда-то ее записать. Где и в каком виде она хранится - в XData, во внешнем файле, во временно выделенной памяти? Это массив; список; что-то еще? Это часть объекта КЭ, или отдельный объект? А решатель должен эту матрицу прочитать и вставить в глобальную матрицу. Или элемент сам должен себя туда записать? А результаты расчета я забираю в элемент, или решатель их туда заносит?

Да. Это важные вопросы, которые нужно обсудить определить сразу.
Матрицы жесткости (локальные суперэлементов и глобальные), видимо, нужно хранить во внешних файлах. Чтобы их заново не обращать, возможно, можно придумать их сопоставление через хэш-коды (т.е. составили матрицу, посчитали ее хэш код и сравнили с шэш-кодами ранее обращенных матриц, если они есть - берем уже обращенную матрицу, не пересчитывая).
Матрицы, видимо, нужно хранить для каждого проекта отдельно.
Т.е. нужно вводить глобальную переменную - имя текущего проекта и для этого проекта создавать каталог на диске.
Я долго пытался найти инструмент для описания структуры программы, но ничего удобнее блок-схемы в dwg не смог найти. Т.е. в ближайшее время я постараюсь выложить блок-схему КЭ-решателя с описанием типов и код на c++.
Видимо, создание структуры программы нужно вести параллельно на с++ и с формированием блок-схемы в файле dwg.

Сообщение от Нубий-IV См. файл https://github.com/chaosEagleOwl/sou...EntryPoint.cpp - там именно это и сделано. Задана единственная функция, которая запрашивает ввод, делает расчеты и оформляет результаты. Не могут одну функцию одновременно писать десять человек, даже в системе контроля версий.

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

Нашел пример решателя на .Net https://github.com/BriefFiniteElemen...iteElement.Net. Видимо, можно как-то пользоваться.
Есть одно неудобство - фактически для расчета железобетона нам нужен анизотропный КЭ (ортотропный с произвольной ориентацией осей ортотропии), который бы учитывал даже в упругой стадии разность в площадях армирования по разным направлениям.
Например, стены подвала работают преимущественно в вертикальном направлении и в этом направлении у них жесткость намного выше, а горизонтальная арматура должна быть меньше. Но в рамках изотропного КЭ жесткость стены везде одинакова, что может существенно не соответствовать реальности.

Возникает необходимость вывода матрицы жесткости треугольного и четырехугольного КЭ анизотропной оболочки (через численное интегрирование), так как готовую мы 100% не найдем. Изотропная пластина Кирхгофа-Лява скорее всего есть в https://github.com/BriefFiniteElemen...iteElement.Net.

Пример вывода пространственного анизотропного КЭ (массив) у меня где-то был.

[zamtmn]

>>См. файл https://github.com/chaosEagleOwl/sou...EntryPoint.cpp
>>>>acutPrintf(_T("\nÂûáåðèòå îòðåçêè è ïîëèëèíèè, îïèñûâàþùèå êîíòóð ïðîäàâëèâàíèÿ: "));
разберитесь с кодировкой

[nickname2019]

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

Голосование по поводу выбора языка уже было. Победил матерный https://forum.dwg.ru/showthread.php?t=10660&page=1.

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

Сообщение от zamtmn >>См. файл https://github.com/chaosEagleOwl/sou...EntryPoint.cpp >>>>acutPrintf(_T("\nÂûáåðèòå îòðåçêè è ïîëèëèíèè, îïèñûâàþùèå êîíòóð ïðîäàâëèâàíèÿ: ")); разберитесь с кодировкой

Спасибо. Но я не знаю как это исправить. На локальном репозитории с кодировкой все нормально.

[румата]

Сообщение от nickname2019 Видимо, создание структуры программы нужно вести параллельно на с++ и с

А в чем такое принципиальное отличие С++ от С без плюсов, что нужно параллелить создание?

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

Сообщение от nickname2019 Но я не знаю как это исправить.

C помошью Notepad++ изменить кодировку на utf8

[Сергей812]

Сообщение от veb86 Так остальные крутые тимлиды сидят и ждут когда все появится, он с 2019 года на форуме, а Вы?

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

Сообщение от veb86 И, пока он не выполнен, не будет массового подлючения участников.

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

[румата]

Сообщение от zamtmn разберитесь с кодировкой

Исправлено.

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

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

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

[veb86]

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

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

[Бахил]

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

[Сергей812]

Offtop:

Сообщение от румата А вообще бываю такие хорошие и математики и программисты одновременно?

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

[румата]

Сообщение от Бахил А "свободный" транслятор с плюсов имеется?

Найдем при крайней необходимости. Только присутсвие MFC в коде может всю трансляцию испортить. У тебя случайно не завалялось матриц жесткости для плоских анизотропных элементов?

[Сергей812]

Сообщение от veb86 Из сообщений Нубий-IV, я вообще стал сомневаться что в решателе будет высшая математика.

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

[Бахил]

Сообщение от румата У тебя случайно не завалялось матриц жесткости для плоских анизотропных элементов?

Это тема докторской. С изотропными сначала разберитесь. Зенкевич в помощь.

[румата]

Сообщение от Бахил Уилкинсон, Райнш. Справочник алгоритмов на языке Алгол. Линейная алгебра.

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

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

Сообщение от Бахил Это тема докторской.

Маловато берешь. Это тема работы не меньше, чем на нобелевскую премию.

[Бахил]

Сообщение от румата на нобелевскую премию

Нет. Математикам не светит.

[румата]

еше мешер https://www.berlios.de/software/tetgen/

[Нубий-IV]

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

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

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

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

Сообщение от румата В нанокадовской "тайге" нет объектов и функций для работы с регионами(областями)

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

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

Похоже, нашлось применение для MFC - диалог для путей к проекту, рабочим файлам и мешерам с решателями.

[румата]

Сообщение от Нубий-IV Но если области предполагалось использовать для логических операций с полигонами - тогда у нас проблема, надо звонить в Хьюстон.

Проблема не большая, можно обойтись и без свонка в Хьюстон. http://www.angusj.com/delphi/clipper.php

[румата]

Немного удалось повозиться с плоской триангуляцией без помощи GMSH триангуляцией. Результат в миниатюре. СтОит оно фиксации в общем проекте?

[nickname2019]

Сообщение от румата Немного удалось повозиться с плоской триангуляцией без помощи GMSH триангуляцией. Результат в миниатюре. СтОит оно фиксации в общем проекте?

Классно. Можно и включить. Может кто-то затестирует. Четырехугольные не поддерживаются?
Замкнутые внутренние полилинии можно, по идее, автоматически считать дырками, а незамкнутые - обязательными контурами, через которые должна проходить сетка.
У меня где-то была процедура сортировки подобных вещей, но она на плюсах.
Поискать?
p.s. имхо, gmsh все равно надо подключить будет.

[румата]

Сообщение от nickname2019 Четырехугольные не поддерживаются?

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

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

А если кто-то замкнутыми захочет нарисовать "недырки"?

Сообщение от nickname2019 У меня где-то была процедура сортировки подобных вещей, но она на плюсах. Поискать?

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

Сообщение от nickname2019 gmsh все равно надо подключить будет.

Это само собой разумеестся.

[nickname2019]

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

Я думаю, что не нужно время тратить. Там есть ограничение на размер внутреннего угла у четырехугольных КЭ, поэтому произвольно не получиться объединять два соседних треугольника в четырехугольник. Возможно, сетку придется изменять сильно. Имхо gmsh "привинтить" будет менее трудозатратно.

Сообщение от румата А если кто-то замкнутыми захочет нарисовать "недырки"?

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

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

[румата]

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

http://youtu.be/ZsNt4-W_DcE всего два человека написали такой набор плагинов. Да еще и исключительно на .net

----- добавлено через ~2 мин. -----
Может что-то подобное, но открытое есть смысл сделать?

[Нубий-IV]

Плагин - это маленькое дополнение к большой программе. Большую программу годами пишет команда программистов, а мелочи под нее - пользователи-инженеры. Инженерные расчеты в наших нормах в большинстве случаев состоят из нескольких формул. Если программа предоставляет доступ к чтению и записи результатов, к вызову решателя и т.п. - то написать плагин можно быстро. Что-то вроде "Calc(); foreach (e in Elements) e.C1 = e.Results.q / e.Results.z;" - и готовы коэффициенты постели. А мы-то с голым кадом ходим; мы пока если и можем что пользователю показать, большое и красное - то никак не заветную кнопку. Кад не понимает плиты с отверстиями или стены с проемами, не знает, что конечные элементы связаны в узлах, что палка-балка имеет сечение, что такое изополя и как их интегрировать, как чертить эпюры, как писать формулы и т.п. Ни одну инженерно-расчетную команду нельзя просто так взять и вызвать, потому что таких в каде вообще не водится. Все это надо сделать с нуля; благодаря каду у нас есть только система хранения палочек и их показ; даже опознать палочку как элемент конструкции - и то попотеть надо. По-моему, тут не "по-быстрому плагин сваляем", а на несколько лет работы. Чтобы было быстро - надо присосаться к чужой почти готовой расчетной программе, которая делает все что нужно, только почему-то не по нормам. Есть такая на примете?

[utrfm]

opensees, codeaster

[румата]

Сообщение от Нубий-IV Плагин - это маленькое дополнение к большой программе.

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

[nickname2019]

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

Я извиняюсь, что я торможу работу, но формат "работы в свободное время" к сожалению, не оставляет других вариантов.
Можем обсудить, какие именно плагины можно бы было разработать?

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

Сообщение от utrfm opensees, codeaster

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

[Нубий-IV]

Сообщение от румата работы с результптами счета, полученными из произвольной МКЭ программы.

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

Я вот работаю в "произвольной МКЭ-программе" - Stark ES. У него нет никаких API вообще. Дотянуться ни до исходных данных, ни до результатов через официальное программирование нельзя. Критерий прочности ЖБ в нелинейном расчете - относительная деформация, а в программе такой вид данных не визуализируется; какой плагин тут возможен? Режим монтаж - полностью ручной (вручную создаются копии всех стадий, вручную запускается расчет для каждой из них, вручную подбирается потом арматура в каждом из файлов; вручную запускается окончательный подбор арматуры, причем одновременный запуск нескольких копий невозможен - нужно сидеть и ждать, когда посчитается предыдущая задача); чем может помочь плагин и как он должен быть устроен? Взаимовлияние осадки свай учитывается только через 3D-модель грунта - круто, но "не совсем по нормам"; как мне извлечь результат расчета, который программа не умеет делать?

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

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

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

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

Выше я давал ссылку на старый FEModels - вот у него такая фишка была: можно добавлять свои элементы с произвольными степенями свободы и результатами. Даже свой GUI для создания пользовательских элементов был, и исходники для тех элементов, что идут в комплекте - стержни, плиты, связи, нагрузки. Демка с ограничением по размеру задач до сих пор доступна. Например, набор типов посмотреть можно - в папках elements и templates. Если "плагины" имеются в виду такие - то можно структуру типов оттуда взять.

[zvezdochiot]

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

См. https://github.com/tuxera/ntfs-3g . Реверс-инженеринг NTFS от Microsoft.

Сообщение от Нубий-IV Плагин - это как у винампа? Положил в папочку "плагины" и в программе появились новые крутые фишки? Главный вопрос тогда - что за программа поддерживает инженерные плагины?

Ну ежели пошла такая песня, то LibreCAD (https://github.com/LibreCAD/LibreCAD) полностью укомплектован API для плагинов. Вот только сам он чудовищен.

Есть ещё "козырной" вариант: использовать API библиотеки LiteCAD (https://kolbasoft.com/). Но у неё сохранение в DXF через раз.

[nickname2019]

Сообщение от Нубий-IV Если на гитхабе обнаружится проект, который использует реверс инжиниринг коммерческих программ - гитхаб такое не банит вместе со всеми участниками? Я вот работаю в "произвольной МКЭ-программе" - Stark ES. У него нет никаких API вообще. Дотянуться ни до исходных данных, ни до результатов через официальное программирование нельзя. Критерий прочности ЖБ в нелинейном расчете - относительная деформация, а в программе такой вид данных не визуализируется; какой плагин тут возможен? Режим монтаж - полностью ручной (вручную создаются копии всех стадий, вручную запускается расчет для каждой из них, вручную подбирается потом арматура в каждом из файлов; вручную запускается окончательный подбор арматуры, причем одновременный запуск нескольких копий невозможен - нужно сидеть и ждать, когда посчитается предыдущая задача); чем может помочь плагин и как он должен быть устроен? Взаимовлияние осадки свай учитывается только через 3D-модель грунта - круто, но "не совсем по нормам"; как мне извлечь результат расчета, который программа не умеет делать? Единственное, что я смог - экспортировать исходную схему из када в текстовый формат исходных данных (по той же схеме, что тут планируется - через слои с параметрами). И, как активный пользователь своей программы, могу сказать, что это неудобно. Неудобно не видеть заливку плиты, чтобы опознать отверстия. Неудобно иметь десятки и сотни слоев с параметрами. Неудобно не видеть, чем одна нагрузка отличается от другой, пока не ткнешь в нее и не посмотришь свойства. Неудобно экспортировать геометрию отдельно от нагрузок, потому что "палочка с высотой" - это и проем, и нагрузка одновременно. Неудобно не видеть размеры шаблона сетки. И т.д. и т.п. Чтобы было удобно, объекты не должны быть просто палочками - а это требует создания собственных объектов с реальными свойствами на панелях свойств. Когда мне начинает казаться, что лучше переделать скрипт на плюсы с объектами - я прикидываю, сколько времени у меня это займет, выпиваю успокоительное и продолжаю есть кактус использовать скрипт.

Визуализацию исходных данных можно отдельно сделать с автоматическим выводом в отчет в удобоваримом виде, чтобы по отчету можно было все легко и быстро проверить. Можно, например, стены по уровням выводить в 3д с нагрузками при помощи тел или заштрихованными полилиниями.
После создания и отладки расчетного "ядра", которое будет обрабатывать исходные данные через простейшие объекты (отрезки, полилинии, текст, блоки), можно попробовать сделать обработку исходных данных через объекты. Но это отдельная задача (может быть трудной), так как связана уже с проектированием, а не расчетом. Это уже тянет за собой обмен данными с ifc, revit'ом, Autodesk Architecture и т.д.

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

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

Выше я давал ссылку на старый FEModels - вот у него такая фишка была: можно добавлять свои элементы с произвольными степенями свободы и результатами. Даже свой GUI для создания пользовательских элементов был, и исходники для тех элементов, что идут в комплекте - стержни, плиты, связи, нагрузки. Демка с ограничением по размеру задач до сих пор доступна. Например, набор типов посмотреть можно - в папках elements и templates. Если "плагины" имеются в виду такие - то можно структуру типов оттуда взять.

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

Баз данных подключаться никаких не планируется. Хранение данных - через стандартные классы
1) vector - для доступа к данным по индексу;
2) map - для быстрого доступа по ключу (например - для доступа к значению системной переменной по строке-имени переменной).

[румата]

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

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

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

Сообщение от nickname2019 Баз данных подключаться никаких не планируется. Хранение данных - через стандартные классы

Если имеется в виду бинарная сериализация сишных массивов, то это будет никуда не годное решение. Сериализовать массивы нужно в файлы открытых форматов типа xml, json, sqlite. В крайнем случае txt или csv.

[nickname2019]

Сообщение от румата Если имеется в виду бинарная сериализация сишных массивов, то это будет никуда не годное решение. Сериализовать массивы нужно в файлы открытых форматов типа xml, json, sqlite. В крайнем случае txt или csv.

Согласен. В бинарном виде только большие массивы имеет смысл хранить (матрицы жесткости, вектора перемещений и т.д.).

[Нубий-IV]

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

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

Сообщение от nickname2019 У меня есть процедура, которая считает жесткость пружинок-свай

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

Пример: три сваи в ряд, под нагрузкой 100т одна свая садится на 20мм, вторую досаживает на 5мм, до третьей не добивает.

Тогда, если загружены все три сваи, первая (левая) сядет на 20+5=25мм, вторая (средняя) на 20+5+5=30мм, третья (правая) на 20+5=25мм.
Жесткости получаются R1 = 100/25 = 4т/мм, R2 = 100/30 = 3.3 т/мм, R3 = 100/25 = 4 т/мм.

А теперь - другое загружение, загружена только средняя свая. Получается осадка первой сваи нулевая (вместо 5мм), средней - 100/3.3 = 30мм (вместо 20мм), третьей - опять ноль (вместо 5мм). Это что-то совсем не "по СП".

Можно сделать по-другому. Если осадка первой сваи от загружения первой сваи равна 20мм, от загружения второй сваи - 5мм, и от загружения третьей - 0, то можно найти не жесткости, а податливости: C11 = 20/100 = 0.20мм/т, C12 = 5/100=0.05мм/т, C13 = 0. При произвольном загружении осадка будет равна Z1 = C11*F1 + C12*F2 + C13*F3 = 0.20*F1 + 0.05*F2. А для всех трех свай уравнение получается:


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




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

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

[zvezdochiot]

Сообщение от Нубий-IV хоть какой-то повод писать свою программу

Плохо получилось. Совершено непонятно на кой чорт данной решалке взаимодействовать с Autocad-ом.

[DEM]

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

Это самый правильный вариант.
Или же найти готовый проект с решателем.
Вы даже не сравнивали готовые решения с тем что хотите реализовать.
Тот же FreeCAD уже умеет делать то что вы хотите из коробки фактически(в части создания сеток про решатель пока не говорю).

[nickname2019]

Сообщение от DEM Это самый правильный вариант. Или же найти готовый проект с решателем. Вы даже не сравнивали готовые решения с тем что хотите реализовать. Тот же FreeCAD уже умеет делать то что вы хотите из коробки фактически(в части создания сеток про решатель пока не говорю).

Посмотрите ТЗ на модуль генерации сеток (ссылка в шапке) и скажите, какой из существующих свободных "решателей" позволяет это сделать "из коробки"?

Есть готовые проекты с решателями с открытым кодом (ссылки уже были выше, их много), например : https://github.com/BriefFiniteElemen...iteElement.Net
Осталось разобраться и приспособить под себя.
Одна из текущих задач - найти в коде функцию формирования матрицы жесткости КЭ оболочки. Не хотите поучаствовать в процессе?

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

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

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

Поэтому я грунт бОльшую половину сознательной деятельности считаю в двух вариантах:
- на жестком основании;
- на упругом основании.
И по этим двум вариантам строю огибающую эпюру армирования.

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

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

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

Короче говоря, хочешь сделать хорошо - сделай сам.

----- добавлено через ~40 мин. -----
И последний вопрос - библиотеку eigen (работа с линейной алгеброй и матрицами) будем включать в репозиторий?

[румата]

Сообщение от Нубий-IV Получился трехузловой конечный элемент с матрицей жесткости R.

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

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

Сообщение от nickname2019 И последний вопрос - библиотеку eigen (работа с линейной алгеброй и матрицами) будем включать в репозиторий?

Нет смысла, если она есть в открытом доступе.

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

Сообщение от nickname2019 Короче говоря, хочешь сделать хорошо - сделай сам.

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

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

Сообщение от zvezdochiot Совершено непонятно на кой чорт данной решалке взаимодействовать с Autocad-ом.

В автокаде удобно рисовать. Не нужно писать собственную рисовалку или разбираться с чужой бесплатно одаренной.

[Нубий-IV]

Сообщение от румата почему именно трехузловой

Потому что в примере три сваи. Будет двадцать свай - будет двадцатиузловой. Это реализация формул 7.38-7.40 СП 24.13330.2011 для куста.

Сам СП в расшифровке формул тонко шутит про "удобно использовать метод сил"; осталось написать удобную инженерную программу с методом сил вместо МКЭ - она у нас следующей в списке пойдет. Ну, или можно преобразовать метод сил в метод перемещений - у них матрицы как раз взаимно обратные.

Сообщение от румата для всего свайгого поля

А к свайному полю с СП другие формулы - там уже аналог модуля "ГРУНТ" придется делать, плюс элементы продавливания ячейки грунта по п.7.4.8. Это гораздо дольше, чем отдельно взятый куст одолеть.

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

Без учета расстояния - это модель с одним коэффициентом постели. А если ввести второй коэффициент - уже получается взаимоучет осадок непосредственных соседей. А плита на 3D-грунте - это уже учет влияния каждого элемента на каждый.

[румата]

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

Я так и не понял каким образом во фрикаде учитываются отверстия в контурах и добавляются в сетку embeddet point, curve или surface.

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

Сообщение от Нубий-IV Потому что в примере три сваи. Будет двадцать свай - будет двадцатиузловой.

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

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

Сообщение от Нубий-IV Сам СП в расшифровке формул тонко шутит про "удобно использовать метод сил"

Так это он "шутит" только ради учета взаимодействия с надземной частью, а не ради взаимодействия свай между собой.

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

Сообщение от Нубий-IV А к свайному полю с СП другие формулы - там уже аналог модуля "ГРУНТ" придется делать, плюс элементы продавливания ячейки грунта по п.7.4.8. Это гораздо дольше, чем отдельно взятый куст одолеть.

Отдельный куст одолеть это от 2-х сасов до пол дня времени. http://webcad.pro/sv_os_ku/sv_os_ku_2.html
А вот аналог ГРУНТа вещь очень необходимая и крайне востребованная.

[nickname2019]

Сообщение от Нубий-IV А к свайному полю с СП другие формулы - там уже аналог модуля "ГРУНТ" придется делать, плюс элементы продавливания ячейки грунта по п.7.4.8. Это гораздо дольше, чем отдельно взятый куст одолеть.

Я делал расчет по старому СНИП.
1. Задается жесткость каждой "пружинки" примерно.
2. Делатеся расчет в составе каркаса и определяется усилие в пружинке.
3. Каждая свая заменяется условным фундаментом в уровне низа сваи.
4. Методом послойного суммирования с учетом взаимного влияния определяется осадка каждого условного фундамента, она же принимается равной осадке пружинки .
5. Определяется новая жесткость для каждой пружинки K = сила/осадка.
6. Пересчитываются пружинки в составе каркаса и определяются усилия в пружинках.
7. GOTO п.3. пока не надоест.

Формула с логарифмом из СП - имхо, какая-то неправильная, но я не проверял.

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

Сообщение от румата А вот аналог ГРУНТа вещь очень необходимая и крайне востребованная.

Она у меня есть в каком-то виде (надо искать где рабочая версия, тестировать, причесывать код).
Щас закончим мкэ-решатель и прикрутим модуль "Грунт 2.0" для свай.

[Сергей812]

Сообщение от nickname2019 Формула с логарифмом из СП - имхо, какая-то неправильная, но я не проверял.

прикольно расчетный модуль реализуете...

----- добавлено через ~29 мин. -----
хотя в заглавном посте было написано совершенно правильно

Сообщение от nickname2019 общепринятых и одобренных алгоритмов нет

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

[nickname2019]

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

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

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

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

[Нубий-IV]

Сообщение от румата используются только трех- или четырех- узловые элементы

Так я потому этот пример и привел. Он противоречит как идее реализовать только трех- и четырехугольники, так и идее хранить элементы полилиниями. И от этого зависит система типов, которая сейчас вроде как в состоянии сборки. Сделать два типа КЭ - и не будет ни суперэлементов, ни составных/библиотечных сложных элементов. А сделать как в FEModels - через запрос числа узлов у элемента - то в библиотеку еще и не такие извращения запихать можно будет.

Сообщение от nickname2019 Формула с логарифмом из СП - имхо, какая-то неправильная

Как я понимаю, это просто осадочная воронка вокруг сосредоточенной нагрузки. Может, это тоже результат интегрирования задачи для полупространства, а может - просто подходящая интерполяция.

Сообщение от румата Так это он "шутит" только ради учета взаимодействия с надземной частью, а не ради взаимодействия свай между собой.

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

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

[Сергей812]

Сообщение от nickname2019 Я бы хотел создать некий "скелет" с некоторым функционалом, который потом могло бы развивать общество

имхо, в данном случае "скелет" - это входные и выходные данные, и сам алгоритм расчета. Код - это следующий этап реализации. Тогда:

1. Смогут вносить свои предложения и уточнения расчетчики без навыков программирования.
2. Входные и выходные данные "преобразуются" в API.
3. Расчетный модуль изолирован от графического редактора (на акад сейчас свет клином не сошелся).
4. Если кто-то захочет - может переписать под другой ЯП.

[Бахил]

Вброшу свои 5 копеек.
Любая расчётная программа состоит из 3-х частей:
1) препроцессор;
2) процессор;
3) постпроцессор.
Процессор решает систему Rx = P,
где R - матрица жёсткости, P - вектор узловых нагрузок, x - искомые перемещения.
Задача препроцессора сформировать матрицу R и вектора Р.
Постпроцессор по найденным перемещениям х определяет внутренние усилия и/или напряжение и деформации, используя данные препроцессора.

----- добавлено через ~2 мин. -----
Я так понимаю, сейчас рассматривается препроцессор.

[nickname2019]

Сообщение от Бахил Вброшу свои 5 копеек. Любая расчётная программа состоит из 3-х частей: 1) препроцессор; 2) процессор; 3) постпроцессор.

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

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

[nickname2019]

По состоянию на 12.10.2021 обновление с описанием основных типов залито на GitHub.

Философски я подумал отказаться по максимуму от объектно-ориентированной модели. Объектом, видимо, будет только класс основного решателя (tFEMSolver).
Различные типы конечных элементов, описаний материалов и т.д. пока планируются как массивы типов-записей (struct), у которых некоторые поля будут процедурными переменными, назначаемыми в процессе выполнения.
Имхо, это позволит упростить объектную модель, сократить количество модулей и строчек кода.
Например, функция формирования матрицы жесткости описывается как процедурная переменная в записи, которая описывает тип конечного элемента.

1. созданы типы данных для описания конечно-элементной модели (Types.h). Файл желательно смотреть, комментарии написаны. Нужна ли доп. информация по документированию кода?
2. подключена библиотека eigen для работы с разряженными и плотными матрицами.

В readme.md описаны пути для хранения библиотеки eigen, чтобы настройки проектов не менять.

Можно пробовать собирать.


проблема у меня: eigen на текущей момент не компилируется с visual studio 2012. Так как в visual studio 2012 проект пока не собрался, Autocad 2016 пока не поддерживается (первый минус от того, что подключили стороннюю библиотеку).

P.S. Может быть, работать с eigen через "обертки", на случай, если придется менять математическую библиотеку?

[Нубий-IV]

Под VS2008/nanoCAD собирается, но требует более старую версию eigen - 3.1 (в текущей 3.4 не опознает новомодные шаблоны с переменным числом параметров, что, видимо, не лечится).

Похоже, VS2008 не опознает UTF-8 без BOM.

[румата]

Сообщение от nickname2019 Может быть, работать с eigen через "обертки", на случай, если придется менять математическую библиотеку?

Абсолютно не понятно каким образом могут помочь обертки eigen при смене его на другую библиотеку.

[nickname2019]

Сообщение от румата Абсолютно не понятно каким образом могут помочь обертки eigen при смене его на другую библиотеку.

Можно доступ к функциям из eigen делать через прокладки:

код вызывает функцию-прокладку-> прокладка вызывает функцию eigen.

Тогда при смене математического модуля придется переписать только "прокладки", а основной код не трогать.
Иначе светит глобальная переработка, например у меня в процедурном типе tLocalStiffnessMatrixProcedure используется входной параметр MatrixXd & localStiffnessMatrix, что привязывает дальнейший код к eigen

typedef bool (*tLocalStiffnessMatrixProcedure)(const tFiniteElement & finiteElement, const tPoint3dArray& point3dArray, const tMaterialArray & materialArray, const tSectionArray &sectionArray, MatrixXd & localStiffnessMatrix);

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

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

Сообщение от Нубий-IV Под VS2008/nanoCAD собирается, но требует более старую версию eigen - 3.1 (в текущей 3.4 не опознает новомодные шаблоны с переменным числом параметров, что, видимо, не лечится). Похоже, VS2008 не опознает UTF-8 без BOM.

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

[румата]

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

Думается замена коней на переправе не очень хорошая затея. Что "прокладки" переписывать, что основной код - хрен редьки не слаще. СтОит все ж окончательно определится на основе какой математической библиотеки(или сразу двух таких либ) будем строить свой решатель. Как по мне, то для .Net-реализации решения и хранения матриц стОит использовать Math.NET (https://numerics.mathdotnet.com/) т.к. эта библиотека уже является оберткой над самым производительным ядром для решения задач линейной алгебры IntelMKL (https://numerics.mathdotnet.com/MKL.html). Проив eigen (BLAS) ничего не имею, но его будет нужно "оборачивать" самостоятельно, чего делать вообще не хочется.

[nickname2019]

Сообщение от румата Думается замена коней на переправе не очень хорошая затея. Что "прокладки" переписывать, что основной код - хрен редьки не слаще. СтОит все ж окончательно определится на основе какой математической библиотеки(или сразу двух таких либ) будем строить свой решатель. Как по мне, то для .Net-реализации решения и хранения матриц стОит использовать Math.NET (https://numerics.mathdotnet.com/) т.к. эта библиотека уже является оберткой над самым производительным ядром для решения задач линейной алгебры IntelMKL (https://numerics.mathdotnet.com/MKL.html). Проив eigen (BLAS) ничего не имею, но его будет нужно "оборачивать" самостоятельно, чего делать вообще не хочется.

Вроде бы MKL доступна бесплатно только для студентов и некоторых исследовательских задач (https://softline.ru/uploads/ad/0d/e5.../3a/origin.pdf).

Вот сравнение eigen с какой-то boost
https://journal.tusur.ru/storage/495...pdf?1472809983

Видимо, надо найти нормальную библиотеку с линейной алгеброй под C#.

Под с++, видимо, придется оставить eigen, но чтобы сделать код максимально совместимым с .Net (а также с целью не привязываться к конкретной библиотеке), классы Eigen я уберу из основного кода.

В коде будет некоторый (может быть абстрактный) класс типа tLinearAlgebra, который будет вызывать методы из самой математической библиотеки.

[Бахил]

Offtop: О, уже до "решателя" добрались.

[nickname2019]

Сообщение от Бахил Offtop: О, уже до "решателя" добрались.

По моему мнению на данный момент, объем требуемого кода - до 2 тыс. строк. Остальное - существующие библиотеки.
Может быть больше с учетом функций проверки и подбора сечений (там сейчас трудно объем оценить).

[румата]

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

Оно бесплатно для пользования(не коммерческого) в Windows, т.к. у создателей Math.NET есть на него лицензия и потому MKL идет в составе Math.NET.

Be aware that unlike the core of Math.NET Numerics including the native wrapper, which are both open source under the terms of the MIT/X11 license, the Intel MKL binaries themselves are closed source and non-free. The Math.NET Numerics project does own an Intel MKL license (for Windows, no longer for Linux) and thus does have the right to distribute it along Math.NET Numerics. You can therefore use the Math.NET Numerics MKL native provider for free for your own use. However, it does not give you any right to redistribute it again yourself to customers of your own product. If you need to redistribute, buy a license from Intel. If unsure, contact the Intel sales team to clarify.

Перевод

Имейте в виду, что в отличие от ядра Math.NET Numerics, включая собственную оболочку, которые являются открытыми исходными кодами в соответствии с условиями лицензии MIT/X11, сами двоичные файлы Intel MKL являются закрытыми и несвободными. Проект Math.NET Numerics имеет лицензию Intel MKL (для Windows, а не для Linux) и, таким образом, имеет право распространять ее вместе Math.NET Numerics. Таким образом, вы можете использовать Math.NET Numerics MKL native provider бесплатно для собственного использования. Однако это не дает вам никакого права перераспределять его снова самостоятельно среди клиентов собственного продукта. Если вам необходимо провести повторное распространение, приобретите лицензию у корпорации Intel. Если вы не уверены, обратитесь в отдел продаж Intel для уточнения.

[nickname2019]

Сообщение от румата Оно бесплатно для пользования(не коммерческого) в Windows, т.к. у создателей Math.NET есть на него лицензия и потому MKL идет в составе Math.NET.

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

[румата]

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

А мы его и не будем включать туда. Кому нужно сам его скачает и подключит для ускорения счета "адских" схем.

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

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

[Нубий-IV]

Сообщение от nickname2019 простой выход из ситуации

Мне помогло пересохранить как UTF с маркером BOM:

Если верить гуглу, разные версии компиляторов этот UTF - и BOMнутый, и неBOMнутый - ухитряются понимать по-разному. Вот VS2008 показывает файл без маркера правильно, а компилирует - неправильно; с маркером - все работает как надо. Другие студии - надо тестировать. (Пример - https://www.codeatcpp.com/2016/03/utf-8.html)

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

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

Будут как минимум проблемы при компиляции с eigen. Если для старых студий нужна старая версия, то в файле Types.h указывать полный путь к заголовкам (#include <C:\ArxLib\eigen\Eigen\Dense>) не годится: чтобы пересобраться под другую студию, надо будет каждый раз удалять старую папку с одной версией библиотеки и записывать другую версию.

Вообще предлагаю отвязать проекты от конкретных путей через свойства:

Фокус в том, что файл настроек окружения - это отдельный файл Environment.vsprops, в котором задана только пара макросов с путями, и каждому нужно поправить их под свое расположение библиотек; остальные настройки задаются по-прежнему в проекте, и их менять не придется. А пути к библиотекам после этого можно указывать просто - как и к другим стандартным "#include <Dense>".

Не соображу только, как настроить Git, чтобы он этот файл игнорировал: если включить его в gitignore сразу, то он не попадает в репозиторий, и его никто не скачает, чтобы настроить под себя; а если включить после добавления в репозиторий, то он уже не игнорируется. Как сделать, чтобы от с репозитория клонировался, но обратно после настройки уже не просился?

[румата]

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

Да, я тут еще вспомнил, что Math.NET, кроме собственного встроенного, использует еще и OpenBLAS в качестве нативного ядра линейной алгеьры, как альтернативу IntelMKL. Оно считает медленне MKL, но значительно быстрее встроенного.

[nickname2019]

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

[Нубий-IV]

Руководство по Git: https://habr.com/ru/post/150673/ - коротенько, на 300 страниц. В пятой главе вроде про совместную работу пишут. Я туда через пару месяцев дочитаю, наверное - тогда тоже смогу поучаствовать.

[veb86]

Товарищи почитайте со стороны что вы пишите!
Румата не обижайся, тебе сказали С++, что ты к ним пристал со своим С#. Делай рядом свой проект, используй какие хочешь библиотеки. Я думаю ребята помогут тебе подключится к своему. Если у тебя будет что то интересное, то подсмотрят. У вас есть лидер, смерись с eigen.
Нубий-IV, вот у руматы C#, а у тебя бесплатный нанокад...
Я кончено не специалист по гиту, но с ZCAD-ом все просто, перед коммитом делаешь ПУЛЛ, решаешь все конфликты на этом моменте, делаешь коммит(помечаешь те файлы которые отправляешь) и пушешь (отправляешь). Естественно работать надо через тортоисеГИТ
Подробнее только подскажет zamtmn

[румата]

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

Наше дело, как говорится, предложить. Ни к кому я не приставал. Я просто предложил готовое рабочее решение СЛАУ. Без танцев с бубнами вокруг сборки eigen.

Сообщение от veb86 У вас есть лидер, смерись с eigen.

Не вопрос, пусть будет eigen. Главное что б кто-то дал ему лад.

Сообщение от nickname2019 После того, как румата поменял кодировку arxentrypoint, у меня синхронизация перестала закачиваться на gitHub (наверно, это нормально, так как кодировка файлов другая совершенно).

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

[zamtmn]

>>Проект, кажется, выходит на финальный этап
оптимистично)))

[Сергей812]

Offtop:

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

ТЗ начинает приобретать какие то видимые черты скорее уж...

[Бахил]

Какое ТЗ? Полноценный проект. Осталось найти подрядчика. Можно и "хозспособом" реализовать.

[Нубий-IV]

Чуток поигрался с этой ЭйГейской библиотекой.

Код:

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

 
// Тест скорости вычисления матрицы жесткости треугольной балки-стенки
#include <iostream>
#include <ctime>
#include <Dense>

using namespace std;

// Обозначения по книге
// МКЭ в проектировании транспортных сооружений.1981.Городецкий
// Стр.34
double E = 3e7;
double mu = 0.2;
double a = 1.1;
double b = 1.2;
double c = 1.3;

Eigen::MatrixXd K(6,6);

// Тестирующая функция
typedef void (*test_function)();
void test(test_function f)
{
    unsigned start_time = clock();
    for(int i = 0; i < 1000000; i++)
        f();
    unsigned end_time = clock();
    cout << "Time: " << (end_time - start_time) << " msec\n";
}


// В лоб по формулам из книги без оптимизации
void f1()
{
    double k = E / (1 - mu*mu);

    K(0,0) = k*(((2*a-b)*b-a*a)*mu+2*c*c+b*(b-2*a)+a*a)/(4*a*c);
    K(0,1) = k*((a-b)*mu-b+a)/(4*a);
    K(0,2) = k*(b*(b-a)*mu-2*c*c+(a-b)*b)/(4*a*c);
    K(0,3) = k*((b+a)*mu+b-a)/(4*a);
    K(0,4) = k*((a-b)*mu+b-a)/(4*c);
    K(0,5) = -k*mu/2;

    K(1,0) = K(1,0);
    K(1,1) = k*(-c*c*mu+c*c+b*(2*b-4*a)+2*a*a)/(4*a*c);
    K(1,2) = k*((b-2*a)*mu+b)/(4*a);
    K(1,3) = k*(c*c*mu-c*c+(2*a-2*b)*b)/(4*a*c);
    K(1,4) = k*(mu-1)/4;
    K(1,5) = k*(b-a)/(2*c);

    K(2,0) = K(0,2);
    K(2,1) = K(1,2);
    K(2,2) = k*(-b*b*mu+2*c*c+b*b)/(4*a*c);
    K(2,3) = k*(-b*mu-b)/(4*a);
    K(2,4) = k*(b*mu-b)/(4*c);
    K(2,5) = k*mu/2;

    K(3,0) = K(0,3);
    K(3,1) = K(1,3);
    K(3,2) = K(2,3);
    K(3,3) = k*(-c*c*mu+c*c+2*b*b)/(4*a*c);
    K(3,4) = k*(1-mu)/4;
    K(3,5) = -k*b/(2*c);

    K(4,0) = K(0,4);
    K(4,1) = K(1,4);
    K(4,2) = K(2,4);
    K(4,3) = K(3,4);
    K(4,4) = k*(a-a*mu)/(4*c);
    K(4,5) = 0;

    K(5,0) = K(0,5);
    K(5,1) = K(1,5);
    K(5,2) = K(2,5);
    K(5,3) = K(3,5);
    K(5,4) = K(4,5);
    K(5,5) = k*a/(2*c);
}

// В формулы, полученные и оптимизированные в Maxima
void f2()
{
    double k = E / (1 - mu*mu);
    double t1 = 1/a;
    double t2 = 1/c;
    double t3 = a*a;
    double t4 = 2*a*b;
    double t5 = b*b;
    double t6 = -t5;
    double t7 = c*c;
    double t8 = -2*t7;
    double t9 = t5*mu;
    double t10 = -a;
    double t11 = b+t10;
    double t12 = mu+1;
    double t13 = -(t1*t11*t12)/4;
    double t14 = (t1*t2*(t9-a*b*mu+t8+t6+a*b))/4;
    double t15 = b*mu;
    double t16 = (t1*(t15+a*mu+b+t10))/4;
    double t17 = mu-1;
    double t18 = -(t11*t2*t17)/4;
    double t19 = -mu/2;
    double t20 = -2*t5;
    double t21 = -t7;
    double t22 = t7*mu;
    double t23 = (t1*(t15-2*a*mu+b))/4;
    double t24 = (t1*t2*(t22+t21+t20+t4))/4;
    double t25 = t17/4;
    double t26 = (t11*t2)/2;
    double t27 = -(t1*b*t12)/4;
    double t28 = (b*t2*t17)/4;
    double t29 = mu/2;
    double t30 = -t17/4;
    double t31 = -(b*t2)/2;

    K(0,0) = k*(-(t1*t2*(t9-2*a*b*mu+t3*mu+t8+t6+t4-t3))/4);
    K(0,1) = k*(t13);
    K(0,2) = k*(t14);
    K(0,3) = k*(t16);
    K(0,4) = k*(t18);
    K(0,5) = k*(t19);

    K(1,0) = K(1,0);
    K(1,1) = k*(-(t1*t2*(t22+t21+t20+4*a*b-2*t3))/4);
    K(1,2) = k*(t23);
    K(1,3) = k*(t24);
    K(1,4) = k*(t25);
    K(1,5) = k*(t26);

    K(2,0) = K(0,2);
    K(2,1) = K(1,2);
    K(2,2) = k*(-(t1*t2*(t9+t8+t6))/4);
    K(2,3) = k*(t27);
    K(2,4) = k*(t28);
    K(2,5) = k*(t29);

    K(3,0) = K(0,3);
    K(3,1) = K(1,3);
    K(3,2) = K(2,3);
    K(3,3) = k*(-(t1*t2*(t22+t21+t20))/4);
    K(3,4) = k*(t30);
    K(3,5) = k*(t31);

    K(4,0) = K(0,4);
    K(4,1) = K(1,4);
    K(4,2) = K(2,4);
    K(4,3) = K(3,4);
    K(4,4) = k*(-(a*t2*t17)/4);
    K(4,5) = 0;

    K(5,0) = K(0,5);
    K(5,1) = K(1,5);
    K(5,2) = K(2,5);
    K(5,3) = K(3,5);
    K(5,4) = K(4,5);
    K(5,5) = k*((a*t2)/2);
}

// Численное интегрирование по одной точке
void f3()
{
    double u = 1.0/3;
    double w = 1.0/3;
    double W = 0.5;

    double x = a*u + b*w;
    double y = c*w;

    Eigen::MatrixXd InvFuxy(6,6);
    InvFuxy(0,0) = 1;
    InvFuxy(0,1) = 0;
    InvFuxy(0,2) = 0;
    InvFuxy(0,3) = 0;
    InvFuxy(0,4) = 0;
    InvFuxy(0,5) = 0;

    InvFuxy(1,0) = -1/a;
    InvFuxy(1,1) = 0;
    InvFuxy(1,2) = 1/a;
    InvFuxy(1,3) = 0;
    InvFuxy(1,4) = 0;
    InvFuxy(1,5) = 0;

    InvFuxy(2,0) = (b-a)/(a*c);
    InvFuxy(2,1) = 0;
    InvFuxy(2,2) = -b/(a*c);
    InvFuxy(2,3) = 0;
    InvFuxy(2,4) = 1/c;
    InvFuxy(2,5) = 0;

    InvFuxy(3,0) = 0;
    InvFuxy(3,1) = 1;
    InvFuxy(3,2) = 0;
    InvFuxy(3,3) = 0;
    InvFuxy(3,4) = 0;
    InvFuxy(3,5) = 0;

    InvFuxy(4,0) = 0;
    InvFuxy(4,1) = -1/a;
    InvFuxy(4,2) = 0;
    InvFuxy(4,3) = 1/a;
    InvFuxy(4,4) = 0;
    InvFuxy(4,5) = 0;

    InvFuxy(5,0) = 0;
    InvFuxy(5,1) = (b-a)/(a*c);
    InvFuxy(5,2) = 0;
    InvFuxy(5,3) = -b/(a*c);
    InvFuxy(5,4) = 0;
    InvFuxy(5,5) = 1/c;

    Eigen::MatrixXd dfxy(3,6);
    dfxy(0,0) = 0;
    dfxy(0,1) = 1;
    dfxy(0,2) = 0;
    dfxy(0,3) = 0;
    dfxy(0,4) = 0;
    dfxy(0,5) = 0;

    dfxy(1,0) = 0;
    dfxy(1,1) = 0;
    dfxy(1,2) = 0;
    dfxy(1,3) = 0;
    dfxy(1,4) = 0;
    dfxy(1,5) = 1;

    dfxy(2,0) = 0;
    dfxy(2,1) = 0;
    dfxy(2,2) = 1;
    dfxy(2,3) = 0;
    dfxy(2,4) = 1;
    dfxy(2,5) = 0;

    Eigen::MatrixXd fexy = dfxy * InvFuxy;

    double k = E / (1 - mu*mu);
    Eigen::MatrixXd D(3,3);
    D(0,0) = k;
    D(0,1) = k*mu;
    D(0,2) = 0;

    D(1,0) = k*mu;
    D(1,1) = k;
    D(1,2) = 0;

    D(2,0) = 0;
    D(2,1) = 0;
    D(2,2) = k*(1-mu)/2;

    double DetJ = a*c;

    K = fexy.transpose() * D * fexy * DetJ * W;
}

// Численное интегрирование - оптимизировано с учетом нулей. Сразу вычисляется fexy
void f4()
{
    double u = 1.0/3;
    double w = 1.0/3;
    double W = 0.5;

    double x = a*u + b*w;
    double y = c*w;

    Eigen::MatrixXd fexy(3,6);
    fexy(0,0) = -1/a;
    fexy(0,1) = 0;
    fexy(0,2) = 1/a;
    fexy(0,3) = 0;
    fexy(0,4) = 0;
    fexy(0,5) = 0;

    fexy(1,0) = 0;
    fexy(1,1) = (b-a)/(a*c);
    fexy(1,2) = 0;
    fexy(1,3) = -b/(a*c);
    fexy(1,4) = 0;
    fexy(1,5) = 1/c;

    fexy(2,0) = (b-a)/(a*c);
    fexy(2,1) = -1/a;
    fexy(2,2) = -b/(a*c);
    fexy(2,3) = 1/a;
    fexy(2,4) = 1/c;
    fexy(2,5) = 0;

    double k = E / (1 - mu*mu);
    Eigen::MatrixXd D(3,3);
    D(0,0) = k;
    D(0,1) = k*mu;
    D(0,2) = 0;

    D(1,0) = k*mu;
    D(1,1) = k;
    D(1,2) = 0;

    D(2,0) = 0;
    D(2,1) = 0;
    D(2,2) = k*(1-mu)/2;

    double DetJ = a*c;

    K = fexy.transpose() * D * fexy * DetJ * W;
}

// Численное интегрирование. Массивы C-style. Перемножение вручную с учетом нулей.
double R[6][6];
void cout_R()
{
    cout << "K =\n";
    for(int i = 0; i < 6; i++) {
        for(int j = 0; j < 6; j++)
            cout << '\t' << R[i][j];
        cout << '\n';
    }
}

void f5()
{
    double u = 1.0/3;
    double w = 1.0/3;
    double W = 0.5;

    double x = a*u + b*w;
    double y = c*w;

    double ac = a*c;
    double ba = b-a;

    double fexy02 = 1/a;
    double fexy00 = -fexy02;
    double fexy11 = ba/ac;
    double fexy13 = -fexy11;
    double fexy15 = 1/c;
    double fexy20 = fexy11; // оптимизировать: не хранить повторы
    double fexy21 = fexy00;
    double fexy22 = fexy13;
    double fexy23 = fexy02;
    double fexy24 = fexy15;

    double k = E / (1 - mu*mu);
    double D00 = k;
    double D01 = k*mu;
    double D10 = D01;
    double D11 = D00;
    double D22 = k*(1-mu)/2;

    double Dfexy00 = D00*fexy00;
    double Dfexy01 = D01*fexy11;
    double Dfexy02 = D00*fexy02;
    double Dfexy03 = D01*fexy13;
    double Dfexy05 = D01*fexy15;

    double Dfexy11 = D11*fexy11;
    double Dfexy12 = D10*fexy02;
    double Dfexy13 = D11*fexy13;
    double Dfexy15 = D11*fexy15;

    double Dfexy20 = D22*fexy20;
    double Dfexy21 = D22*fexy21;
    double Dfexy22 = D22*fexy22;
    double Dfexy23 = D22*fexy23;
    double Dfexy24 = D22*fexy24;

    double DetJ = a*c;
    double WDetJ = W*DetJ;

    R[0][0] = WDetJ*(Dfexy20*fexy20+Dfexy00*fexy00);
    R[0][1] = WDetJ*(Dfexy21*fexy20+Dfexy01*fexy00);
    R[0][2] = WDetJ*(Dfexy22*fexy20+Dfexy02*fexy00);
    R[0][3] = WDetJ*(Dfexy23*fexy20+Dfexy03*fexy00);
    R[0][4] = WDetJ*(Dfexy24*fexy20);
    R[0][5] = WDetJ*(Dfexy05*fexy00);

    R[1][0] = R[0][1];
    R[1][1] = WDetJ*(Dfexy21*fexy21+Dfexy11*fexy11);
    R[1][2] = WDetJ*(Dfexy22*fexy21+Dfexy12*fexy11);
    R[1][3] = WDetJ*(Dfexy23*fexy21+Dfexy13*fexy11);
    R[1][4] = WDetJ*(Dfexy24*fexy21);
    R[1][5] = WDetJ*(Dfexy15*fexy11);

    R[2][0] = R[0][2];
    R[2][1] = R[1][2];
    R[2][2] = WDetJ*(Dfexy22*fexy22+Dfexy02*fexy02);
    R[2][3] = WDetJ*(Dfexy23*fexy22+Dfexy03*fexy02);
    R[2][4] = WDetJ*(Dfexy24*fexy22);
    R[2][5] = WDetJ*(Dfexy05*fexy02);

    R[3][0] = R[0][3];
    R[3][1] = R[1][3];
    R[3][2] = R[2][3];
    R[3][3] = WDetJ*(Dfexy23*fexy23+Dfexy13*fexy13);
    R[3][4] = WDetJ*(Dfexy24*fexy23);
    R[3][5] = WDetJ*(Dfexy15*fexy13);

    R[4][0] = R[0][4];
    R[4][1] = R[1][4];
    R[4][2] = R[2][4];
    R[4][3] = R[3][4];
    R[4][4] = WDetJ*(Dfexy24*fexy24);
    R[4][5] = 0;

    R[5][0] = R[0][5];
    R[5][1] = R[1][5];
    R[5][2] = R[2][5];
    R[5][3] = R[3][5];
    R[5][4] = R[4][5];
    R[5][5] = WDetJ*(Dfexy15*fexy15);
}

int main()
{
    cout << "Function test\n";
    f1();
    cout << "K = \n" << K << endl;

    f2();
    cout << "K = \n" << K << endl;

    f3();
    cout << "K = \n" << K << endl;

    f4();
    cout << "K = \n" << K << endl;

    f5();
    cout_R();

    cout << "Speed test\n";
    test(f1);
    test(f2);
    test(f3);
    test(f4);
    test(f5);

    return 0;
}

Результаты. Числитель - VS2008 + Eigen-3.1 / Знаменатель - GCC8 + Eigen-3.4.

• 16/47
  Аналитическое решение.
  Готовые формулы для элементов матрицы, взятые из книги. Наверное, можно еще чуть ускорить, если вынести повторы и сгруппировать умножения.
• 16/47
  Аналитическое решение.
  Те же формулы, полученные в символьном виде в Maxima, после функции Optimize(). Можно еще ускорить, если присваивать одноразовые временные переменные сразу в матрицу.
• 1015/797
  Численное интегрирование.
  Eigen - реализация формул МКЭ "Как в книге" - вычисление векторов координат, потом векторов коэффициентов, потом матрицы градиентов, и наконец матрицы жесткости [ K ]=[ B^T ][ D ][ B ].
• 625/391
  Численное интегрирование.
  Eigen - попытка оптимизации, за счет избавления от перемножения матриц с большим числом нулей. Так же сделано в примере на хабре из поста 137 - матрица градиентов вычисляется сразу, а не перемножением других матриц.
• 15/16
  Численное интегрирование.
  C-массивы. Ручное перемножение матриц с учетом нулей, симметрии и без лишнего прожорливого транспонирования.

Вопросы:

• Результаты зависят от компилятора. Может быть, другие Студии покажут другие результаты. Как бы не пришлось еще под каждый компилятор версии писать.
• Забавно, что ручное численное интегрирование обставило аналитику. Может, в более сложных элементах (меньше нулей, больше точек интегрирования, переменные жескости) будет больший объем счета, но там и формулы будут сильно сложнее.
• Типовая формула из учебников [ K ]=[ B^T ][ D ][ B ] что-то сильно тормозит. Даже с избыточным перемножением нулевых элементов, неучетом симметрии и лишним транспонированием - непонятно, откуда разница в десятки раз. Может, там Евгену что-то подкрутить надо в настройках?

Второй тест - решение систем.

Код:

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

 
// EigenTest.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"


int _tmain(int argc, _TCHAR* argv[])
{
	int MatrixSize = 200000;
	int BandWidth = 50;

	std::cout << "Stiffness matrix calulation...\n";
	unsigned start_time = std::clock();

	Eigen::SparseMatrix<double> K(MatrixSize, MatrixSize);
	std::vector<Eigen::Triplet<double>> T;
	for(int i = 0; i < MatrixSize; i++) {
		int bandMinIndex = std::max(0, i - BandWidth + 1);
		int bandMaxIndex = std::min(i + BandWidth, MatrixSize);
		for(int j = bandMinIndex; j < bandMaxIndex; j++) {
			double distance = i-j;
			double max_distance = BandWidth;
			double relativeDistance = distance / max_distance;
			T.push_back(Eigen::Triplet<double>(i, j, 1.0 - std::pow(relativeDistance, 2)));
		}
	}
	K.setFromTriplets(T.begin(), T.end());

	unsigned end_time = std::clock();
	std::cout << (end_time - start_time) / 1000.0 << " seconds\n";
	std::cout << "...done.\n\n";
	//K.coeffRef(0,0) = 0.0;

	std::cout << "Forces vector calulation...\n";
	start_time = std::clock();
	Eigen::VectorXd F(MatrixSize);

	for(int i = 0; i < MatrixSize; i++)
		F[i] = (double)i / MatrixSize;

	end_time = std::clock();
	std::cout << (end_time - start_time) / 1000.0 << " seconds\n";
	std::cout << "...done.\n\n";

	std::cout << "Equation system solving...\n";
	start_time = std::clock();

	Eigen::SimplicialLDLT<Eigen::SparseMatrix<double>> solver(K);
	Eigen::VectorXd x = solver.solve(F);

	end_time = std::clock();
	std::cout << (end_time - start_time) / 1000.0 << " seconds\n";
	std::cout << "...done.\n";

	//std::cout << "Solver info: " << solver.info() << std::endl;
	//std::cout << "\nStiffness:\n" << K << std::endl;
	//std::cout << "\nForces:\n" << F << std::endl;
	//std::cout << "\nDisplacements:\n" << x << std::endl;

	return 0;
}

Есть вопросы:

• Матрицы держит в памяти (вроде даже без учета симметрии - хранит и верх, и низ). Значит, большие схемы на слабом железе считать не выйдет?
• Не понимает, что ноль на диагонали - это автоматическая связь, а не ошибка расчета. Можно ему объяснить, что он неправ?
• Приостановка/возобновление расчета невозможны?

[bigden]

я конечно не спец в линейной алгебре, но

Сообщение от Нубий-IV Матрицы держит в памяти (вроде даже без учета симметрии - хранит и верх, и низ). Значит, большие схемы на слабом железе считать не выйдет?

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

Сообщение от Нубий-IV Не понимает, что ноль на диагонали - это автоматическая связь, а не ошибка расчета. Можно ему объяснить, что он неправ?

что это за фишка такая - расчет с нулем на диагонали? можно где-то посмотреть?

[zvezdochiot]

Сообщение от bigden я подозреваю, что это пережиток прошлого, когда компьютеры были большие, а память маленькая.

Да не только по алгебре неспец. Вообще в памяти не хранились, а каждый раз считывались с носителя. Так что мимо!

[Нубий-IV]

Сообщение от bigden держать полностью матрицу по времени должно быстрее получаться

Так ясен пень, что быстрее, если памяти хватает.

Простой тест: типовая свечка на двадцать этажей, схема в 120000 узлов - это совсем скромно; старк считает ее две минуты, из них решение системы - около 10сек; остальное время занимают чтение данных и запись результатов.

В протоколе указано число ненулевых элементов матрицы - 0.238 млрд. Если считать, что матрица хранится в виде значений double (8 байт) с двумя индексами int (2x4 байта), это требует расхода памяти 0.238*(8+2*4) = 3.8Gb. Примерно столько и лежит у старка в рабочем каталоге; пиковое потребление памяти в процессе счета у него меньше, т.е. матрицу он выгружает на диск.

Тот же тест в Eigen.
Проверил: при решении через SimplicialLDLT не нужно записывать нижний треугольник, т.е. избыточное хранение есть только в плотных матрицах - у нас такими будут разве что матрицы суперэлементов, если мы их оставим с типом MatrixXd, как сейчас сделано в Types.h.
В верхнем треугольнике матрицы размером N, с шириной ленты W, и оставшейся нулевой шириной Z=N-W хранится элементов. Значит, ширина ленты равна

Код:

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

 
#include <iostream>
#include <ctime>

#include <stdio.h>
#include <tchar.h>
#include <math.h>

#include <Eigen/Dense>
#include <Eigen/Sparse>

int _tmain(int argc, _TCHAR* argv[])
{
	int MatrixSize = 716229;
	int BandWidth = 333;

	std::cout << "Stiffness matrix calulation...\n";
	unsigned start_time = std::clock();

	Eigen::SparseMatrix<double> K(MatrixSize, MatrixSize);
	std::vector<Eigen::Triplet<double>> T;
	for(int i = 0; i < MatrixSize; i++) {
		int bandMinIndex = i;
		int bandMaxIndex = std::min(i + BandWidth, MatrixSize);
		for(int j = bandMinIndex; j < bandMaxIndex; j++) {
			double distance = i-j;
			double max_distance = BandWidth;
			double relativeDistance = distance / max_distance;
			T.push_back(Eigen::Triplet<double>(i, j, 1.0 - std::pow(relativeDistance, 2)));
		}
	}
	K.setFromTriplets(T.begin(), T.end());

	unsigned end_time = std::clock();
	std::cout << (end_time - start_time) / 1000.0 << " seconds\n";
	std::cout << "...done.\n\n";
	//K.coeffRef(0,0) = 0.0;

	std::cout << "Forces vector calulation...\n";
	start_time = std::clock();
	Eigen::VectorXd F(MatrixSize);

	for(int i = 0; i < MatrixSize; i++)
		F[i] = (double)i / MatrixSize;

	end_time = std::clock();
	std::cout << (end_time - start_time) / 1000.0 << " seconds\n";
	std::cout << "...done.\n\n";

	std::cout << "Equation system solving...\n";
	start_time = std::clock();

	Eigen::SimplicialLDLT<Eigen::SparseMatrix<double>> solver(K);
	Eigen::VectorXd x = solver.solve(F);

	end_time = std::clock();
	std::cout << (end_time - start_time) / 1000.0 << " seconds\n";
	std::cout << "...done.\n";

	//std::cout << "Solver info: " << solver.info() << std::endl;
	//std::cout << "\nStiffness:\n" << K << std::endl;
	//std::cout << "\nForces:\n" << F << std::endl;
	//std::cout << "\nDisplacements:\n" << x << std::endl;

	return 0;
}

Если собрать 32-битный проект, результат запуска будет таким:

Старенькие автокады x32 отпадают. На x64 результат получше:

Потрачено 7.4G памяти; у меня на рабочем компе память 16G, ее хватает. Забавно, что сборка матрицы шла в 10 раз дольше, чем решение системы; загрузка процессора 13% - работает 1 ядро из 8; и это без вычисления матриц жесткости элементов, просто запись чисел. То ли сборку надо распараллеливать, то ли операция добавления в матрицу тормозит; надо тестировать дополнительно.

Чтобы увеличить расход памяти, удвою ленту: W = 2*333 = 666. Результат:

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

Сообщение от bigden я конечно не спец в линейной алгебре

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

[nickname2019]

Сообщение от Нубий-IV Не понимает, что ноль на диагонали - это автоматическая связь, а не ошибка расчета. Можно ему объяснить, что он неправ?

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

Сообщение от Нубий-IV Приостановка/возобновление расчета невозможны?

Нужно в цикле проверять нажатие Esc. В автокаде есть примерно такой код.

Код:

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

 
acutPrintf(ACRX_T("\nФормирование матрицы...\r"));
 
acedSetStatusBarProgressMeter(ACRX_T("Формирвоание матрицы"), 0, n);

for (i=0;i<n;i++){

  if ( acedUsrBrk() ){
	// Perform cleanup on cancel
	bContinue = Adesk::kFalse;
	acutPrintf(ACRX_T("\nCancelled !"));
	break;
  }
  acedSetStatusBarProgressMeterPos(i);
//Делаем что-то
//....

}
acedRestoreStatusBar();

В посте #320 матрицу жесткости какого КЭ вычисляли? Этот код можно забрать в проект?


P.S. Судя по затратам времени на вычисления, делать класс - прокладку между eigen и основной программой - не самая удачная идея. Прокладка, видимо, будет тормозить расчет, так как количество вызовов процедур сразу в два раза вырастет (выделение/освобождение стека и т.д.).

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

[румата]

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

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

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

Сообщение от Нубий-IV Не понимает, что ноль на диагонали - это автоматическая связь, а не ошибка расчета. Можно ему объяснить, что он неправ?

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

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

Сообщение от Нубий-IV Забавно, что сборка матрицы шла в 10 раз дольше, чем решение системы;

Ну это же си++. Неоптимизированная сборка матрицы и оптимизированное решение системы.

[Нубий-IV]

Сообщение от nickname2019 Нужно в цикле проверять нажатие Esc.

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

Сообщение от nickname2019 Этот код можно забрать в проект?

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

В первой функции формулы взяты из книги Метод конечных элементов в проектировании транспортных сооружений.А.С. Городецкий, В.И. Зоворицкий, А.И. Лантух-Лященко, А.О. Рассказов. 1981 г..

В остальных функциях формулы получены в Maxima:

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

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

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

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

Eigen при появлении нуля на диагонали просто возвращает в Info код ошибки, а вектор ответа забивает большими числами (кому интересно - файле теста системы размер матрицы уберите в 10, чтобы на экран помещалась, и раскомментируйте строки 36 и 59-62). Ни усилия в схеме посмотреть, ни даже узнать, в каком узле сбой был.

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

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

В книгах по МКЭ много пишут про численное интегрирование. Родной для GMSH решатель GetDP, например, не матрицы элементов хранит, а запрашивает у пользователя число точек Гаусса и типы производных, а остальную арифметику крутит сам - т.е. у него все на матричных произведениях, а не на формулах. Я, когда тест скорости матриц затевал, думал - будет единственный безоговорочный победитель и явные аутсайдеры. А ответ меня удивил сильно. Теперь я никому не верю и все думаю проверять.

Сообщение от румата Неоптимизированная сборка матрицы и оптимизированное решение системы.

Обе операции - библиотечные функции. Вот эта троица работает - push_back(), setFromTriplets() и solve(). Все не мои, и никак от меня не зависят. Максимум могу push_back() в восемь разных потоков разогнать, а остальное на совести авторов библиотеки. Тоже открытый вопрос - можно ли полностью параллельное заполнение организовать.

[румата]

Сообщение от Нубий-IV Тоже открытый вопрос - можно ли полностью параллельное заполнение организовать.

Из-под .net точно можно, а на ++ я вообще не умею праллелить.

[nickname2019]

Сообщение от Нубий-IV В первой функции формулы взяты из книги Метод конечных элементов в проектировании транспортных сооружений.А.С. Городецкий, В.И. Зоворицкий, А.И. Лантух-Лященко, А.О. Рассказов. 1981 г..

Годная книга. На ее основе уже можно линейный процессор написать.
Я раньше пользовался книгой Хечумов Р.А., Кепплер Х., Прокопьев В.И. "Применение метода конечных элементов к расчету строительных конструкций". Более современная книжка "обо всем" в МКЭ, но с опечатками. Найти ее в свободном доступе не могу. Покупать пока не будем, может быть и так справимся.

Сообщение от Нубий-IV Как вводить шарниры

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

Сообщение от Нубий-IV Как сделать переменный модуль упругости по всем узлам? Какой вектор узловых усилий под неравномерной нагрузкой на части площади КЭ?

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

Сообщение от Нубий-IV Какая матрица масс или геометрических параметров у анизотропной плиты?

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

Сообщение от Нубий-IV А у гибридного элемента? И т.д. и т.п.

Может быть ограничиться оболочечными КЭ (в общем случае анизотропными) и стержневыми?

Сообщение от Нубий-IV Я имел ввиду связи, забытые пользователем. У Лироскадов есть фишка - обнаруженную в процессе счета изменяемость любезно закреплять автоматической связью, и продолжать расчет. Вот у Старка такой фишки нет - он до первой ошибки считает. И, если таких ошибок полсотни в проекте, придется полсотни раз расчет заново запускать, чтобы их по одному узлу отлавливать.

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

[RomanM]

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

Не на переаллокацию ли памяти в vector-е всё время сборки матрицы уходит?
Если зарезервировать заранее память (хотя бы приблизительно) перед push_back-ами, должно ускориться.
Дальше возникает вопрос, как бы вообще от ненужного промежуточного vector-а уйти?

...
поэкспериментировал с Вашим кодом, мысли такие.
Во-первых, в релизе соотношение таймингов получается другое - ещё хуже для этапа формирования матрицы. Правда, в абсолютных значениях всё куда быстрее debug.
Далее, думаю, что заполнение SparseMatrix надо анализировать отдельно от заполнения вектора и предыдущих манипуляций.
Там основное время в Вашем коде уходит на арифметику в теле цикла и перевыделение памяти при заполнении вектора. Если это всё убрать (арифметика все равно на практике будет другая), то данный этап ускорится чуть ли не на порядок. Но это просто к слову.
Заполнение SparseMatrix тоже не быстрое. Видимо, основное время уходит на сортировку вставляемых данных.
Можно, кстати, вставлять данные и поштучно непосредственно в SparseMatrix (без промежуточного вектора) через insert,
но, видимо, затраты на пересортировку после каждой вставки могут быть о-очень большие. Так что вариант с передачей сразу всех данных кажется предпочтительным. Хотя, в данной конкретной задаче, если предварительно зарезервировать память в SparseMatrix и выкинуть вектор, затраты времени на эти два этапа у меня сократились на ~40%.

Код:

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

#include <iostream>
#include <ctime>

#include <stdio.h>
#include <tchar.h>
#include <math.h>

#include <Eigen/Dense>
#include <Eigen/Sparse>

int main() {
	int MatrixSize = 716229;
	int BandWidth = 333;

	std::cout << "vector initialization...\n";
	unsigned start_time = std::clock();
	std::vector<Eigen::Triplet<double>> T;
	T.reserve(MatrixSize*BandWidth);
	for (int i = 0; i < MatrixSize; i++) {
		int bandMinIndex = i;
		int bandMaxIndex = std::min(i + BandWidth, MatrixSize);
		for (int j = bandMinIndex; j < bandMaxIndex; j++) {
			//double distance = i - j;
			//double max_distance = BandWidth;
			//double relativeDistance = distance / max_distance;
			//T.push_back(Eigen::Triplet<double>(i, j, 1.0 - std::pow(relativeDistance, 2)));
			T.push_back(Eigen::Triplet<double>(i, j, 1.));
			//K.insert(i, j) = 1.0 - std::pow(relativeDistance, 2);
		}
	}
	std::cout << (std::clock() - start_time) / 1000.0 << " seconds\n" << "...done.\n\n";
	
	std::cout << "SparseMatrix initialization...\n";
	start_time = std::clock();
	Eigen::SparseMatrix<double> K(MatrixSize, MatrixSize);
	//K.reserve(Eigen::VectorXi::Constant(MatrixSize,BandWidth));
	K.setFromTriplets(T.begin(), T.end());
	std::cout << (std::clock() - start_time) / 1000.0 << " seconds\n" << "...done.\n\n";

	std::cout << "Forces vector calulation...\n";
	start_time = std::clock();
	Eigen::VectorXd F(MatrixSize);

	for (int i = 0; i < MatrixSize; i++)
		F[i] = (double)i / MatrixSize;

	unsigned end_time = std::clock();
	std::cout << (end_time - start_time) / 1000.0 << " seconds\n";
	std::cout << "...done.\n\n";

	std::cout << "Equation system solving...\n";
	start_time = std::clock();

	Eigen::SimplicialLDLT<Eigen::SparseMatrix<double>> solver(K);
	Eigen::VectorXd x = solver.solve(F);

	end_time = std::clock();
	std::cout << (end_time - start_time) / 1000.0 << " seconds\n";
	std::cout << "...done.\n";

	system("pause");

	//std::cout << "Solver info: " << solver.info() << std::endl;
	//std::cout << "\nStiffness:\n" << K << std::endl;
	//std::cout << "\nForces:\n" << F << std::endl;
	//std::cout << "\nDisplacements:\n" << x << std::endl;

	return 0;
}

[Бахил]

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

Можно проверить на наличие нулей на главной диагонали. И, либо выдать предупреждение, либо вставить любое число, лучше 1е10.

----- добавлено через ~2 мин. -----
Есть Холецкий на Паскале. Если интересно, могу скинуть. Правда только однопроцессорный.

[nickname2019]

Сообщение от Бахил Есть Холецкий на Паскале. Если интересно, могу скинуть. Правда только однопроцессорный.

Холецкий должен быть в eigene.

[Нубий-IV]

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

Раз заявлена нелинейность для железобетона - скорее всего придется интерполяцию жесткостей делать, вдобавок к анизотропии, иначе придется мельчить сетку. Формально это не сложно - достаточно в файле максимы добавить строку типа E=E1+(E2-E1)u + (E3-E1)v, и посмотреть ответы.

Сообщение от nickname2019 Может быть ограничиться оболочечными КЭ

Даже оболочек - и то целый выводок в любой книге. Такие полиномы - сякие полиномы - а вот кому косинусы. Помнится, в старой Лире наклонные оболочки были геометрически изменяемыми, а в новых версиях - уже нет; явно там в элементах что-то подшаманили (или в автоматических связях, кто их там разберет, закрыто-коммерческих). Даже из Зенкевича полно ссылок на конкретные элементы, в виде научных статей, за которые денег хотят.

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

В любом случае полный набор формул "для всего" вряд ли хоть в одной книге найдем; что-то придется выводить. Во вложении - пример матрицы в Максиме, и pdf с описанием процесса.

Сообщение от румата Из-под .net точно можно

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

Сообщение от Бахил Можно проверить на наличие нулей на главной диагонали.

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

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

[Бахил]

Сообщение от Нубий-IV Вложения

А это что за опус? Offtop: Предупреждать же надо.

[nickname2019]

Вот вывод МЖ прямоуголных КЭ плоской задачи и физ. нелинейного пространственного КЭ - параллелепипеда.

Это для справки по учету нелинейности в МЖ.

[румата]

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

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

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

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

Сообщение от Нубий-IV Даже оболочек - и то целый выводок в любой книге. Такие полиномы - сякие полиномы - а вот кому косинусы.

Без этого обойтись не получится. Все эти балки-стенки и исключительно прямоугольные оболочки никому не нужны. Нужны произвольные четырехугольные и треугольные КЭ оболочки. Потом четырехугольные и треугольные КЭ толстой оболочки или плиты.

[nickname2019]

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

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

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

Есть вариант вывести матрицу жесткости пространственного КЭ (см. вложение пост #334 рис. 3.5, но не прямоугольный, а произвольный), а из нее получить КЭ оболочки (единичное смещение давать не одному узлу, а сразу двум, потом получать реакции, вычислять суммарную реакцию - переводить в M,N,Q).
Может быть, это будет сложнее, а может проще, не могу пока понять.

[Нубий-IV]

Сообщение от румата Не вижу проблемы в проверке на диагональный ноль-элемент в разреженной матрице.

А она есть .

Элемент фермы в плоской задаче со степенями свободы x,y.

1. Заносим элемент в матрицу жесткости. Поскольку по оси y реакций элемент не передает, вторая и последняя строки (суммы сил на вертикаль в 1 и 2 узле) - полностью нулевые.
2. Удаляем строки с нулями на диагонали (так делают Лира и Скад, но не делает Старк). Это, фактически, значит "Ставим автоматические связи".
3. Начинаем расчет. Исключаем из второй строки первый элемент: добавляем в нее первую строку.
4. Опа! Нарисовался! Ноль на диагонали. До начала расчета его там не было. Тут Лира и Скад ставят на диагональ ненулевое значение ("Автоматическая связь в процессе расчета"), а Старк падает в обморок. У Eigen к этому месту нет доступа - solve() вернет ошибку, и абсолютно левые перемещения.

Сообщение от румата Все эти балки-стенки и исключительно прямоугольные оболочки никому не нужны.

Как минимум они нужны авторам книг, чтобы показать, какие простые формулы получаются в МКЭ:

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

[nickname2019]

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

Я выводил матрицу прямоугольного пространственного анизотропного КЭ 24х24 элемента. Получилась простыня.

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

[румата]

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

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

Сообщение от Нубий-IV Элемент фермы в плоской задаче со степенями свободы x,y.

1)Вычисляется матрица жесткости элемента Kr в локальной системе координат.
2)Вычисляется матрицы преобразования матрицы жескости элемента из локальной в глобальную систему координат Tr
3)Учитываеются элементные шарниры путем вычисления матрицы L и последующего преобразования матрицы Кr = L^T*Kr*L
4)Вычисляется матрица жесткости элемента в глобальной системе координат К'r = Tr^T*Kr*Tr
5)Формируется общая матрица жесткости системы К из матриц элементов К'r по матрице индексов или иным способом суммирования.
6)Выполняется проверка матрицы К на наличие нулевых элементов на диагонали перед решением СЛАУ или обращением этой матрицы.
Где эта проблема, которая есть?

[nickname2019]

Сообщение от румата Однозначно будет быстрее. На порядки. Все матричные вычисления нужно делать численно на числах с двойной точностью. А вся эта символьная борода может быть полезной только для наглядности. 1)Вычисляется матрица жесткости элемента Kr в локальной системе координат. 2)Вычисляется матрицы преобразования матрицы жескости элемента из локальной в глобальную систему координат Tr 3)Учитываеются элементные шарниры путем вычисления матрицы L и последующего преобразования матрицы Кr = L^T*Kr*L 4)Вычисляется матрица жесткости элемента в глобальной системе координат К'r = Tr^T*Kr*Tr 5)Формируется общая матрица жесткости системы К из матриц элементов К'r по матрице индексов или иным способом суммирования. 6)Выполняется проверка матрицы К на наличие нулевых элементов на диагонали перед решением СЛАУ или обращением этой матрицы. Где эта проблема, которая есть?

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

[румата]

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

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

[nickname2019]

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

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

[Нубий-IV]

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

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

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

[Бахил]

Мгновенно-изменяемая определяется "на берегу" нулями на диагонали.
Вот вырожденную матрицу (без опорных закреплений) выявить труднее.
И, кстати, матрица без опорных закреплений не всегда вырожденная.

Сообщение от Нубий-IV все матрицы хранить надо

Они нужны и для определения внутренних усилий/напряжений. Можно хранить только ненулевые элементы.

[nickname2019]

Сообщение от Нубий-IV У меня тут неприятность образовалась в одном месте. Я неожиданно вспомнил, что нанокад - 32-битный. Получается, я сообственную свечку в собственный нанокад не смогу вставить - вот где геморрой-то будет.

Сольвер можно сделать отдельным exe, так как подключить 64-разрядную DLL к 32-разрядной системе вряд ли выйдет. Что делать с 64-разрядным акадом пока не понятно. Не понятно нужно ли создавать многопоточную задачу внутри его основного процесса.

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

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

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

Сообщение от Нубий-IV Кстати, кто в курсе - в кадовскую базу элементов можно в многопоточном режиме обращаться, или это еще одно узкое место получается?

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

[Бахил]

Сообщение от nickname2019 (см. вложение).

МКЭ там и близко не стояло. Обычный метод перемещений.
МКЭ для стержня хорошо описан в Клаф, Пензиен. Динамика сооружений.
Ну а матрицы для пластин смотрите в Зенкевиче.
https://dwg.ru/dnl/4923 и https://dwg.ru/dnl/1949

[Нубий-IV]

Еще один тест скорости, более реалистичный, с элементом балки-стенки. Программа читает входной файл in.txt и записывает выходной out.pos. Формат входного файла - аналогичный статье из поста 137. Чтобы не мучиться с ручным вводом - дальше простейший скриптовый генератор. Код генератора сохранить с расширением HTA и запускать как обычную программу. Результаты смотреть в GMSH.

Код:

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

 
#include<iostream>
#include<fstream>
#include<vector>
#include<ctime>
#include<Dense>
#include<Sparse>


namespace Timer {
	unsigned start_time;
	void Start(const char* msg)  { std::cout << msg; start_time = std::clock(); }
	void Stop()  { std::cout << (std::clock() - start_time) / 1000.0 << " seconds\n"; }
}


struct Material {
	double mu;
	double E;
};


struct Section {
	double h;
};


struct Node {
	double x;
	double y;
	double z;
};


struct Element{
	int materialId;
	int sectionId;
	int nodesIds[3];
};


struct Constraint {
	int nodeId;
	int direction;
};


struct Load {
	int nodeId;
	int direction;
	double value;
};


typedef std::vector<Material> Materials;
typedef std::vector<Section> Sections;
typedef std::vector<Node> Nodes;
typedef std::vector<Element> Elements;
typedef std::vector<Constraint> Constraints;
typedef std::vector<Load> Loads;

typedef Eigen::Matrix<double, 6, 9> ElementMatrixT;
typedef Eigen::Matrix<double, 6, 6> ElementLocalMatrixK;
typedef Eigen::Matrix<double, 9, 9> ElementGlobalMatrixK;

typedef std::vector<ElementMatrixT *> ElementMatricesT;
typedef std::vector<ElementLocalMatrixK *> ElementLocalMatricesK;
typedef std::vector<ElementGlobalMatrixK *> ElementGlobalMatricesK;

typedef Eigen::SparseMatrix<double> SystemMatrixK;
typedef Eigen::VectorXd LoadsVector;
typedef Eigen::VectorXd Variables;

typedef Eigen::SimplicialLDLT<Eigen::SparseMatrix<double>> Solver;


void ReadMaterials(std::ifstream& infile, Materials& materials)
{
	int nMaterials;
	infile >> nMaterials;
	materials.resize(nMaterials);
	for(int i =0; i < nMaterials; i++)
		infile >> materials[i].mu >> materials[i].E;
}


void ReadSections(std::ifstream& infile, Sections& sections)
{
	int nSections;
	infile >> nSections;
	sections.resize(nSections);
	for(int i =0; i < nSections; i++)
		infile >> sections[i].h;
}


void ReadNodes(std::ifstream& infile, Nodes& nodes)
{
	int nNodes;
	infile >> nNodes;
	nodes.resize(nNodes);
	for(int i = 0; i < nNodes; i++)
		infile >> nodes[i].x >> nodes[i].y >> nodes[i].z;

}


void ReadElements(std::ifstream& infile, Elements& elements)
{
	int nElements;
	infile >> nElements;
	elements.resize(nElements);
	for(int i = 0; i < nElements; i++)
		infile >> elements[i].materialId >> elements[i].sectionId >> elements[i].nodesIds[0] >> elements[i].nodesIds[1] >> elements[i].nodesIds[2];
}


void ReadConstraints(std::ifstream& infile, Constraints& constraints)
{
	int nConstraints;
	infile >> nConstraints;
	constraints.resize(nConstraints);
	for(int i = 0; i < nConstraints; i++)
		infile >> constraints[i].nodeId >> constraints[i].direction;
}


void ReadLoads(std::ifstream& infile, Loads& loads)
{
	int nLoads;
	infile >> nLoads;
	loads.resize(nLoads);
	for(int i = 0; i < nLoads; i++)
		infile >> loads[i].nodeId >> loads[i].direction >> loads[i].value;
}


void CalcElementMatrixT(const Element& element, const Nodes& nodes, ElementMatrixT& t)
{
	Eigen::Vector3d x;
	x[0] = nodes[element.nodesIds[1]].x - nodes[element.nodesIds[0]].x;
	x[1] = nodes[element.nodesIds[1]].y - nodes[element.nodesIds[0]].y;
	x[2] = nodes[element.nodesIds[1]].z - nodes[element.nodesIds[0]].z;

	Eigen::Vector3d v;
	v[0] = nodes[element.nodesIds[2]].x - nodes[element.nodesIds[0]].x;
	v[1] = nodes[element.nodesIds[2]].y - nodes[element.nodesIds[0]].y;
	v[2] = nodes[element.nodesIds[2]].z - nodes[element.nodesIds[0]].z;

	Eigen::Vector3d z = x.cross(v);
	Eigen::Vector3d y = z.cross(x);

	x.normalize();
	y.normalize();

	t(0,0) = x[0]; t(0,1) = x[1]; t(0,2) = x[2]; t(0,3) = 0;    t(0,4) =  0;   t(0,5) = 0;    t(0,6) = 0;    t(0,7) = 0;    t(0,8) = 0;
	t(1,0) = y[0]; t(1,1) = y[1]; t(1,2) = y[2]; t(1,3) = 0;    t(1,4) =  0;   t(1,5) = 0;    t(1,6) = 0;    t(1,7) = 0;    t(1,8) = 0;
	t(2,0) = 0;    t(2,1) = 0;    t(2,2) = 0;    t(2,3) = x[0]; t(2,4) = x[1]; t(2,5) = x[2]; t(2,6) = 0;    t(2,7) = 0;    t(2,8) = 0;
	t(3,0) = 0;    t(3,1) = 0;    t(3,2) = 0;    t(3,3) = y[0]; t(3,4) = y[1]; t(3,5) = y[2]; t(3,6) = 0;    t(3,7) = 0;    t(3,8) = 0;
	t(4,0) = 0;    t(4,1) = 0;    t(4,2) = 0;    t(4,3) = 0;    t(4,4) = 0;    t(4,5) = 0;    t(4,6) = x[0]; t(4,7) = x[1]; t(4,8) = x[2];
	t(5,0) = 0;    t(5,1) = 0;    t(5,2) = 0;    t(5,3) = 0;    t(5,4) = 0;    t(5,5) = 0;    t(5,6) = y[0]; t(5,7) = y[1]; t(5,8) = y[2];
}

void CalcElementMatricesT(const Elements& elements, const Nodes& nodes, ElementMatricesT& matricesT)
{
	matricesT.resize(elements.size());

	for(unsigned i = 0; i < elements.size(); i++) {
		ElementMatrixT* t = new ElementMatrixT;
		CalcElementMatrixT(elements[i], nodes, *t);
		matricesT[i] = t;
	}
}


void CalcElementLocalMatrixK(const Element& element, const Materials& materials, const Sections& sections, const Nodes& nodes, const ElementMatrixT& t, ElementLocalMatrixK& kl)
{
	Eigen::VectorXd globalCoord(9);

	globalCoord[0] = 0;
	globalCoord[1] = 0;
	globalCoord[2] = 0;

	globalCoord[3] = nodes[element.nodesIds[1]].x - nodes[element.nodesIds[0]].x;
	globalCoord[4] = nodes[element.nodesIds[1]].y - nodes[element.nodesIds[0]].y;
	globalCoord[5] = nodes[element.nodesIds[1]].z - nodes[element.nodesIds[0]].z;

	globalCoord[6] = nodes[element.nodesIds[2]].x - nodes[element.nodesIds[0]].x;
	globalCoord[7] = nodes[element.nodesIds[2]].y - nodes[element.nodesIds[0]].y;
	globalCoord[8] = nodes[element.nodesIds[2]].z - nodes[element.nodesIds[0]].z;

	Eigen::VectorXd localCoord = t * globalCoord;

	double a = localCoord[2]; // x2
	double b = localCoord[4]; // x3
	double c = localCoord[5]; // y3

	double E = materials[element.materialId].E;
	double mu = materials[element.materialId].mu;
	double h = sections[element.sectionId].h;
	double f = E * h / (1 - mu*mu);

	kl(0,0) =  f*(((2*a - b)*b - a*a)*mu + 2*c*c + b*(b - 2*a) + a*a)/(4*a*c);
	kl(0,1) =  f*((a - b)*mu - b + a)/(4*a);
	kl(0,2) =  f*(b*(b - a)*mu - 2*c*c + (a - b)*b)/(4*a*c);
	kl(0,3) =  f*((b + a)*mu + b - a)/(4*a);
	kl(0,4) =  f*((a - b)*mu + b - a)/(4*c);
	kl(0,5) =  - f*mu/2;

	kl(1,0) =  kl(0,1);
	kl(1,1) =  f*( - c*c*mu + c*c + b*(2*b - 4*a) + 2*a*a)/(4*a*c);
	kl(1,2) =  f*((b - 2*a)*mu + b)/(4*a);
	kl(1,3) =  f*(c*c*mu - c*c + (2*a - 2*b)*b)/(4*a*c);
	kl(1,4) =  f*(mu - 1)/4;
	kl(1,5) =  f*(b - a)/(2*c);

	kl(2,0) =  kl(0,2);
	kl(2,1) =  kl(1,2);
	kl(2,2) =  f*( - b*b*mu + 2*c*c + b*b)/(4*a*c);
	kl(2,3) =  f*( - b*mu - b)/(4*a);
	kl(2,4) =  f*(b*mu - b)/(4*c);
	kl(2,5) =  f*mu/2;

	kl(3,0) =  kl(0,3);
	kl(3,1) =  kl(1,3);
	kl(3,2) =  kl(2,3);
	kl(3,3) =  f*( - c*c*mu + c*c + 2*b*b)/(4*a*c);
	kl(3,4) =  f*(1 - mu)/4;
	kl(3,5) =  - f*b/(2*c);

	kl(4,0) =  kl(0,4);
	kl(4,1) =  kl(1,4);
	kl(4,2) =  kl(2,4);
	kl(4,3) =  kl(3,4);
	kl(4,4) =  f*(a - a*mu)/(4*c);
	kl(4,5) =  0;

	kl(5,0) =  kl(0,5);
	kl(5,1) =  kl(1,5);
	kl(5,2) =  kl(2,5);
	kl(5,3) =  kl(3,5);
	kl(5,4) =  kl(4,5);
	kl(5,5) =  f*a/(2*c);
}

void CalcElementLocalMatricesK(const Elements& elements, const Materials& materials, const Sections& sections, const Nodes& nodes, 
			       const ElementMatricesT& elementMatricesT, ElementLocalMatricesK& elementLocalMatricesK)
{
	elementLocalMatricesK.resize(elements.size());

	for(unsigned i = 0; i < elements.size(); i++) {
		ElementLocalMatrixK* kl = new ElementLocalMatrixK;
		CalcElementLocalMatrixK(elements[i], materials, sections, nodes, *elementMatricesT[i], *kl);
		elementLocalMatricesK[i] = kl;
	}
	
}


void CalcElementGlobalMatrixK(const ElementLocalMatrixK& kl, const ElementMatrixT& t, ElementGlobalMatrixK& kg)
{
	kg = t.transpose() * kl * t;
}

void CalcElementGlobalMatricesK(const ElementMatricesT& elementMatricesT, const ElementLocalMatricesK& elementLocalMatricesK, ElementGlobalMatricesK& elementGlobalMatricesK)
{
	elementGlobalMatricesK.resize(elementLocalMatricesK.size());

	for(unsigned i = 0; i < elementLocalMatricesK.size(); i++) {
		ElementGlobalMatrixK* elementGlobalMatrixK = new ElementGlobalMatrixK;
		CalcElementGlobalMatrixK(*elementLocalMatricesK[i], *elementMatricesT[i], *elementGlobalMatrixK);
		elementGlobalMatricesK[i] = elementGlobalMatrixK;
	}
}


void PlaceElementMatrixK(const Element& element, const ElementGlobalMatrixK& k, SystemMatrixK& K)
{
	for(int i = 0; i < k.rows(); i++) {
		int iNodeId = i / 3;
		int iDirectionId = i % 3;
		for(int j = 0; j < k.cols(); j++) {
			int jNodeId = j / 3;
			int jDirectionId = j % 3;
			int m = 6 * element.nodesIds[iNodeId] + iDirectionId;
			int n = 6 * element.nodesIds[jNodeId] + jDirectionId;
			K.coeffRef(m,n) += k(i,j);
		}
	}
}


void CalcSystemMatrixK(const Elements& elements, const ElementGlobalMatricesK&  elementGlobalMatricesK, SystemMatrixK& K)
{
	for(unsigned i = 0; i < elements.size(); i++) {
		PlaceElementMatrixK(elements[i], *elementGlobalMatricesK[i], K);
	}
}


void SetConstraint(const Constraint constraint, SystemMatrixK& K)
{
	K.coeffRef(6 * constraint.nodeId + constraint.direction,6 * constraint.nodeId + constraint.direction) = 1e10;
}


void CalcConstraints(const Constraints& constraints, SystemMatrixK& K)
{
	for(unsigned i = 0; i < constraints.size(); i++)
		SetConstraint(constraints[i], K);
}


void SetLoad(const Load load, LoadsVector& L)
{
	L.coeffRef(6 * load.nodeId + load.direction) = load.value;
}


void CalcLoads(const Loads& loads, LoadsVector& L)
{
	L.setZero();
	for(unsigned i = 0; i < loads.size(); i++)
		SetLoad(loads[i], L);
}


void WriteU(std::ofstream& outfile, const Nodes& nodes, const Elements& elements, const Variables& U)
{
	outfile << "View \"Ux\"{\n";
	for(unsigned i = 0; i < elements.size(); i++)
		outfile << "ST(" <<
			nodes[elements[i].nodesIds[0]].x << ',' << nodes[elements[i].nodesIds[0]].y << ',' << nodes[elements[i].nodesIds[0]].z << ',' <<
			nodes[elements[i].nodesIds[1]].x << ',' << nodes[elements[i].nodesIds[1]].y << ',' << nodes[elements[i].nodesIds[1]].z << ',' <<
			nodes[elements[i].nodesIds[2]].x << ',' << nodes[elements[i].nodesIds[2]].y << ',' << nodes[elements[i].nodesIds[2]].z << "){" <<
			U[6*elements[i].nodesIds[0]] << "," << U[6*elements[i].nodesIds[1]] << "," << U[6*elements[i].nodesIds[2]] << "};\n";
	outfile << "};\n";

	outfile << "View \"Uy\"{\n";
	for(unsigned i = 0; i < elements.size(); i++)
		outfile << "ST(" <<
			nodes[elements[i].nodesIds[0]].x << ',' << nodes[elements[i].nodesIds[0]].y << ',' << nodes[elements[i].nodesIds[0]].z << ',' <<
			nodes[elements[i].nodesIds[1]].x << ',' << nodes[elements[i].nodesIds[1]].y << ',' << nodes[elements[i].nodesIds[1]].z << ',' <<
			nodes[elements[i].nodesIds[2]].x << ',' << nodes[elements[i].nodesIds[2]].y << ',' << nodes[elements[i].nodesIds[2]].z << "){" <<
			U[6*elements[i].nodesIds[0]+1] << "," << U[6*elements[i].nodesIds[1]+1] << "," << U[6*elements[i].nodesIds[2]+1] << "};\n";
	outfile << "};\n";

	outfile << "View \"Uz\"{\n";
	for(unsigned i = 0; i < elements.size(); i++)
		outfile << "ST(" <<
			nodes[elements[i].nodesIds[0]].x << ',' << nodes[elements[i].nodesIds[0]].y << ',' << nodes[elements[i].nodesIds[0]].z << ',' <<
			nodes[elements[i].nodesIds[1]].x << ',' << nodes[elements[i].nodesIds[1]].y << ',' << nodes[elements[i].nodesIds[1]].z << ',' <<
			nodes[elements[i].nodesIds[2]].x << ',' << nodes[elements[i].nodesIds[2]].y << ',' << nodes[elements[i].nodesIds[2]].z << "){" <<
			U[6*elements[i].nodesIds[0]+2] << "," << U[6*elements[i].nodesIds[1]+2] << "," << U[6*elements[i].nodesIds[2]+2] << "};\n";
	outfile << "};\n";
}


int main(int argc, char* argv[])
{
	std::ifstream infile("in.txt");
	std::ofstream outfile("out.pos");

	Timer::Start("Read data...");
		Materials materials;
		ReadMaterials(infile, materials);

		Sections sections;
		ReadSections(infile, sections);

		Nodes nodes;
		ReadNodes(infile, nodes);

		Elements elements;
		ReadElements(infile, elements);

		Constraints constraints;
		ReadConstraints(infile, constraints);

		Loads loads;
		ReadLoads(infile, loads);
	Timer::Stop();

	Timer::Start("Element transformation matrices calculation...");
		ElementMatricesT elementMatricesT;
		CalcElementMatricesT(elements, nodes, elementMatricesT);
	Timer::Stop();

	Timer::Start("Element local stiffness matrices calculation...");
		ElementLocalMatricesK elementLocalMatricesK;
		CalcElementLocalMatricesK(elements, materials, sections, nodes, elementMatricesT, elementLocalMatricesK);
	Timer::Stop();

	Timer::Start("Element global stiffness matrices calculation...");
		ElementGlobalMatricesK elementGlobalMatricesK;
		CalcElementGlobalMatricesK(elementMatricesT, elementLocalMatricesK, elementGlobalMatricesK);
	Timer::Stop();

	Timer::Start("System siffnes matrix calulation...");
		int nVars = 6 * nodes.size();
		SystemMatrixK K(nVars, nVars);
		CalcSystemMatrixK(elements, elementGlobalMatricesK, K);
	Timer::Stop();

	Timer::Start("Constraints calulation...");
		CalcConstraints(constraints, K);
	Timer::Stop();

	Timer::Start("Loads calulation...");
		LoadsVector L(nVars);
		CalcLoads(loads, L);
	Timer::Stop();

	Timer::Start("Equations system solving...");
		Solver solver(K);
		Variables U = solver.solve(L);
	Timer::Stop();

	Timer::Start("Results writting...");
		WriteU(outfile, nodes, elements, U);
	Timer::Stop();
}

Код:

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

<h1>Генератор исходных данных</h1>
<p>Ширина балки-стенки <input name="i_b"  value="1"> м</p>
<p>Высота балки-стенки <input name="i_h"  value="1"> м</p>
<p>Число элементов по ширине <input name="i_nb" value="1"></p>
<p>Число элементов по высоте <input name="i_nh" value="1"></p>
<p>Модуль упругости <input name="i_E"  value="3e7"> Кпа</p>
<p>Коэффициент Пуассона <input name="i_mu" value="0.2"></p>
<p>Толщина балки-стенки <input name="i_t"  value="0.5"> м</p>
<p>Распределенная нагрузка по верху балки-стенки <input name="i_q"  value="100"> Кн/м</p>
<input type="button" value="Генерировать" onclick="Generate()">

<script>

function Generate()
{
	fso = new ActiveXObject("Scripting.FileSystemObject")
	var file = fso.OpenTextFile("In.txt", 2, true)

	b  = parseFloat(i_b.value)
	nb = parseFloat(i_nb.value)
	h  = parseFloat(i_h.value)
	nh = parseFloat(i_nh.value)
	E  = parseFloat(i_E.value)
	mu = parseFloat(i_mu.value)
	t  = parseFloat(i_t.value)
	q  = parseFloat(i_q.value)

	// Материалы
	file.Write("1\n" + mu + " " + E + "\n")
	
	// Сечения
	file.Write("1\n" + t + "\n")
	
	// Узлы
	nNodes = (nb + 1) * (nh + 1)
	file.Write("" + nNodes + "\n")
	sizeX = b/nb
	sizeY = h/nh
	for(j = 0; j <= nh; j++)
		for(i = 0; i <= nb; i++) {
			x = i * sizeX
			y = j * sizeY
			z = 0
			file.Write("" + x + " " + y + " " + z + "\n")
		}

	// Элементы
	nElements = 2 * nb * nh
	file.Write("" + nElements + "\n")
	for(j = 0; j < nh; j++)
		for(i = 0; i < nb; i++) {
			node0 = i + (nb + 1) * j
			node1 = i + (nb + 1) * j + 1
			node2 = i + (nb + 1) * (j + 1)
			file.Write("0 0 " + node0 + " " + node1 + " " + node2 + "\n")

			node0 = i + (nb + 1) * (j + 1)
			node1 = i + (nb + 1) * j + 1
			node2 = i + (nb + 1) * (j + 1) + 1
			file.Write("0 0 " + node0 + " " + node1 + " " + node2 + "\n")
		}

	// Связи
	nConstraints = 6 + 5 * nb + 4 * (nb + 1) * nh
	file.Write("" + nConstraints + "\n")
	file.Write("0 0\n0 1\n0 2\n0 3\n0 4\n0 5\n")
	for(i = 1; i <= nb; i++) {
		file.Write("" + i + " 1\n")
		file.Write("" + i + " 2\n")
		file.Write("" + i + " 3\n")
		file.Write("" + i + " 4\n")
		file.Write("" + i + " 5\n")
	}

	for(i = nb + 1; i < (nb + 1) * (nh + 1); i++) {
		file.Write("" + i + " 2\n")
		file.Write("" + i + " 3\n")
		file.Write("" + i + " 4\n")
		file.Write("" + i + " 5\n")
	}

	// Нагрузки
	nLoads = nb + 1
	file.Write("" + nLoads + "\n")

	f1 = q * sizeX
	f2 = q * sizeX / 2
	
	node = (nb + 1) * nh
	file.Write("" + node + " 1 " + f2 + "\n")

	for(i = (nb + 1) * nh + 1; i < (nb + 1) * (nh + 1) - 1; i++)
		file.Write("" + i + " 1 " + f1 + "\n")	

	node = (nb + 1) * (nh + 1) - 1
	file.Write("" + node + " 1 " + f2 + "\n")

	file.Close()	
}
</script>

Однако, самая прожорливая операция - вставка в матрицу системы. Даже оптимизация "нули не вставлять" разгоняет ее вдвое. Это какой-то позор.

Сообщение от nickname2019 Сольвер можно сделать отдельным exe

Кстати, так он больше похож на ОбПеньСорс. Если у него будет интерфейс для ввода данных и чтения результатов:

• В виде функций c++
• В виде функций c#
• В виде функций Python
• В виде текстового языка
• В виде двоичного формата

То поучаствовать смогут те, кто заходил в тему, и советовал выше это все.

[румата]

Сообщение от Нубий-IV А у гибридного элемента?

Нашел у себя вот такое


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

Сообщение от Нубий-IV Формат входного файла - аналогичный статье из поста 137.

Думается стОит принять XML-формат для файла входных данных по причине возможности его валидации XML -схемой.

[Нубий-IV]

Однако, гугл помогл. Оказывается, у разреженной матрицы есть метод reserve(), в который можно передать профиль матрицы - вектор, у которого для каждого столбца указано, сколько ненулевых элементов в столбце будет. Тогда память выделится только один раз. Я в запас просуммировал количество всех элементов на этапе сборки глобальных матриц элементов, не учитывая наложений. Где без резервирования было 12с - с резервированием стало 0.016с; ускорение в 750 раз.

Код:

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

 
#include<iostream>
#include<fstream>
#include<vector>
#include<ctime>
#include<Dense>
#include<Sparse>


namespace Timer {
	unsigned start_time;
	void Start(const char* msg)  { std::cout << msg; start_time = std::clock(); }
	void Stop()  { std::cout << (std::clock() - start_time) / 1000.0 << " seconds\n"; }
}


struct Material {
	double mu;
	double E;
};


struct Section {
	double h;
};


struct Node {
	double x;
	double y;
	double z;
};


struct Element{
	int materialId;
	int sectionId;
	int nodesIds[3];
};


struct Constraint {
	int nodeId;
	int direction;
};


struct Load {
	int nodeId;
	int direction;
	double value;
};


typedef std::vector<Material> Materials;
typedef std::vector<Section> Sections;
typedef std::vector<Node> Nodes;
typedef std::vector<Element> Elements;
typedef std::vector<Constraint> Constraints;
typedef std::vector<Load> Loads;

typedef Eigen::Matrix<double, 6, 9> ElementMatrixT;
typedef Eigen::Matrix<double, 6, 6> ElementLocalMatrixK;
typedef Eigen::Matrix<double, 9, 9> ElementGlobalMatrixK;

typedef std::vector<ElementMatrixT *> ElementMatricesT;
typedef std::vector<ElementLocalMatrixK *> ElementLocalMatricesK;
typedef std::vector<ElementGlobalMatrixK *> ElementGlobalMatricesK;

typedef Eigen::VectorXi SystemMatrixProfile;
typedef Eigen::SparseMatrix<double> SystemMatrixK;
typedef Eigen::VectorXd LoadsVector;
typedef Eigen::VectorXd Variables;

typedef Eigen::SimplicialLDLT<Eigen::SparseMatrix<double>> Solver;


void ReadMaterials(std::ifstream& infile, Materials& materials)
{
	int nMaterials;
	infile >> nMaterials;
	materials.resize(nMaterials);
	for(int i =0; i < nMaterials; i++)
		infile >> materials[i].mu >> materials[i].E;
}


void ReadSections(std::ifstream& infile, Sections& sections)
{
	int nSections;
	infile >> nSections;
	sections.resize(nSections);
	for(int i =0; i < nSections; i++)
		infile >> sections[i].h;
}


void ReadNodes(std::ifstream& infile, Nodes& nodes)
{
	int nNodes;
	infile >> nNodes;
	nodes.resize(nNodes);
	for(int i = 0; i < nNodes; i++)
		infile >> nodes[i].x >> nodes[i].y >> nodes[i].z;

}


void ReadElements(std::ifstream& infile, Elements& elements)
{
	int nElements;
	infile >> nElements;
	elements.resize(nElements);
	for(int i = 0; i < nElements; i++)
		infile >> elements[i].materialId >> elements[i].sectionId >> elements[i].nodesIds[0] >> elements[i].nodesIds[1] >> elements[i].nodesIds[2];
}


void ReadConstraints(std::ifstream& infile, Constraints& constraints)
{
	int nConstraints;
	infile >> nConstraints;
	constraints.resize(nConstraints);
	for(int i = 0; i < nConstraints; i++)
		infile >> constraints[i].nodeId >> constraints[i].direction;
}


void ReadLoads(std::ifstream& infile, Loads& loads)
{
	int nLoads;
	infile >> nLoads;
	loads.resize(nLoads);
	for(int i = 0; i < nLoads; i++)
		infile >> loads[i].nodeId >> loads[i].direction >> loads[i].value;
}


void CalcElementMatrixT(const Element& element, const Nodes& nodes, ElementMatrixT& t)
{
	Eigen::Vector3d x;
	x[0] = nodes[element.nodesIds[1]].x - nodes[element.nodesIds[0]].x;
	x[1] = nodes[element.nodesIds[1]].y - nodes[element.nodesIds[0]].y;
	x[2] = nodes[element.nodesIds[1]].z - nodes[element.nodesIds[0]].z;

	Eigen::Vector3d v;
	v[0] = nodes[element.nodesIds[2]].x - nodes[element.nodesIds[0]].x;
	v[1] = nodes[element.nodesIds[2]].y - nodes[element.nodesIds[0]].y;
	v[2] = nodes[element.nodesIds[2]].z - nodes[element.nodesIds[0]].z;

	Eigen::Vector3d z = x.cross(v);
	Eigen::Vector3d y = z.cross(x);

	x.normalize();
	y.normalize();

	t(0,0) = x[0]; t(0,1) = x[1]; t(0,2) = x[2]; t(0,3) = 0;    t(0,4) =  0;   t(0,5) = 0;    t(0,6) = 0;    t(0,7) = 0;    t(0,8) = 0;
	t(1,0) = y[0]; t(1,1) = y[1]; t(1,2) = y[2]; t(1,3) = 0;    t(1,4) =  0;   t(1,5) = 0;    t(1,6) = 0;    t(1,7) = 0;    t(1,8) = 0;
	t(2,0) = 0;    t(2,1) = 0;    t(2,2) = 0;    t(2,3) = x[0]; t(2,4) = x[1]; t(2,5) = x[2]; t(2,6) = 0;    t(2,7) = 0;    t(2,8) = 0;
	t(3,0) = 0;    t(3,1) = 0;    t(3,2) = 0;    t(3,3) = y[0]; t(3,4) = y[1]; t(3,5) = y[2]; t(3,6) = 0;    t(3,7) = 0;    t(3,8) = 0;
	t(4,0) = 0;    t(4,1) = 0;    t(4,2) = 0;    t(4,3) = 0;    t(4,4) = 0;    t(4,5) = 0;    t(4,6) = x[0]; t(4,7) = x[1]; t(4,8) = x[2];
	t(5,0) = 0;    t(5,1) = 0;    t(5,2) = 0;    t(5,3) = 0;    t(5,4) = 0;    t(5,5) = 0;    t(5,6) = y[0]; t(5,7) = y[1]; t(5,8) = y[2];
}


void CalcElementMatricesT(const Elements& elements, const Nodes& nodes, ElementMatricesT& matricesT)
{
	matricesT.resize(elements.size());

	for(unsigned i = 0; i < elements.size(); i++) {
		ElementMatrixT* t = new ElementMatrixT;
		CalcElementMatrixT(elements[i], nodes, *t);
		matricesT[i] = t;
	}
}


void CalcElementLocalMatrixK(const Element& element, const Materials& materials, const Sections& sections, const Nodes& nodes, const ElementMatrixT& t, ElementLocalMatrixK& kl)
{
	Eigen::VectorXd globalCoord(9);

	globalCoord[0] = 0;
	globalCoord[1] = 0;
	globalCoord[2] = 0;

	globalCoord[3] = nodes[element.nodesIds[1]].x - nodes[element.nodesIds[0]].x;
	globalCoord[4] = nodes[element.nodesIds[1]].y - nodes[element.nodesIds[0]].y;
	globalCoord[5] = nodes[element.nodesIds[1]].z - nodes[element.nodesIds[0]].z;

	globalCoord[6] = nodes[element.nodesIds[2]].x - nodes[element.nodesIds[0]].x;
	globalCoord[7] = nodes[element.nodesIds[2]].y - nodes[element.nodesIds[0]].y;
	globalCoord[8] = nodes[element.nodesIds[2]].z - nodes[element.nodesIds[0]].z;

	Eigen::VectorXd localCoord = t * globalCoord;

	double a = localCoord[2]; // x2
	double b = localCoord[4]; // x3
	double c = localCoord[5]; // y3

	double E = materials[element.materialId].E;
	double mu = materials[element.materialId].mu;
	double h = sections[element.sectionId].h;
	double f = E * h / (1 - mu*mu);

	kl(0,0) =  f*(((2*a - b)*b - a*a)*mu + 2*c*c + b*(b - 2*a) + a*a)/(4*a*c);
	kl(0,1) =  f*((a - b)*mu - b + a)/(4*a);
	kl(0,2) =  f*(b*(b - a)*mu - 2*c*c + (a - b)*b)/(4*a*c);
	kl(0,3) =  f*((b + a)*mu + b - a)/(4*a);
	kl(0,4) =  f*((a - b)*mu + b - a)/(4*c);
	kl(0,5) =  - f*mu/2;

	kl(1,0) =  kl(0,1);
	kl(1,1) =  f*( - c*c*mu + c*c + b*(2*b - 4*a) + 2*a*a)/(4*a*c);
	kl(1,2) =  f*((b - 2*a)*mu + b)/(4*a);
	kl(1,3) =  f*(c*c*mu - c*c + (2*a - 2*b)*b)/(4*a*c);
	kl(1,4) =  f*(mu - 1)/4;
	kl(1,5) =  f*(b - a)/(2*c);

	kl(2,0) =  kl(0,2);
	kl(2,1) =  kl(1,2);
	kl(2,2) =  f*( - b*b*mu + 2*c*c + b*b)/(4*a*c);
	kl(2,3) =  f*( - b*mu - b)/(4*a);
	kl(2,4) =  f*(b*mu - b)/(4*c);
	kl(2,5) =  f*mu/2;

	kl(3,0) =  kl(0,3);
	kl(3,1) =  kl(1,3);
	kl(3,2) =  kl(2,3);
	kl(3,3) =  f*( - c*c*mu + c*c + 2*b*b)/(4*a*c);
	kl(3,4) =  f*(1 - mu)/4;
	kl(3,5) =  - f*b/(2*c);

	kl(4,0) =  kl(0,4);
	kl(4,1) =  kl(1,4);
	kl(4,2) =  kl(2,4);
	kl(4,3) =  kl(3,4);
	kl(4,4) =  f*(a - a*mu)/(4*c);
	kl(4,5) =  0;

	kl(5,0) =  kl(0,5);
	kl(5,1) =  kl(1,5);
	kl(5,2) =  kl(2,5);
	kl(5,3) =  kl(3,5);
	kl(5,4) =  kl(4,5);
	kl(5,5) =  f*a/(2*c);
}


void CalcElementLocalMatricesK(const Elements& elements, const Materials& materials, const Sections& sections, const Nodes& nodes, 
			       const ElementMatricesT& elementMatricesT, ElementLocalMatricesK& elementLocalMatricesK)
{
	elementLocalMatricesK.resize(elements.size());

	for(unsigned i = 0; i < elements.size(); i++) {
		ElementLocalMatrixK* kl = new ElementLocalMatrixK;
		CalcElementLocalMatrixK(elements[i], materials, sections, nodes, *elementMatricesT[i], *kl);
		elementLocalMatricesK[i] = kl;
	}
	
}


void CalcElementGlobalMatrixK(const ElementLocalMatrixK& kl, const ElementMatrixT& t, ElementGlobalMatrixK& kg)
{
	kg = t.transpose() * kl * t;
}


void CalcElementGlobalMatricesK(const Elements& elements, const ElementMatricesT& elementMatricesT, const ElementLocalMatricesK& elementLocalMatricesK, ElementGlobalMatricesK& elementGlobalMatricesK, SystemMatrixProfile& profile)
{
	elementGlobalMatricesK.resize(elementLocalMatricesK.size());

	for(unsigned i = 0; i < elementLocalMatricesK.size(); i++) {
		ElementGlobalMatrixK* elementGlobalMatrixK = new ElementGlobalMatrixK;
		CalcElementGlobalMatrixK(*elementLocalMatricesK[i], *elementMatricesT[i], *elementGlobalMatrixK);
		elementGlobalMatricesK[i] = elementGlobalMatrixK;

		for(int j = 0; j < elementGlobalMatrixK->cols(); j++) {
			int jNodeId = j / 3;
			int jDirectionId = j % 3;
			int n = 6 * elements[i].nodesIds[jNodeId] + jDirectionId;
			profile[n] += elementGlobalMatrixK->rows();
		}
	}
}


void PlaceElementMatrixK(const Element& element, const ElementGlobalMatrixK& k, SystemMatrixK& K)
{
	for(int i = 0; i < k.rows(); i++) {
		int iNodeId = i / 3;
		int iDirectionId = i % 3;
		for(int j = 0; j < k.cols(); j++) {
			int jNodeId = j / 3;
			int jDirectionId = j % 3;
			int m = 6 * element.nodesIds[iNodeId] + iDirectionId;
			int n = 6 * element.nodesIds[jNodeId] + jDirectionId;
			K.coeffRef(m,n) += k(i,j);
		}
	}
}


void CalcSystemMatrixK(const Elements& elements, const ElementGlobalMatricesK&  elementGlobalMatricesK, SystemMatrixK& K)
{
	for(unsigned i = 0; i < elements.size(); i++) {
		PlaceElementMatrixK(elements[i], *elementGlobalMatricesK[i], K);
	}
}


void SetConstraint(const Constraint constraint, SystemMatrixK& K)
{
	K.coeffRef(6 * constraint.nodeId + constraint.direction,6 * constraint.nodeId + constraint.direction) = 1e10;
}


void CalcConstraints(const Constraints& constraints, SystemMatrixK& K)
{
	for(unsigned i = 0; i < constraints.size(); i++)
		SetConstraint(constraints[i], K);
}


void SetLoad(const Load load, LoadsVector& L)
{
	L.coeffRef(6 * load.nodeId + load.direction) = load.value;
}


void CalcLoads(const Loads& loads, LoadsVector& L)
{
	L.setZero();
	for(unsigned i = 0; i < loads.size(); i++)
		SetLoad(loads[i], L);
}


void WriteU(std::ofstream& outfile, const Nodes& nodes, const Elements& elements, const Variables& U)
{
	outfile << "View \"Ux\"{\n";
	for(unsigned i = 0; i < elements.size(); i++)
		outfile << "ST(" <<
			nodes[elements[i].nodesIds[0]].x << ',' << nodes[elements[i].nodesIds[0]].y << ',' << nodes[elements[i].nodesIds[0]].z << ',' <<
			nodes[elements[i].nodesIds[1]].x << ',' << nodes[elements[i].nodesIds[1]].y << ',' << nodes[elements[i].nodesIds[1]].z << ',' <<
			nodes[elements[i].nodesIds[2]].x << ',' << nodes[elements[i].nodesIds[2]].y << ',' << nodes[elements[i].nodesIds[2]].z << "){" <<
			U[6*elements[i].nodesIds[0]] << "," << U[6*elements[i].nodesIds[1]] << "," << U[6*elements[i].nodesIds[2]] << "};\n";
	outfile << "};\n";

	outfile << "View \"Uy\"{\n";
	for(unsigned i = 0; i < elements.size(); i++)
		outfile << "ST(" <<
			nodes[elements[i].nodesIds[0]].x << ',' << nodes[elements[i].nodesIds[0]].y << ',' << nodes[elements[i].nodesIds[0]].z << ',' <<
			nodes[elements[i].nodesIds[1]].x << ',' << nodes[elements[i].nodesIds[1]].y << ',' << nodes[elements[i].nodesIds[1]].z << ',' <<
			nodes[elements[i].nodesIds[2]].x << ',' << nodes[elements[i].nodesIds[2]].y << ',' << nodes[elements[i].nodesIds[2]].z << "){" <<
			U[6*elements[i].nodesIds[0]+1] << "," << U[6*elements[i].nodesIds[1]+1] << "," << U[6*elements[i].nodesIds[2]+1] << "};\n";
	outfile << "};\n";

	outfile << "View \"Uz\"{\n";
	for(unsigned i = 0; i < elements.size(); i++)
		outfile << "ST(" <<
			nodes[elements[i].nodesIds[0]].x << ',' << nodes[elements[i].nodesIds[0]].y << ',' << nodes[elements[i].nodesIds[0]].z << ',' <<
			nodes[elements[i].nodesIds[1]].x << ',' << nodes[elements[i].nodesIds[1]].y << ',' << nodes[elements[i].nodesIds[1]].z << ',' <<
			nodes[elements[i].nodesIds[2]].x << ',' << nodes[elements[i].nodesIds[2]].y << ',' << nodes[elements[i].nodesIds[2]].z << "){" <<
			U[6*elements[i].nodesIds[0]+2] << "," << U[6*elements[i].nodesIds[1]+2] << "," << U[6*elements[i].nodesIds[2]+2] << "};\n";
	outfile << "};\n";
}


int main(int argc, char* argv[])
{
	std::ifstream infile("in.txt");
	std::ofstream outfile("out.pos");

	Timer::Start("Read data...");
		Materials materials;
		ReadMaterials(infile, materials);

		Sections sections;
		ReadSections(infile, sections);

		Nodes nodes;
		ReadNodes(infile, nodes);

		Elements elements;
		ReadElements(infile, elements);

		Constraints constraints;
		ReadConstraints(infile, constraints);

		Loads loads;
		ReadLoads(infile, loads);
	Timer::Stop();

	Timer::Start("Element transformation matrices calculation...");
		ElementMatricesT elementMatricesT;
		CalcElementMatricesT(elements, nodes, elementMatricesT);
	Timer::Stop();

	Timer::Start("Element local stiffness matrices calculation...");
		ElementLocalMatricesK elementLocalMatricesK;
		CalcElementLocalMatricesK(elements, materials, sections, nodes, elementMatricesT, elementLocalMatricesK);
	Timer::Stop();

	Timer::Start("Element global stiffness matrices calculation...");
		int nVars = 6 * nodes.size();
		SystemMatrixProfile profile(nVars);
		for(int i = 0; i < nVars; i++)
			profile[i]=1;

		ElementGlobalMatricesK elementGlobalMatricesK;
		CalcElementGlobalMatricesK(elements, elementMatricesT, elementLocalMatricesK, elementGlobalMatricesK, profile);
	Timer::Stop();

	Timer::Start("System siffnes matrix calulation...");
		SystemMatrixK K(nVars, nVars);
		K.reserve(profile);
		CalcSystemMatrixK(elements, elementGlobalMatricesK, K);
	Timer::Stop();

	Timer::Start("Constraints calulation...");
		CalcConstraints(constraints, K);
	Timer::Stop();

	Timer::Start("Loads calulation...");
		LoadsVector L(nVars);
		CalcLoads(loads, L);
	Timer::Stop();

	Timer::Start("Equations system solving...");
		Solver solver(K);
		Variables U = solver.solve(L);
	Timer::Stop();

	Timer::Start("Results writting...");
		WriteU(outfile, nodes, elements, U);
	Timer::Stop();
}

А вот тест на 120000 узлов (как у свечки):

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

Сообщение от румата XML-формат для файла входных данных

Скорее уж, основным должен быть либо двоичный файл, либо програмный интерфейс. А к нему разные утилиты импорта - экспорта: хоть XML, хоть Лировский TXT, хоть HTML - страничка.

[румата]

Сообщение от Нубий-IV Скорее уж, основным должен быть либо двоичный файл, либо програмный интерфейс. А к нему разные утилиты импорта - экспорта: хоть XML, хоть Лировский TXT, хоть HTML - страничка.

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

[Нубий-IV]

Сообщение от румата Ввод данных через бинарный файл точно не нужно делать.

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

Код:

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

 
#include<iostream>
#include<fstream>
#include<ctime>
#include<windows.h>


namespace Timer {
	unsigned start_time;
	void Start(const char* msg)  { std::cout << msg << std::endl; start_time = std::clock(); }
	void Stop()  { std::cout << (std::clock() - start_time) / 1000.0 << " seconds\n\n"; }
}


struct Node {
	Node():x(1), y(2), z(3) {}
	double x;
	double y;
	double z;
};


void WriteFormatted(int nNodes, Node* nodes)
{
	std::ofstream outfile("File.txt");
	
	for(int i = 0; i < nNodes; i++)
		outfile << "Node  =  { " << nodes[i].x << " , " << nodes[i].y << " , " << nodes[i].z << " }\n";
}


void WriteBinary(int nNodes, Node* nodes)
{
	HANDLE hFile = CreateFile("File.bin", GENERIC_WRITE, 0, 0, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, 0);

	WriteFile(hFile, nodes, nNodes * sizeof(Node), 0, 0);

	CloseHandle(hFile);
}


void main()
{
	const int nNodes = 10000000;
	Node* nodes = new Node[nNodes];

	Timer::Start("WriteFormatted");
		WriteFormatted(nNodes, nodes);
	Timer::Stop();

	Timer::Start("WriteBinary");
		WriteBinary(nNodes, nodes);
	Timer::Stop();
}

При форматированном выводе получится, что сначала ARX-модуль 20с записывает данные, потом решатель 20с их читает, делает расчет за 30с (см. тест выше), 20с пишет результаты, и ARX их обратно 20с читает - получится 80с возни с файлами и 30с расчета. И, чем сложнее формат, тем больше потери на чтение-запись. А в двоичной форме - 10с обработки файлов и 30с расчета. Еще обмен данными между программами через двоичный файл подкачки поддерживается системой (CreateFileMapping). И никто не мешает наклепать сторонних конвертеров под любые форматы. Но выбирать медленный формат как основной - по мне, неудачное решение.

У меня вообще, как у непрограммиста, проблема в том, что я синтаксис языка немного понимаю, а как его правильно применять - не очень. Даже простейший вопрос "как организовать перебор точек Гаусса" вызывает сложности.

Код:

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

 
#include<iostream>
#include<ctime>


namespace Timer {
	unsigned start_time;
	void Start(const char* msg)  { std::cout << msg << std::endl; start_time = std::clock(); }
	void Stop()  { std::cout << (std::clock() - start_time) / 1000.0 << " seconds\n\n"; }
}


// Число повторов в цикле
const int N = 1000000000;


// Подынтегральная функция
double f(double u)
{
	return 0.5 * u;
}


// Точка Гаусса - число
// Простейшее решение. Эталон скорости
// При смене числа точек требует правки в двух местах: заголовок цикла и строка суммирования
namespace Test1 {
	void run() {
		double integral = 0;
		for(int i = 0; i < N; i++) {
			integral += 2.0 * f(0.0);
		}
		std::cout << "integral = " << integral << std::endl;
	}
}


// Точка Гаусса - число в массиве
// При нескольких точках придется использовать массивы и циклы
// При смене числа точек требует правки в двух местах: заголовок цикла и строка суммирования
namespace Test2 {
	void run() {
		const int nPoints = 1;
		double u[nPoints] = {0.0};
		double W[nPoints] = {2.0};

		double integral = 0;
		for(int i = 0; i < N; i++) {
			for(int n = 0; n < nPoints; n++) {
				integral += W[n] * f(u[n]);
			}
		}
		std::cout << "integral = " << integral << std::endl;
	}
}


// Точка Гаусса - статическая структура
// Группировка координат и весов в структуру
// При смене числа точек требует правки в двух местах: заголовок цикла и строка суммирования
namespace Test3 {
	struct GaussPoint {
		double u;
		double W;
	} gaussPoint = { 0.0, 2.0 };

	const int nPoints = 1;

	void run() {
		double integral = 0;
		for(int i = 0; i < N; i++) {
			for(int n = 0; n < nPoints; n++) {
				integral += gaussPoint.W * f(gaussPoint.u);
			}
		}
		std::cout << "integral = " << integral << std::endl;
	}
}


// Точка Гаусса - структура, возвращаемая функцией
// При смене числа точек требует правки в двух местах: заголовок цикла и строка суммирования
namespace Test4 {
	struct GaussPoint {
		double u;
		double W;
	};

	GaussPoint GetPoint()
	{
		GaussPoint p = {0.0, 2.0};
		return p;
	}

	const int nPoints = 1;

	void run() {
		double integral = 0;
		for(int i = 0; i < N; i++) {
			for(int n = 0; n < nPoints; n++) {
				GaussPoint p = GetPoint();
				integral += p.W * f(p.u);
			}
		}
		std::cout << "integral = " << integral << std::endl;
	}
}


// Точка Гаусса - структура, возвращаемая функцией из массива
// При нескольких точках нужны массивы точек
// При смене числа точек требует правки в двух местах: заголовок цикла и строка суммирования
namespace Test5 {
	struct GaussPoint {
		double u;
		double W;
	};

	const int nPoints = 1;

	GaussPoint GetPoint()
	{
		static GaussPoint points[nPoints] = {0.0, 2.0};
		return points[0];
	}

	void run() {
		double integral = 0;
		for(int i = 0; i < N; i++) {
			for(int n = 0; n < nPoints; n++) {
				GaussPoint p = GetPoint();
				integral += p.W * f(p.u);
			}
		}
		std::cout << "integral = " << integral << std::endl;
	}
}


// Точка Гаусса - струкура с конструктором
// При смене числа точек требует правки в двух местах: заголовок цикла и строка суммирования
namespace Test6 {
	struct GaussPoint {
		GaussPoint(double u, double W): u(u), W(W) {}
		double u;
		double W;
	};

	const int nPoints = 1;

	void run() {
		double integral = 0;
		for(int i = 0; i < N; i++) {
			for(int n = 0; n < nPoints; n++) {
				GaussPoint p(0.0, 2.0);
				integral += p.W * f(p.u);
			}
		}
		std::cout << "integral = " << integral << std::endl;
	}
}


// Точка Гаусса - класс
// Вместо структур - классы. Вместо прямого доступа к полям - функции
// При смене числа точек требует правки в двух местах: заголовок цикла и строка суммирования
namespace Test7 {
	class GaussPoint {
	public:
		GaussPoint(double u, double W): m_u(u), m_W(W) {}
		double u() { return m_u; }
		double W() { return m_W; }
	private:
		double m_u;
		double m_W;
	};

	const int nPoints = 1;

	void run() {
		double integral = 0;
		for(int i = 0; i < N; i++) {
			for(int n = 0; n < nPoints; n++) {
				GaussPoint p(0.0, 2.0);
				integral += p.W() * f(p.u());
			}
		}
		std::cout << "integral = " << integral << std::endl;
	}
}


// Точка Гаусса - класс с приватными полями + класс схемы интегрирования
// Точки защищены от случайных изменений
// При смене числа точек требует единственного исправления - строки получения схемы
namespace Test8 {
	class GaussPoint {
	public:
		GaussPoint(double u, double W): m_u(u), m_W(W) {}
		double u() { return m_u; }
		double W() { return m_W; }
	private:
		double m_u;
		double m_W;
	};

	class GaussScheme {
	public:
		int NumPoints() { return 1; }
		GaussPoint Point() { return m_gaussPoint; }
	private:
		static GaussPoint m_gaussPoint;
	};

	GaussPoint GaussScheme::m_gaussPoint = GaussPoint(0.0, 2.0); 

	void run() {
		double integral = 0;
		for(int i = 0; i < N; i++) {
			GaussScheme scheme;
			for(int n = 0; n < scheme.NumPoints(); n++) {
				GaussPoint p = scheme.Point();
				integral += p.W() * f(p.u());
			}
		}
		std::cout << "integral = " << integral << std::endl;
	}
}


// Точка Гаусса - класс в массиве + класс схемы интегрирования
// При нескольких точках нужен массив
// При смене числа точек требует единственного исправления - строки получения схемы
namespace Test9 {
	class GaussPoint {
	public:
		GaussPoint(double u, double W): m_u(u), m_W(W) {}
		double u() { return m_u; }
		double W() { return m_W; }
	private:
		double m_u;
		double m_W;
	};

	class GaussScheme {
	public:
		int NumPoints() { return 1; }
		GaussPoint Point(int n) { return m_gaussPoints[n]; }
	private:
		static GaussPoint m_gaussPoints[];
	};

	GaussPoint GaussScheme::m_gaussPoints[] = {GaussPoint(0.0, 2.0)}; 

	void run() {
		double integral = 0;
		for(int i = 0; i < N; i++) {
			GaussScheme scheme;
			for(int n = 0; n < scheme.NumPoints(); n++) {
				GaussPoint p = scheme.Point(n);
				integral += p.W() * f(p.u());
			}
		}
		std::cout << "integral = " << integral << std::endl;
	}
}


// Точка Гаусса и схема интегрирования - абстрактные классы
// При смене числа точек требует единственного исправления - строки получения схемы
// Тормозное решение.
namespace Test10 {
	namespace Gauss {
		class Point {
		public:
			Point(double u, double W): m_u(u), m_W(W) {}
			double u() { return m_u; }
			double W() { return m_W; }
		private:
			double m_u;
			double m_W;
		};

		class IScheme {
		public:
			virtual int NumPoints() = 0;
			virtual Point* GetPoint(int n) = 0;
		};

		class Scheme: public IScheme {
		public:
			virtual int NumPoints() { return 1; }
			virtual Point* GetPoint(int n) { return &points[0]; }
		private:
			static Point points[1];
		} scheme;

		Point Scheme::points[1] = { Point(0.0, 2.0) };

		IScheme* GetScheme()
		{
			return &scheme;
		}
	}

	void run() {
		double integral = 0;
		for(int i = 0; i < N; i++) {
			Gauss::IScheme* scheme = Gauss::GetScheme();
			for(int n = 0; n < scheme->NumPoints(); n++) {
				Gauss::Point* point = scheme->GetPoint(n);
				integral += point->W() * f(point->u());
			}
		}
		std::cout << "integral = " << integral << std::endl;
	}
}


// Точка Гаусса - структура. Схема интегрирования - пространство имен.
// При смене числа точек требует правки в двух местах: заголовок цикла и строка суммирования
namespace Test11 {
	namespace Gauss {
		struct Point1D {
			double u;
			double W;
		};

		namespace Line1P {
			const int Points = 1;

			Point1D Point(int n)
			{
				static Point1D points[Points] = {0.0, 2.0};
				return points[n];
			}

		}
	}

	void run() {
		double integral = 0;
		for(int i = 0; i < N; i++) {
			for(int n = 0; n < Gauss::Line1P::Points; n++) {
				Gauss::Point1D point = Gauss::Line1P::Point(n);
				integral += point.W * f(point.u);
			}
		}
		std::cout << "integral = " << integral << std::endl;
	}
}


// Точка Гаусса - структура. Схема интегрирования - безымянная структура.
// При смене числа точек требует правки в двух местах: заголовок цикла и строка суммирования
namespace Test12 {
	namespace Gauss {
		struct Point1D {
			double u;
			double W;
		};

		const struct {
			int Points;

			Point1D Point(int n) const
			{
				static Point1D points[] = {0.0, 2.0};
				return points[n];
			}
		} Line1P = {1};

	}

	void run() {
		double integral = 0;
		for(int i = 0; i < N; i++) {
			for(int n = 0; n < Gauss::Line1P.Points; n++) {
				Gauss::Point1D point = Gauss::Line1P.Point(n);
				integral += point.W * f(point.u);
			}
		}
		std::cout << "integral = " << integral << std::endl;
	}
}

// Точка Гаусса - структура. Схема интегрирования - структура.
// При смене числа точек требует единственного исправления - строки получения схемы
// Пространство имен замусорено посторонними функциями
// Тормозное решение
namespace Test13 {
	namespace Gauss {
		struct Point1D {
			double u;
			double W;
		};

		struct Scheme {
			int Points;
			Point1D (*Point)(int n);
		};

		Point1D Line1P_Point(int n)
		{
			static Point1D points[] = {0.0, 2.0};
			return points[n];
		}

		const Scheme Line1P = {1, Line1P_Point};
	}

	void run() {
		double integral = 0;
		for(int i = 0; i < N; i++) {
			Gauss::Scheme scheme = Gauss::Line1P;
			for(int n = 0; n < scheme.Points; n++) {
				Gauss::Point1D point = scheme.Point(n);
				integral += point.W * f(point.u);
			}
		}
		std::cout << "integral = " << integral << std::endl;
	}
}


// Точка Гаусса - класс. Схема интегрирования - класс.
// При смене числа точек требует единственного исправления - строки получения схемы
namespace Test14 {
	namespace Gauss {
		class Point1D {
		public:
			Point1D(double u, double Weight): m_u(u), m_Weight(Weight) {}
			double u() { return m_u; }
			double Weight() { return m_Weight; }
		private:
			double m_u;
			double m_Weight;
		};

		namespace Scheme {
			Point1D Line_1_Points[] = {
				Point1D(0.0, 2.0)
			};

			class Line1 {
			public:
				int Points() {return 1; }
				Point1D Point(int n) { return Line_1_Points[n]; }
			};

		}

	}

	void run() {
		double integral = 0;
		for(int i = 0; i < N; i++) {
			Gauss::Scheme::Line1 scheme;
			for(int n = 0; n < scheme.Points(); n++) {
				Gauss::Point1D point = scheme.Point(n);
				integral += point.Weight() * f(point.u());
			}
		}
		std::cout << "integral = " << integral << std::endl;
	}
}


// Точка Гаусса - класс. Схема интегрирования - универсальный класс с массивом точек Гаусса.
// При смене числа точек требует единственного исправления - строки получения схемы
namespace Test15 {
	namespace Gauss {
		class Point1D {
		public:
			Point1D(double u, double Weight): m_u(u), m_Weight(Weight) {}
			double u() { return m_u; }
			double Weight() { return m_Weight; }
		private:
			double m_u;
			double m_Weight;
		};

		namespace Scheme {
			Point1D Line_1_Points[] = {
				Point1D(0.0, 2.0)
			};

			Point1D* Line_Points[] = {
				&Line_1_Points[0]
			};

			class Line {
			public:
				Line(int nPoints): nPoints(nPoints), points(Line_Points[nPoints-1]) {}
				int Points() {return nPoints; }
				Point1D Point(int n) { return points[n]; }
			private:
				int nPoints;
				Point1D* points;
			};

		}

	}

	void run() {
		double integral = 0;
		for(int i = 0; i < N; i++) {
			Gauss::Scheme::Line scheme(1);
			for(int n = 0; n < scheme.Points(); n++) {
				Gauss::Point1D point = scheme.Point(n);
				integral += point.Weight() * f(point.u());
			}
		}
		std::cout << "integral = " << integral << std::endl;
	}
}


int main()
{
	Timer::Start("Test 1");
	Test1::run();
	Timer::Stop();

	Timer::Start("Test 2");
	Test2::run();
	Timer::Stop();

	Timer::Start("Test 3");
	Test3::run();
	Timer::Stop();

	Timer::Start("Test 4");
	Test4::run();
	Timer::Stop();

	Timer::Start("Test 5");
	Test5::run();
	Timer::Stop();

	Timer::Start("Test 6");
	Test6::run();
	Timer::Stop();

	Timer::Start("Test 7");
	Test7::run();
	Timer::Stop();

	Timer::Start("Test 8");
	Test8::run();
	Timer::Stop();

	Timer::Start("Test 9");
	Test9::run();
	Timer::Stop();

	Timer::Start("Test 10");
	Test10::run();
	Timer::Stop();

	Timer::Start("Test 11");
	Test11::run();
	Timer::Stop();

	Timer::Start("Test 12");
	Test12::run();
	Timer::Stop();

	Timer::Start("Test 13");
	Test13::run();
	Timer::Stop();

	Timer::Start("Test 14");
	Test14::run();
	Timer::Stop();

	Timer::Start("Test 15");
	Test15::run();
	Timer::Stop();
}

Я удивлен, что стандартные решения через указатели на функции (стиль C) и через наследование (стиль С++) - два единственных тормозных способа упаковать константы в какую-то легко используемую оболочку; а городильня с массивами и универсальными классами равна по скорости прямому указанию констант в коде. Даже интересно, сколько всего мы еще по незнанию наделаем не так как надо .

Кстати, есть вопрос. В коде GetDP для численного интегрирования прошиты координаты точек Гаусса до 20-точечных схем включительно. Кто знает, откуда они взяли формулы? В литературе только пятиточечные схемы нахожу. В коде GetDP в последних знаках погрешности видны, в стиле "5.55555555555555552" - получается, как в анекдоте, неаккуратненько .

[zamtmn]

Если записывать данные не "влоб" - разница будет минимальной.
Например прокешировав все\частично в озу, а не пологаясь полностью на ос

[Нубий-IV]

Сообщение от zamtmn прокешировав все\частично в озу, а не пологаясь полностью на ос

В тесте стандартный кешированный поток C++ на порядок проиграл по скорости системной функции записи в файл. Еще Гугель утверждает, что отображение файлов в память даже промежуточный буфер не использует; а если памяти хватает, то и собственно файл не записывается - только однократное чтение/запись в память происходит: пишет передающая программа, читает принимающая. Как понимаю, это стандартное системное кеширование из коробки, желающие могут взамен написать свое. Опять же, не разбираюсь в тонкостях, все надо тестировать.

[zamtmn]

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

Если начинать из такого долека, результат будет лет через 15-20))

[Нубий-IV]

Оказывается, гаусс-то засекречен! В книгах по интегрированию либо теория с примерами для низких степеней, либо числовые коэффициенты с 5-15 знаками, что недотягивает до точности double. Изредка попадаются честные двадцатизначные таблицы или формулы.
Книги:

• Приближенное вычисление интегралов.1967.Крылов
• Интерполяционные кубатурные формулы.1981.Мысовских
• Approximate calculation of multiple integrals.1971.Stroud
• Геометрическое моделирование.2002.Голованов

Что нашел - набрал. Для отрезков - 9 степень, для треугольников - 5, для прямоугольников - 9. Если понадобятся степени выше, можно уточнить книжные коэффициенты в максиме, численно решив нелинейную систему уравнений с начальным приближением.

Код:

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

 
#ifndef GAUSS_H
#define GAUSS_H


namespace Gauss {


class Point1D {
public:
	Point1D(double u, double Weight);
	double u()      const;
	double Weight() const;
private:
	double m_u;
	double m_Weight;
};


class Point2D {
public:
	Point2D(double u, double v, double Weight);
	double u()      const;
	double v()      const;
	double Weight() const;
private:
	double m_u;
	double m_v;
	double m_Weight;
};


class Point3D {
public:
	Point3D(double u, double v, double w, double Weight);
	double u()      const;
	double v()      const;
	double w()      const;
	double Weight() const;
private:
	double m_u;
	double m_v;
	double m_w;
	double m_Weight;
};


namespace Scheme {


class Line_1D_1P        { public: int NumPoints() const; Point1D Point(int n) const; private: static const Point1D points[]; };
class Line_3D_2P        { public: int NumPoints() const; Point1D Point(int n) const; private: static const Point1D points[]; };
class Line_5D_3P        { public: int NumPoints() const; Point1D Point(int n) const; private: static const Point1D points[]; };
class Line_7D_4P        { public: int NumPoints() const; Point1D Point(int n) const; private: static const Point1D points[]; };
class Line_9D_5P        { public: int NumPoints() const; Point1D Point(int n) const; private: static const Point1D points[]; };


class Triangle_1D_1P    { public: int NumPoints() const; Point2D Point(int n) const; private: static const Point2D points[]; };
class Triangle_2D_3P    { public: int NumPoints() const; Point2D Point(int n) const; private: static const Point2D points[]; };
class Triangle_3D_4P    { public: int NumPoints() const; Point2D Point(int n) const; private: static const Point2D points[]; };
class Triangle_4D_6P    { public: int NumPoints() const; Point2D Point(int n) const; private: static const Point2D points[]; };
class Triangle_5D_7P    { public: int NumPoints() const; Point2D Point(int n) const; private: static const Point2D points[]; };


class Quadrangle_1D_1P  { public: int NumPoints() const; Point2D Point(int n) const; private: static const Point2D points[]; };
class Quadrangle_2D_3P  { public: int NumPoints() const; Point2D Point(int n) const; private: static const Point2D points[]; };
class Quadrangle_3D_4P  { public: int NumPoints() const; Point2D Point(int n) const; private: static const Point2D points[]; };
class Quadrangle_5D_7P  { public: int NumPoints() const; Point2D Point(int n) const; private: static const Point2D points[]; };
class Quadrangle_7D_12P { public: int NumPoints() const; Point2D Point(int n) const; private: static const Point2D points[]; };
class Quadrangle_9D_17P { public: int NumPoints() const; Point2D Point(int n) const; private: static const Point2D points[]; };


} /* namespace Scheme */


} /* namespace Gauss */


#endif /* GAUSS_H */

Код:

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

 
#include "Gauss.h"


namespace Gauss {


Point1D::Point1D(double u, double Weight): m_u(u), m_Weight(Weight) {}
double Point1D::u()      const { return m_u; }
double Point1D::Weight() const { return m_Weight; }


Point2D::Point2D(double u, double v, double Weight): m_u(u), m_v(v), m_Weight(Weight) {}
double Point2D::u()      const { return m_u; }
double Point2D::v()      const { return m_v; }
double Point2D::Weight() const { return m_Weight; }


Point3D::Point3D(double u, double v, double w, double Weight): m_u(u), m_v(v), m_w(w), m_Weight(Weight) {}
double Point3D::u()      const { return m_u; }
double Point3D::v()      const { return m_v; }
double Point3D::w()      const { return m_w; }
double Point3D::Weight() const { return m_Weight; }


namespace Scheme {


int Line_1D_1P::NumPoints() const { return 1; }
int Line_3D_2P::NumPoints() const { return 2; }
int Line_5D_3P::NumPoints() const { return 3; }
int Line_7D_4P::NumPoints() const { return 4; }
int Line_9D_5P::NumPoints() const { return 5; }


Point1D Line_1D_1P::Point(int n) const { return points[n]; }
Point1D Line_3D_2P::Point(int n) const { return points[n]; }
Point1D Line_5D_3P::Point(int n) const { return points[n]; }
Point1D Line_7D_4P::Point(int n) const { return points[n]; }
Point1D Line_9D_5P::Point(int n) const { return points[n]; }


const Point1D Line_1D_1P::points[] = {
	Point1D( 0.0000000000000000e+00, 2.0000000000000000e+00),
};

const Point1D Line_3D_2P::points[] = {
	Point1D(-5.7735026918962576e-01, 1.0000000000000000e+00),
	Point1D( 5.7735026918962576e-01, 1.0000000000000000e+00),
};

const Point1D Line_5D_3P::points[] = {
	Point1D(-7.7459666924148338e-01, 5.5555555555555556e-01),
	Point1D( 0.0000000000000000e+00, 8.8888888888888889e-01),
	Point1D( 7.7459666924148338e-01, 5.5555555555555556e-01),
};

const Point1D Line_7D_4P::points[] = {
	Point1D(-8.6113631159405258e-01, 3.4785484513745386e-01),
	Point1D(-3.3998104358485626e-01, 6.5214515486254614e-01),
	Point1D( 3.3998104358485626e-01, 6.5214515486254614e-01),
	Point1D( 8.6113631159405258e-01, 3.4785484513745386e-01),
};

const Point1D Line_9D_5P::points[] = {
	Point1D(-9.0617984593866399e-01, 2.3692688505618909e-01),
	Point1D(-5.3846931010568309e-01, 4.7862867049936647e-01),
	Point1D( 0.0000000000000000e+00, 5.6888888888888889e-01),
	Point1D( 5.3846931010568309e-01, 4.7862867049936647e-01),
	Point1D( 9.0617984593866399e-01, 2.3692688505618909e-01),
};


int Triangle_1D_1P::NumPoints() const { return 1; }
int Triangle_2D_3P::NumPoints() const { return 3; }
int Triangle_3D_4P::NumPoints() const { return 4; }
int Triangle_4D_6P::NumPoints() const { return 6; }
int Triangle_5D_7P::NumPoints() const { return 7; }


Point2D Triangle_1D_1P::Point(int n) const { return points[n]; }
Point2D Triangle_2D_3P::Point(int n) const { return points[n]; }
Point2D Triangle_3D_4P::Point(int n) const { return points[n]; }
Point2D Triangle_4D_6P::Point(int n) const { return points[n]; }
Point2D Triangle_5D_7P::Point(int n) const { return points[n]; }


const Point2D Triangle_1D_1P::points[] = {
	Point2D( 3.3333333333333333e-01,  3.3333333333333333e-01, 5.0000000000000000e-01),
};

const Point2D Triangle_2D_3P::points[] = {
	Point2D( 1.6666666666666667e-01,  6.6666666666666667e-01, 1.6666666666666667e-01),
	Point2D( 1.6666666666666667e-01,  1.6666666666666667e-01, 1.6666666666666667e-01),
	Point2D( 6.6666666666666667e-01,  1.6666666666666667e-01, 1.6666666666666667e-01),
};

const Point2D Triangle_3D_4P::points[] = {
	Point2D( 2.0000000000000000e-01,  2.0000000000000000e-01, 2.6041666666666667e-01),
	Point2D( 3.3333333333333333e-01,  3.3333333333333333e-01,-2.8125000000000000e-01),
	Point2D( 2.0000000000000000e-01,  6.0000000000000000e-01, 2.6041666666666667e-01),
	Point2D( 6.0000000000000000e-01,  2.0000000000000000e-01, 2.6041666666666667e-01),
};

const Point2D Triangle_4D_6P::points[] = {
	Point2D( 8.1684757298045851e-01, 9.1576213509770743e-02, 5.4975871827660934e-02),
	Point2D( 9.1576213509770743e-02, 8.1684757298045851e-01, 5.4975871827660934e-02),
	Point2D( 9.1576213509770743e-02, 9.1576213509770743e-02, 5.4975871827660934e-02),
	Point2D( 1.0810301816807023e-01, 4.4594849091596489e-01, 1.1169079483900573e-01),
	Point2D( 4.4594849091596489e-01, 1.0810301816807023e-01, 1.1169079483900573e-01),
	Point2D( 4.4594849091596489e-01, 4.4594849091596489e-01, 1.1169079483900573e-01),
};

const Point2D Triangle_5D_7P::points[] = {
	Point2D( 1.0128650732345634e-01,  1.0128650732345634e-01, 6.2969590272413576e-02),
	Point2D( 1.0128650732345634e-01,  7.9742698535308732e-01, 6.2969590272413576e-02),
	Point2D( 3.3333333333333333e-01,  3.3333333333333333e-01, 1.1250000000000000e-01),
	Point2D( 4.7014206410511509e-01,  4.7014206410511509e-01, 6.6197076394253090e-02),
	Point2D( 4.7014206410511509e-01,  5.9715871789769820e-02, 6.6197076394253090e-02),
	Point2D( 5.9715871789769820e-02,  4.7014206410511509e-01, 6.6197076394253090e-02),
	Point2D( 7.9742698535308732e-01,  1.0128650732345634e-01, 6.2969590272413576e-02),
};


int Quadrangle_1D_1P ::NumPoints() const { return  1; }
int Quadrangle_2D_3P ::NumPoints() const { return  3; }
int Quadrangle_3D_4P ::NumPoints() const { return  4; }
int Quadrangle_5D_7P ::NumPoints() const { return  7; }
int Quadrangle_7D_12P::NumPoints() const { return 12; }
int Quadrangle_9D_17P::NumPoints() const { return 17; }


Point2D Quadrangle_1D_1P ::Point(int n) const { return points[n]; }
Point2D Quadrangle_2D_3P ::Point(int n) const { return points[n]; }
Point2D Quadrangle_3D_4P ::Point(int n) const { return points[n]; }
Point2D Quadrangle_5D_7P ::Point(int n) const { return points[n]; }
Point2D Quadrangle_7D_12P::Point(int n) const { return points[n]; }
Point2D Quadrangle_9D_17P::Point(int n) const { return points[n]; }


const Point2D Quadrangle_1D_1P::points[] = {
	Point2D( 0.0000000000000000e+00,  0.0000000000000000e+00, 4.0000000000000000e+00),
};

const Point2D Quadrangle_2D_3P::points[] = {
	Point2D(-4.0824829046386302e-01,-7.0710678118654752e-01, 1.3333333333333333e+00),
	Point2D(-4.0824829046386302e-01, 7.0710678118654752e-01, 1.3333333333333333e+00),
	Point2D( 8.1649658092772603e-01, 0.0000000000000000e+00, 1.3333333333333333e+00),

};

const Point2D Quadrangle_3D_4P::points[] = {
	Point2D(-5.7735026918962576e-01, -5.7735026918962576e-01, 1.0000000000000000e+00),
	Point2D(-5.7735026918962576e-01,  5.7735026918962576e-01, 1.0000000000000000e+00),
	Point2D( 5.7735026918962576e-01, -5.7735026918962576e-01, 1.0000000000000000e+00),
	Point2D( 5.7735026918962576e-01,  5.7735026918962576e-01, 1.0000000000000000e+00),
};

const Point2D Quadrangle_5D_7P::points[] = {
	Point2D(-7.7459666924148338e-01, -5.7735026918962576e-01, 5.5555555555555556e-01),
	Point2D(-7.7459666924148338e-01,  5.7735026918962576e-01, 5.5555555555555556e-01),
	Point2D( 0.0000000000000000e+00, -9.6609178307929590e-01, 3.1746031746031746e-01),
	Point2D( 0.0000000000000000e+00,  0.0000000000000000e+00, 1.1428571428571429e+00),
	Point2D( 0.0000000000000000e+00,  9.6609178307929590e-01, 3.1746031746031746e-01),
	Point2D( 7.7459666924148338e-01, -5.7735026918962576e-01, 5.5555555555555556e-01),
	Point2D( 7.7459666924148338e-01,  5.7735026918962576e-01, 5.5555555555555556e-01),
};

const Point2D Quadrangle_7D_12P::points[] = {
	Point2D(-9.2582009977255146e-01,  0.0000000000000000e+00, 2.4197530864197531e-01),
	Point2D(-8.0597978291859874e-01, -8.0597978291859874e-01, 2.3743177469063023e-01),
	Point2D(-8.0597978291859874e-01,  8.0597978291859874e-01, 2.3743177469063023e-01),
	Point2D(-3.8055443320831566e-01, -3.8055443320831566e-01, 5.2059291666739446e-01),
	Point2D(-3.8055443320831566e-01,  3.8055443320831566e-01, 5.2059291666739446e-01),
	Point2D( 0.0000000000000000e+00, -9.2582009977255146e-01, 2.4197530864197531e-01),
	Point2D( 0.0000000000000000e+00,  9.2582009977255146e-01, 2.4197530864197531e-01),
	Point2D( 3.8055443320831566e-01, -3.8055443320831566e-01, 5.2059291666739446e-01),
	Point2D( 3.8055443320831566e-01,  3.8055443320831566e-01, 5.2059291666739446e-01),
	Point2D( 8.0597978291859874e-01, -8.0597978291859874e-01, 2.3743177469063023e-01),
	Point2D( 8.0597978291859874e-01,  8.0597978291859874e-01, 2.3743177469063023e-01),
	Point2D( 9.2582009977255146e-01,  0.0000000000000000e+00, 2.4197530864197531e-01),
};

const Point2D Quadrangle_9D_17P::points[] = {
	Point2D(-9.6884996636197772e-01, -6.3068011973166885e-01, 8.8879378170198707e-02),
	Point2D(-9.2796164595956967e-01,  7.5027709997890053e-01, 1.1209960212959649e-01),
	Point2D(-8.5261572933366231e-01,  7.6208328192617173e-02, 2.6905133763978080e-01),
	Point2D(-7.6208328192617173e-02, -8.5261572933366231e-01, 2.6905133763978080e-01),
	Point2D(-7.5027709997890053e-01, -9.2796164595956967e-01, 1.1209960212959649e-01),
	Point2D(-6.3068011973166885e-01,  9.6884996636197772e-01, 8.8879378170198707e-02),
	Point2D(-5.2373582021442934e-01, -4.5333982113564719e-01, 3.9828243926207010e-01),
	Point2D(-4.5333982113564719e-01,  5.2373582021442934e-01, 3.9828243926207010e-01),
	Point2D( 0.0000000000000000e+00,  0.0000000000000000e+00, 5.2674897119341564e-01),
	Point2D( 4.5333982113564719e-01, -5.2373582021442934e-01, 3.9828243926207010e-01),
	Point2D( 5.2373582021442934e-01,  4.5333982113564719e-01, 3.9828243926207010e-01),
	Point2D( 6.3068011973166885e-01, -9.6884996636197772e-01, 8.8879378170198707e-02),
	Point2D( 7.5027709997890053e-01,  9.2796164595956967e-01, 1.1209960212959649e-01),
	Point2D( 7.6208328192617173e-02,  8.5261572933366231e-01, 2.6905133763978080e-01),
	Point2D( 8.5261572933366231e-01, -7.6208328192617173e-02, 2.6905133763978080e-01),
	Point2D( 9.2796164595956967e-01, -7.5027709997890053e-01, 1.1209960212959649e-01),
	Point2D( 9.6884996636197772e-01,  6.3068011973166885e-01, 8.8879378170198707e-02),
};


} /* namespace Scheme */


} /* namespace Gauss */

Пример использования (Quadrangle_3D_4P значит "Прямоугольник", "Полином до 3 степени", "4 точки"):

Код:

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

 
#include<iostream>
#include "Gauss.h"


double f(double u, double v)
{
	return u*u + u*v + v*v;
}


int main()
{
	double Integral = 0.0;

	Gauss::Scheme::Quadrangle_3D_4P scheme;

	for(int n = 0; n < scheme.NumPoints(); n++) {
		Gauss::Point2D point = scheme.Point(n);
		Integral += point.Weight() * f(point.u(), point.v());
	}

	std::cout << "Integral = " << Integral << std::endl;

	return 0;
}

Тест точности:

Код:

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

 
#include<iostream>
#include<ctime>
#include<math.h>
#include "Gauss.h"


struct Line_Poly_1D {
	double f(double u) {
		return
		1 +
		u;
	}
	double F() { return 2.0; }
};

struct Line_Poly_2D {
	double f(double u) {
		return
		1 +
		u +
		u*u;
	}
	double F() { return 8.0 / 3.0; }
};

struct Line_Poly_3D {
	double f(double u){
		return
		1 +
		u +
		u*u +
		u*u*u;
	}
	double F() { return 8.0 / 3.0; }
};

struct Line_Poly_4D {
	double f(double u) {
		return
		1 +
		u +
		u*u +
		u*u*u +
		u*u*u*u;
	}
	double F() { return 46.0 / 15.0; }
};

struct Line_Poly_5D {
	double f(double u) {
		return
		1 +
		u +
		u*u +
		u*u*u +
		u*u*u*u +
		u*u*u*u*u;
	}
	double F() { return 46.0 / 15.0; }
};

struct Line_Poly_6D {
	double f(double u) {
		return
		1 +
		u +
		u*u +
		u*u*u +
		u*u*u*u +
		u*u*u*u*u +
		u*u*u*u*u*u;
	}
	double F() { return 352.0 / 105.0; }
};

struct Line_Poly_7D {
	double f(double u) {
		return
		1 +
		u +
		u*u +
		u*u*u +
		u*u*u*u +
		u*u*u*u*u +
		u*u*u*u*u*u +
		u*u*u*u*u*u*u;
	}
	double F() { return 352.0 / 105.0; }
};

struct Line_Poly_8D {
	double f(double u) {
		return
		1 +
		u +
		u*u +
		u*u*u +
		u*u*u*u +
		u*u*u*u*u +
		u*u*u*u*u*u +
		u*u*u*u*u*u*u +
		u*u*u*u*u*u*u*u;
	}
	double F() { return 1126.0 / 315.0; }
};

struct Line_Poly_9D {
	double f(double u) {
		return
		1 +
		u +
		u*u +
		u*u*u +
		u*u*u*u +
		u*u*u*u*u +
		u*u*u*u*u*u +
		u*u*u*u*u*u*u +
		u*u*u*u*u*u*u*u +
		u*u*u*u*u*u*u*u*u;
	}
	double F() { return 1126.0 / 315.0; }
};

#define TEST_LINE(POLYNOM, GAUSS_SCHEME) \
{ \
	std::cout.precision(17); \
	std::cout << "Gauss::Scheme::" << #GAUSS_SCHEME  << std::endl; \
	std::cout << #POLYNOM << std::endl; \
	POLYNOM poly; \
	Gauss::Scheme::GAUSS_SCHEME scheme; \
	double F = 0.0; \
	for(int n = 0; n < scheme.NumPoints(); n++) { \
		Gauss::Point1D point = scheme.Point(n); \
		F += point.Weight() * poly.f(point.u()); \
	} \
	std::cout << "Numerically:  "  <<      F   << std::endl; \
	std::cout << "Analytically: " << poly.F() << std::endl << std::endl; \
}


struct Triangle_Poly_1D {
	double f(double u, double v) {
		return
		1 +
		u + v;
	}
	double F() { return 5.0 / 6.0; }
};

struct Triangle_Poly_2D {
	double f(double u, double v) {
		return
		1 +
		u + v +
		u*u + v*v + u*v;
	}
	double F() { return 25.0 / 24.0; }
};

struct Triangle_Poly_3D {
	double f(double u, double v) {
		return
		1 +
		u + v +
		u*u + v*v + u*v +
		u*u*u + u*u*v + u*v*v + v*v*v;
	}
	double F() { return 47.0 / 40.0; }
};

struct Triangle_Poly_4D {
	double f(double u, double v) {
		return
		1 +
		u + v +
		u*u + v*v + u*v +
		u*u*u + u*u*v + u*v*v + v*v*v +
		u*u*u*u + u*u*u*v + u*u*v*v + u*v*v*v + v*v*v*v;
	}
	double F() { return 91.0 / 72.0; }
};

struct Triangle_Poly_5D {
	double f(double u, double v) {
		return
		1 + u + v +
		u*u + v*v + u*v +
		u*u*u + u*u*v + u*v*v + v*v*v +
		u*u*u*u + u*u*u*v + u*u*v*v + u*v*v*v + v*v*v*v +
		u*u*u*u*u + u*u*u*u*v + u*u*u*v*v + u*u*v*v*v + u*v*v*v*v + v*v*v*v*v;
	}
	double F() { return 3341.0 / 2520.0; }
};

#define TEST_TRIANGLE(POLYNOM, GAUSS_SCHEME) \
{ \
	std::cout.precision(17); \
	std::cout << "Gauss::Scheme::" << #GAUSS_SCHEME  << std::endl; \
	std::cout << #POLYNOM << std::endl; \
	POLYNOM poly; \
	Gauss::Scheme::GAUSS_SCHEME scheme; \
	double F = 0.0; \
	for(int n = 0; n < scheme.NumPoints(); n++) { \
		Gauss::Point2D point = scheme.Point(n); \
		F += point.Weight() * poly.f(point.u(), point.v()); \
	} \
	std::cout << "Numerically:  "  <<      F   << std::endl; \
	std::cout << "Analytically: " << poly.F() << std::endl << std::endl; \
}


struct Quadrangle_Poly_1D {
	double f(double u, double v) {
		return
		1 +
		u + v;
	}
	double F() { return 4.0; }
};

struct Quadrangle_Poly_2D {
	double f(double u, double v) {
		return
		1 +
		u + v +
		u*u + v*v + u*v;
	}
	double F() { return 20.0 / 3.0; }
};

struct Quadrangle_Poly_3D {
	double f(double u, double v) {
		return
		1 +
		u + v +
		u*u + v*v + u*v +
		u*u*u + u*u*v + u*v*v + v*v*v;
	}
	double F() { return 20.0 / 3.0; }
};

struct Quadrangle_Poly_4D {
	double f(double u, double v) {
		return
		1 +
		u + v +
		u*u + v*v + u*v +
		u*u*u + u*u*v + u*v*v + v*v*v +
		u*u*u*u + u*u*u*v + u*u*v*v + u*v*v*v + v*v*v*v;
	}
	double F() { return 392.0 / 45.0; }
};

struct Quadrangle_Poly_5D {
	double f(double u, double v) {
		return
		1 + u + v +
		u*u + v*v + u*v +
		u*u*u + u*u*v + u*v*v + v*v*v +
		u*u*u*u + u*u*u*v + u*u*v*v + u*v*v*v + v*v*v*v +
		u*u*u*u*u + u*u*u*u*v + u*u*u*v*v + u*u*v*v*v + u*v*v*v*v + v*v*v*v*v;
	}
	double F() { return 392.0 / 45.0; }
};

struct Quadrangle_Poly_6D {
	double f(double u, double v) {
		return
		1 + u + v +
		u*u + v*v + u*v +
		u*u*u + u*u*v + u*v*v + v*v*v +
		u*u*u*u + u*u*u*v + u*u*v*v + u*v*v*v + v*v*v*v +
		u*u*u*u*u + u*u*u*u*v + u*u*u*v*v + u*u*v*v*v + u*v*v*v*v + v*v*v*v*v +
		u*u*u*u*u*u + u*u*u*u*u*v + u*u*u*u*v*v + u*u*u*v*v*v + u*u*v*v*v*v + u*v*v*v*v*v + v*v*v*v*v*v;
	}
	double F() { return 3272.0 / 315.0; }
};


struct Quadrangle_Poly_7D {
	double f(double u, double v) {
		return
		1 + u + v +
		u*u + v*v + u*v +
		u*u*u + u*u*v + u*v*v + v*v*v +
		u*u*u*u + u*u*u*v + u*u*v*v + u*v*v*v + v*v*v*v +
		u*u*u*u*u + u*u*u*u*v + u*u*u*v*v + u*u*v*v*v + u*v*v*v*v + v*v*v*v*v +
		u*u*u*u*u*u + u*u*u*u*u*v + u*u*u*u*v*v + u*u*u*v*v*v + u*u*v*v*v*v + u*v*v*v*v*v + v*v*v*v*v*v +
		u*u*u*u*u*u*u + u*u*u*u*u*u*v + u*u*u*u*u*v*v + u*u*u*u*v*v*v + u*u*u*v*v*v*v + u*u*v*v*v*v*v + u*v*v*v*v*v*v + v*v*v*v*v*v*v;
	}
	double F() { return 3272.0 / 315.0; }
};

struct Quadrangle_Poly_8D {
	double f(double u, double v) {
		return
		1 + u + v +
		u*u + v*v + u*v +
		u*u*u + u*u*v + u*v*v + v*v*v +
		u*u*u*u + u*u*u*v + u*u*v*v + u*v*v*v + v*v*v*v +
		u*u*u*u*u + u*u*u*u*v + u*u*u*v*v + u*u*v*v*v + u*v*v*v*v + v*v*v*v*v +
		u*u*u*u*u*u + u*u*u*u*u*v + u*u*u*u*v*v + u*u*u*v*v*v + u*u*v*v*v*v + u*v*v*v*v*v + v*v*v*v*v*v +
		u*u*u*u*u*u*u + u*u*u*u*u*u*v + u*u*u*u*u*v*v + u*u*u*u*v*v*v + u*u*u*v*v*v*v + u*u*v*v*v*v*v + u*v*v*v*v*v*v + v*v*v*v*v*v*v +
		u*u*u*u*u*u*u*u + u*u*u*u*u*u*u*v + u*u*u*u*u*u*v*v + u*u*u*u*u*v*v*v + u*u*u*u*v*v*v*v + u*u*u*v*v*v*v*v + u*u*v*v*v*v*v*v + u*v*v*v*v*v*v*v + v*v*v*v*v*v*v*v;
	}
	double F() { return 2068.0 / 175.0; }
};

struct Quadrangle_Poly_9D {
	double f(double u, double v) {
		return
		1 + u + v +
		u*u + v*v + u*v +
		u*u*u + u*u*v + u*v*v + v*v*v +
		u*u*u*u + u*u*u*v + u*u*v*v + u*v*v*v + v*v*v*v +
		u*u*u*u*u + u*u*u*u*v + u*u*u*v*v + u*u*v*v*v + u*v*v*v*v + v*v*v*v*v +
		u*u*u*u*u*u + u*u*u*u*u*v + u*u*u*u*v*v + u*u*u*v*v*v + u*u*v*v*v*v + u*v*v*v*v*v + v*v*v*v*v*v +
		u*u*u*u*u*u*u + u*u*u*u*u*u*v + u*u*u*u*u*v*v + u*u*u*u*v*v*v + u*u*u*v*v*v*v + u*u*v*v*v*v*v + u*v*v*v*v*v*v + v*v*v*v*v*v*v +
		u*u*u*u*u*u*u*u + u*u*u*u*u*u*u*v + u*u*u*u*u*u*v*v + u*u*u*u*u*v*v*v + u*u*u*u*v*v*v*v + u*u*u*v*v*v*v*v + u*u*v*v*v*v*v*v + u*v*v*v*v*v*v*v + v*v*v*v*v*v*v*v +
		u*u*u*u*u*u*u*u*u + u*u*u*u*u*u*u*u*v + u*u*u*u*u*u*u*v*v + u*u*u*u*u*u*v*v*v + u*u*u*u*u*v*v*v*v + u*u*u*u*v*v*v*v*v + u*u*u*v*v*v*v*v*v + u*u*v*v*v*v*v*v*v + u*v*v*v*v*v*v*v*v + v*v*v*v*v*v*v*v*v;
	}
	double F() { return 2068.0 / 175.0; }
};

#define TEST_QUADRANGLE(POLYNOM, GAUSS_SCHEME) \
{ \
	std::cout.precision(17); \
	std::cout << "Gauss::Scheme::" << #GAUSS_SCHEME  << std::endl; \
	std::cout << #POLYNOM << std::endl; \
	POLYNOM poly; \
	Gauss::Scheme::GAUSS_SCHEME scheme; \
	double F = 0.0; \
	for(int n = 0; n < scheme.NumPoints(); n++) { \
		Gauss::Point2D point = scheme.Point(n); \
		F += point.Weight() * poly.f(point.u(), point.v()); \
	} \
	std::cout << "Numerically:  "  <<      F   << std::endl; \
	std::cout << "Analytically: " << poly.F() << std::endl << std::endl; \
}


int main()
{
	TEST_LINE(Line_Poly_1D, Line_1D_1P)

	TEST_LINE(Line_Poly_1D, Line_3D_2P)
	TEST_LINE(Line_Poly_2D, Line_3D_2P)
	TEST_LINE(Line_Poly_3D, Line_3D_2P)

	TEST_LINE(Line_Poly_1D, Line_5D_3P)
	TEST_LINE(Line_Poly_2D, Line_5D_3P)
	TEST_LINE(Line_Poly_3D, Line_5D_3P)
	TEST_LINE(Line_Poly_4D, Line_5D_3P)
	TEST_LINE(Line_Poly_5D, Line_5D_3P)

	TEST_LINE(Line_Poly_1D, Line_7D_4P)
	TEST_LINE(Line_Poly_2D, Line_7D_4P)
	TEST_LINE(Line_Poly_3D, Line_7D_4P)
	TEST_LINE(Line_Poly_4D, Line_7D_4P)
	TEST_LINE(Line_Poly_5D, Line_7D_4P)
	TEST_LINE(Line_Poly_6D, Line_7D_4P)
	TEST_LINE(Line_Poly_7D, Line_7D_4P)

	TEST_LINE(Line_Poly_1D, Line_9D_5P)
	TEST_LINE(Line_Poly_2D, Line_9D_5P)
	TEST_LINE(Line_Poly_3D, Line_9D_5P)
	TEST_LINE(Line_Poly_4D, Line_9D_5P)
	TEST_LINE(Line_Poly_5D, Line_9D_5P)
	TEST_LINE(Line_Poly_6D, Line_9D_5P)
	TEST_LINE(Line_Poly_7D, Line_9D_5P)
	TEST_LINE(Line_Poly_8D, Line_9D_5P)
	TEST_LINE(Line_Poly_9D, Line_9D_5P)


	TEST_TRIANGLE(Triangle_Poly_1D, Triangle_1D_1P)

	TEST_TRIANGLE(Triangle_Poly_1D, Triangle_2D_3P)
	TEST_TRIANGLE(Triangle_Poly_2D, Triangle_2D_3P)

	TEST_TRIANGLE(Triangle_Poly_1D, Triangle_3D_4P)
	TEST_TRIANGLE(Triangle_Poly_2D, Triangle_3D_4P)
	TEST_TRIANGLE(Triangle_Poly_3D, Triangle_3D_4P)

	TEST_TRIANGLE(Triangle_Poly_1D, Triangle_4D_6P)
	TEST_TRIANGLE(Triangle_Poly_2D, Triangle_4D_6P)
	TEST_TRIANGLE(Triangle_Poly_3D, Triangle_4D_6P)
	TEST_TRIANGLE(Triangle_Poly_4D, Triangle_4D_6P)

	TEST_TRIANGLE(Triangle_Poly_1D, Triangle_5D_7P)
	TEST_TRIANGLE(Triangle_Poly_2D, Triangle_5D_7P)
	TEST_TRIANGLE(Triangle_Poly_3D, Triangle_5D_7P)
	TEST_TRIANGLE(Triangle_Poly_4D, Triangle_5D_7P)
	TEST_TRIANGLE(Triangle_Poly_5D, Triangle_5D_7P)


	TEST_QUADRANGLE(Quadrangle_Poly_1D, Quadrangle_1D_1P)

	TEST_QUADRANGLE(Quadrangle_Poly_1D, Quadrangle_2D_3P)
	TEST_QUADRANGLE(Quadrangle_Poly_2D, Quadrangle_2D_3P)

	TEST_QUADRANGLE(Quadrangle_Poly_1D, Quadrangle_3D_4P)
	TEST_QUADRANGLE(Quadrangle_Poly_2D, Quadrangle_3D_4P)
	TEST_QUADRANGLE(Quadrangle_Poly_3D, Quadrangle_3D_4P)

	TEST_QUADRANGLE(Quadrangle_Poly_1D, Quadrangle_5D_7P)
	TEST_QUADRANGLE(Quadrangle_Poly_2D, Quadrangle_5D_7P)
	TEST_QUADRANGLE(Quadrangle_Poly_3D, Quadrangle_5D_7P)
	TEST_QUADRANGLE(Quadrangle_Poly_4D, Quadrangle_5D_7P)
	TEST_QUADRANGLE(Quadrangle_Poly_5D, Quadrangle_5D_7P)

	TEST_QUADRANGLE(Quadrangle_Poly_1D, Quadrangle_7D_12P)
	TEST_QUADRANGLE(Quadrangle_Poly_2D, Quadrangle_7D_12P)
	TEST_QUADRANGLE(Quadrangle_Poly_3D, Quadrangle_7D_12P)
	TEST_QUADRANGLE(Quadrangle_Poly_4D, Quadrangle_7D_12P)
	TEST_QUADRANGLE(Quadrangle_Poly_5D, Quadrangle_7D_12P)
	TEST_QUADRANGLE(Quadrangle_Poly_6D, Quadrangle_7D_12P)
	TEST_QUADRANGLE(Quadrangle_Poly_7D, Quadrangle_7D_12P)

	TEST_QUADRANGLE(Quadrangle_Poly_1D, Quadrangle_9D_17P)
	TEST_QUADRANGLE(Quadrangle_Poly_2D, Quadrangle_9D_17P)
	TEST_QUADRANGLE(Quadrangle_Poly_3D, Quadrangle_9D_17P)
	TEST_QUADRANGLE(Quadrangle_Poly_4D, Quadrangle_9D_17P)
	TEST_QUADRANGLE(Quadrangle_Poly_5D, Quadrangle_9D_17P)
	TEST_QUADRANGLE(Quadrangle_Poly_6D, Quadrangle_9D_17P)
	TEST_QUADRANGLE(Quadrangle_Poly_7D, Quadrangle_9D_17P)
	TEST_QUADRANGLE(Quadrangle_Poly_8D, Quadrangle_9D_17P)
	TEST_QUADRANGLE(Quadrangle_Poly_9D, Quadrangle_9D_17P)

	return 0;
}

Код:

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

Gauss::Scheme::Line_1D_1P
Line_Poly_1D
Numerically:  2
Analytically: 2

Gauss::Scheme::Line_3D_2P
Line_Poly_1D
Numerically:  2
Analytically: 2

Gauss::Scheme::Line_3D_2P
Line_Poly_2D
Numerically:  2.6666666666666665
Analytically: 2.6666666666666665

Gauss::Scheme::Line_3D_2P
Line_Poly_3D
Numerically:  2.6666666666666665
Analytically: 2.6666666666666665

Gauss::Scheme::Line_5D_3P
Line_Poly_1D
Numerically:  2
Analytically: 2

Gauss::Scheme::Line_5D_3P
Line_Poly_2D
Numerically:  2.666666666666667
Analytically: 2.6666666666666665

Gauss::Scheme::Line_5D_3P
Line_Poly_3D
Numerically:  2.666666666666667
Analytically: 2.6666666666666665

Gauss::Scheme::Line_5D_3P
Line_Poly_4D
Numerically:  3.0666666666666669
Analytically: 3.0666666666666669

Gauss::Scheme::Line_5D_3P
Line_Poly_5D
Numerically:  3.0666666666666669
Analytically: 3.0666666666666669

Gauss::Scheme::Line_7D_4P
Line_Poly_1D
Numerically:  1.9999999999999998
Analytically: 2

Gauss::Scheme::Line_7D_4P
Line_Poly_2D
Numerically:  2.6666666666666665
Analytically: 2.6666666666666665

Gauss::Scheme::Line_7D_4P
Line_Poly_3D
Numerically:  2.6666666666666665
Analytically: 2.6666666666666665

Gauss::Scheme::Line_7D_4P
Line_Poly_4D
Numerically:  3.0666666666666664
Analytically: 3.0666666666666669

Gauss::Scheme::Line_7D_4P
Line_Poly_5D
Numerically:  3.0666666666666664
Analytically: 3.0666666666666669

Gauss::Scheme::Line_7D_4P
Line_Poly_6D
Numerically:  3.3523809523809525
Analytically: 3.3523809523809525

Gauss::Scheme::Line_7D_4P
Line_Poly_7D
Numerically:  3.3523809523809529
Analytically: 3.3523809523809525

Gauss::Scheme::Line_9D_5P
Line_Poly_1D
Numerically:  2
Analytically: 2

Gauss::Scheme::Line_9D_5P
Line_Poly_2D
Numerically:  2.666666666666667
Analytically: 2.6666666666666665

Gauss::Scheme::Line_9D_5P
Line_Poly_3D
Numerically:  2.6666666666666665
Analytically: 2.6666666666666665

Gauss::Scheme::Line_9D_5P
Line_Poly_4D
Numerically:  3.0666666666666664
Analytically: 3.0666666666666669

Gauss::Scheme::Line_9D_5P
Line_Poly_5D
Numerically:  3.0666666666666664
Analytically: 3.0666666666666669

Gauss::Scheme::Line_9D_5P
Line_Poly_6D
Numerically:  3.352380952380952
Analytically: 3.3523809523809525

Gauss::Scheme::Line_9D_5P
Line_Poly_7D
Numerically:  3.352380952380952
Analytically: 3.3523809523809525

Gauss::Scheme::Line_9D_5P
Line_Poly_8D
Numerically:  3.5746031746031743
Analytically: 3.5746031746031748

Gauss::Scheme::Line_9D_5P
Line_Poly_9D
Numerically:  3.5746031746031743
Analytically: 3.5746031746031748

Gauss::Scheme::Triangle_1D_1P
Triangle_Poly_1D
Numerically:  0.83333333333333326
Analytically: 0.83333333333333337

Gauss::Scheme::Triangle_2D_3P
Triangle_Poly_1D
Numerically:  0.83333333333333326
Analytically: 0.83333333333333337

Gauss::Scheme::Triangle_2D_3P
Triangle_Poly_2D
Numerically:  1.0416666666666665
Analytically: 1.0416666666666667

Gauss::Scheme::Triangle_3D_4P
Triangle_Poly_1D
Numerically:  0.83333333333333348
Analytically: 0.83333333333333337

Gauss::Scheme::Triangle_3D_4P
Triangle_Poly_2D
Numerically:  1.0416666666666667
Analytically: 1.0416666666666667

Gauss::Scheme::Triangle_3D_4P
Triangle_Poly_3D
Numerically:  1.1750000000000003
Analytically: 1.175

Gauss::Scheme::Triangle_4D_6P
Triangle_Poly_1D
Numerically:  0.83333333333333326
Analytically: 0.83333333333333337

Gauss::Scheme::Triangle_4D_6P
Triangle_Poly_2D
Numerically:  1.0416666666666667
Analytically: 1.0416666666666667

Gauss::Scheme::Triangle_4D_6P
Triangle_Poly_3D
Numerically:  1.175
Analytically: 1.175

Gauss::Scheme::Triangle_4D_6P
Triangle_Poly_4D
Numerically:  1.2638888888888888
Analytically: 1.2638888888888888

Gauss::Scheme::Triangle_5D_7P
Triangle_Poly_1D
Numerically:  0.83333333333333326
Analytically: 0.83333333333333337

Gauss::Scheme::Triangle_5D_7P
Triangle_Poly_2D
Numerically:  1.0416666666666665
Analytically: 1.0416666666666667

Gauss::Scheme::Triangle_5D_7P
Triangle_Poly_3D
Numerically:  1.175
Analytically: 1.175

Gauss::Scheme::Triangle_5D_7P
Triangle_Poly_4D
Numerically:  1.2638888888888891
Analytically: 1.2638888888888888

Gauss::Scheme::Triangle_5D_7P
Triangle_Poly_5D
Numerically:  1.325793650793651
Analytically: 1.3257936507936507

Gauss::Scheme::Quadrangle_1D_1P
Quadrangle_Poly_1D
Numerically:  4
Analytically: 4

Gauss::Scheme::Quadrangle_2D_3P
Quadrangle_Poly_1D
Numerically:  3.9999999999999996
Analytically: 4

Gauss::Scheme::Quadrangle_2D_3P
Quadrangle_Poly_2D
Numerically:  6.666666666666667
Analytically: 6.666666666666667

Gauss::Scheme::Quadrangle_3D_4P
Quadrangle_Poly_1D
Numerically:  4
Analytically: 4

Gauss::Scheme::Quadrangle_3D_4P
Quadrangle_Poly_2D
Numerically:  6.6666666666666661
Analytically: 6.666666666666667

Gauss::Scheme::Quadrangle_3D_4P
Quadrangle_Poly_3D
Numerically:  6.6666666666666661
Analytically: 6.666666666666667

Gauss::Scheme::Quadrangle_5D_7P
Quadrangle_Poly_1D
Numerically:  4
Analytically: 4

Gauss::Scheme::Quadrangle_5D_7P
Quadrangle_Poly_2D
Numerically:  6.666666666666667
Analytically: 6.666666666666667

Gauss::Scheme::Quadrangle_5D_7P
Quadrangle_Poly_3D
Numerically:  6.666666666666667
Analytically: 6.666666666666667

Gauss::Scheme::Quadrangle_5D_7P
Quadrangle_Poly_4D
Numerically:  8.7111111111111121
Analytically: 8.7111111111111104

Gauss::Scheme::Quadrangle_5D_7P
Quadrangle_Poly_5D
Numerically:  8.7111111111111121
Analytically: 8.7111111111111104

Gauss::Scheme::Quadrangle_7D_12P
Quadrangle_Poly_1D
Numerically:  4
Analytically: 4

Gauss::Scheme::Quadrangle_7D_12P
Quadrangle_Poly_2D
Numerically:  6.666666666666667
Analytically: 6.666666666666667

Gauss::Scheme::Quadrangle_7D_12P
Quadrangle_Poly_3D
Numerically:  6.6666666666666661
Analytically: 6.666666666666667

Gauss::Scheme::Quadrangle_7D_12P
Quadrangle_Poly_4D
Numerically:  8.7111111111111104
Analytically: 8.7111111111111104

Gauss::Scheme::Quadrangle_7D_12P
Quadrangle_Poly_5D
Numerically:  8.7111111111111121
Analytically: 8.7111111111111104

Gauss::Scheme::Quadrangle_7D_12P
Quadrangle_Poly_6D
Numerically:  10.387301587301589
Analytically: 10.387301587301588

Gauss::Scheme::Quadrangle_7D_12P
Quadrangle_Poly_7D
Numerically:  10.387301587301586
Analytically: 10.387301587301588

Gauss::Scheme::Quadrangle_9D_17P
Quadrangle_Poly_1D
Numerically:  4
Analytically: 4

Gauss::Scheme::Quadrangle_9D_17P
Quadrangle_Poly_2D
Numerically:  6.666666666666667
Analytically: 6.666666666666667

Gauss::Scheme::Quadrangle_9D_17P
Quadrangle_Poly_3D
Numerically:  6.666666666666667
Analytically: 6.666666666666667

Gauss::Scheme::Quadrangle_9D_17P
Quadrangle_Poly_4D
Numerically:  8.7111111111111104
Analytically: 8.7111111111111104

Gauss::Scheme::Quadrangle_9D_17P
Quadrangle_Poly_5D
Numerically:  8.7111111111111121
Analytically: 8.7111111111111104

Gauss::Scheme::Quadrangle_9D_17P
Quadrangle_Poly_6D
Numerically:  10.387301587301588
Analytically: 10.387301587301588

Gauss::Scheme::Quadrangle_9D_17P
Quadrangle_Poly_7D
Numerically:  10.387301587301588
Analytically: 10.387301587301588

Gauss::Scheme::Quadrangle_9D_17P
Quadrangle_Poly_8D
Numerically:  11.817142857142859
Analytically: 11.817142857142857

Gauss::Scheme::Quadrangle_9D_17P
Quadrangle_Poly_9D
Numerically:  11.817142857142857
Analytically: 11.817142857142857

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

[румата]

Сообщение от Нубий-IV Оказывается, гаусс-то засекречен!

Кем он засекречен? https://ru.wikipedia.org/wiki/%D0%A1...BC%D1%83%D0%BB

----- добавлено через -----

Сообщение от Нубий-IV В книгах по интегрированию либо теория с примерами для низких степеней, либо числовые коэффициенты с 5-15 знаками, что недотягивает до точности double.

По ссылке весовые к-ты даны в натуральных дробях. Точности хоть отбавляй

[Нубий-IV]

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

Код:

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

 
#include <iostream>

const size_t NUM_NODES = 200000;
const size_t NUM_ELEMENTS = 300000;
const size_t NUM_ELEMENT_NODES = 4;
const size_t NUM_NODE_VARS = 6;
const size_t NUM_LOADS = 20;

struct Node {
	double x;
	double y;
	double z;
};

struct Element {
	double K[NUM_NODE_VARS * NUM_ELEMENT_NODES][NUM_NODE_VARS * NUM_ELEMENT_NODES];
};

struct Variable {
	double x;
	double y;
	double z;
	double Ux;
	double Uy;
	double Uz;
};

struct Result {
	double Nx;
	double Ny;
	double Txy;
	double Mx;
	double My;
	double Mxy;

	double Sxx;
	double Syy;
	double Szz;
	double Sxy;
	double Syz;
	double Szx;

	double Asxt;
	double Asxb;
	double Asyt;
	double Asyb;
};

int main()
{
	Node** nodes = new Node*[NUM_NODES];
	for(size_t i = 0; i < NUM_NODES; i++)
		nodes[i] = new Node;
	std::cout << "nodes = " << nodes << std::endl;
	//std::cin.get();

	Element** elements = new Element*[NUM_ELEMENTS];
	for(size_t i = 0; i < NUM_ELEMENTS; i++)
		elements[i] = new Element;
	std::cout << "elements = " << elements << std::endl;
	//std::cin.get();

	Variable** variables = new Variable*[NUM_NODES * NUM_LOADS];
	for(size_t i = 0; i < NUM_NODES * NUM_LOADS; i++)
		variables[i] = new Variable;
	std::cout << "variables = " << variables << std::endl;
	//std::cin.get();

	Result** results = new Result*[NUM_NODES * NUM_LOADS];
	for(size_t i = 0; i < NUM_NODES * NUM_LOADS; i++)
		results[i] = new Result;
	std::cout << "results = " << results << std::endl;
	//std::cin.get();

	/*** а так даже не компилируется при 500000 элементах
	Node* nodes = new Node[NUM_NODES];
	std::cout << "nodes = " << nodes << std::endl;

	Element* elements = new Element[NUM_ELEMENTS];
	std::cout << "elements = " << elements << std::endl;

	Variable* variables = new Variable[NUM_NODES * NUM_LOADS];
	std::cout << "variables = " << variables << std::endl;

	Result* results = new Result[NUM_NODES * NUM_LOADS];
	std::cout << "results = " << results << std::endl;
	*/

	return 0;
}

200 тыс узлов - слишком много. Либо x32 вообще отпадает, либо нужен свой диспетчер данных с подкачкой.

Сообщение от румата По ссылке весовые к-ты даны в натуральных дробях.

Только для нескольких степеней. Где там хотя бы 4 степень для треугольника? Найти что-то выше третьей - пятой степени оказалось проблемой. А если у нас будет нелинейность, повышенные степени могут понадобиться.

[румата]

Сообщение от Нубий-IV Где там хотя бы 4 степень для треугольника?

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

[Нубий-IV]

Сообщение от румата А для чего треугольнику порядок выше третьего

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

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

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

Это все. Как по этому описанию получить координаты точек? Ссылка [5,a] - диссертация, нет в свободном доступе. Таблица 15.2 - точки и веса точностью в 7знаков.

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

Кстати, 4-точечная формула из Википедии - единственная возможная, или есть версии без отрицательных коэффициентов?

[румата]

Сообщение от Нубий-IV Кстати, 4-точечная формула из Википедии - единственная возможная, или есть версии без отрицательных коэффициентов?

Я семиточечную применял, тоже вполне рабочий вариант.

Сообщение от Нубий-IV Вопрос-то в том, почему на второй сотне лет численного интегрирования нет полного справочника с формулами и значениями машинной точности.

Может такие справочники и есть где-то, но кому нужны эти сложности, когда для треугольного КЭ вполне достаточно интегрирования 3-го порядка.

[Нубий-IV]

Вот я все тестирую и тестирую, а мне все хуже и хуже. Если x32 работает примерно с 1.5G памяти, то что будет при вызове из нанокада?

Код:

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

 
#include "arxHeaders.h"


class nanoCADmem: public AcRxArxApp {
public:
	virtual AcRx::AppRetCode On_kInitAppMsg (void *pkt)
	{
		AcRx::AppRetCode retCode =AcRxArxApp::On_kInitAppMsg (pkt);
		return (retCode);
	}

	virtual AcRx::AppRetCode On_kUnloadAppMsg (void *pkt)
	{
		AcRx::AppRetCode retCode =AcRxArxApp::On_kUnloadAppMsg (pkt);
		return (retCode);
	}

	virtual void RegisterServerComponents ()
	{

	}

	static void nanoCADmem_memtest(void)
	{
		const int N_BLOCKS = 1000;
		const int BLOCK_SIZE = 100000000;
		
		try {
			double** blocks = new double*[N_BLOCKS];
			for(int i = 0; i < N_BLOCKS; i++) {
				blocks[i] = new double[BLOCK_SIZE];
				acutPrintf(L"Allocate %ib ok", BLOCK_SIZE);
			}
		} catch (...) {
			acutPrintf(L"Allocate %ib error", BLOCK_SIZE);
		}
	}
};

IMPLEMENT_ARX_ENTRYPOINT(nanoCADmem)
ACED_ARXCOMMAND_ENTRY_AUTO(nanoCADmem, nanoCADmem, _memtest, memtest, ACRX_CMD_TRANSPARENT, NULL)

Выделение десяти блоков памяти по 100 метров. В чистом файле выделяется только 3 блока; в большом файле и один не выделяется. Это все, что доступно для работы из-под нанокада.

Четырехугольная оболочка с 6 степенями свободы имеет матрицу жесткости (6*4)*(6*4)*8 = 4.6К = 0.0046M. При доступных 100M в памяти можно разместить только 100/0.0046 = 20 тыс матриц (не считая узлов, самих элементов, матриц преобразований, векторов перемещений и т.п.).

Не то что "хранить матрицы" не выйдет; видимо, безопасно только поэлементное чтение/запись.

[DEM]

А чего все??

[zamtmn]

>>А чего все??
В твоей теме никто не злорадствует))

[DEM]

Сообщение от zamtmn >>А чего все?? В твоей теме никто не злорадствует))

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

[румата]

Сообщение от DEM ДА и там так же было...

А что там было?

[nickname2019]

Сообщение от Бахил Какое ТЗ? Полноценный проект. Осталось найти подрядчика. Можно и "хозспособом" реализовать.

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

Имхо, оптимальная организация труда - колхоз "Светлый путь", внутри которого могут существовать отдельные артели.

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

2. Колхозники могут создавать свои закрытие артели, в которых могут совместно создавать код для использования внутри артели. Они сами принимают решения о том, делиться или не делиться с сообществом разработанным кодом и на каких условиях. Решения внутри артели принимается голосованием, при этом вес "голоса" определяется количеством строк разработанного человеком кода, который он разработал, работая в артели. Принятие/не принятие человека в артель определяется голосованием членов артели. В идеале, артели должны заманивать тех рядовых колхозников, которые имеют высокую "карму", заработанную ими на общих условиях. Артель имеет свой доход, связанный как с использованием разработанного кода каждым членом артели, так и продажей результатов работы (алгоритмов и программ).
Доход артели делится между участниками артели пропорционально их "карме". Колхозу артель перечисляет только членские взносы. Артель может нанимать исполнительных директоров, менеджеров по продажам, маркетологов и т.д.

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

И у меня вопрос: "Колхоз светлый путь" звучит не слишком кринжово?

[Сергей812]

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

строчек может десяток, но потрачены на них часы (а то и дни) поиска той же информации и пробного тестирования.

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

хм, а для чего тогда столько видов лицензий на ПО...

[nickname2019]

Сообщение от Сергей812 строчек может десяток, но потрачены на них часы (а то и дни) поиска той же информации и пробного тестирования.

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

Сообщение от Сергей812 хм, а для чего тогда столько видов лицензий на ПО...

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

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

Но никто не запрещает выработать свои правила сообщества по аналогии с компьютерной игрой и оперировать условными "строками кода", которые могут быть игровыми деньгами внутри сообщества.

"Колхоз светлый путь" - плохое название?

[Сергей812]

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

сколько строк совместного кода это "профессиональное" сообщество написало за те же последние три года?

[nickname2019]

Сообщение от Сергей812 сколько строк совместного кода это "профессиональное" сообщество написало за те же последние три года?

Примерно 20-30 тысяч. Не знаю, можно ли это считать сообществом, если в нем пока один я.

[Сергей812]

Сообщение от nickname2019 Примерно 20-30 тысяч. Не знаю, можно ли это считать сообществом, если в нем пока один я.

т.е. за эти годы не было не одного реального предложения о совместном создании ПО?

[nickname2019]

Сообщение от Сергей812 т.е. за эти годы не было не одного реального предложения о совместном создании ПО?

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

Сейчас я нахожусь в начале п.3.

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

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

[Сергей812]

Сообщение от nickname2019 Для расчетного ПО нужен скриптовый язык.

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

[nickname2019]

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

А вот это уже сделано до нас.https://oofem.org/doku.php?id=en:download
И этот проект с открытой лицензией.

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

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

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

Мне они не удобны.


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

[Нубий-IV]

Сообщение от nickname2019 Для расчетного ПО нужен скриптовый язык.

Концепция поменялась? Будем писать МКЭ на самодельном скриптовом языке? От этого все, кто говорил в теме "фу, плюсы, я только на питоне буду", разом переучатся и на этот раз все взлетит? Например, нехватку память в nano-x32 язык решает?

Сообщение от nickname2019 "Колхоз светлый путь" - плохое название?

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

[nickname2019]

Сообщение от Нубий-IV Концепция поменялась? Будем писать МКЭ на самодельном скриптовом языке? От этого все, кто говорил в теме "фу, плюсы, я только на питоне буду", разом переучатся и на этот раз все взлетит? Например, нехватку память в nano-x32 язык решает? колхоз наш раньше назывался путь ленина потом никак теперь лень путина назвали чтоб новых букв не покупать (с)тырьнет

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

[Сергей812]

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

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

Сообщение от nickname2019 Мне они не удобны.

а другим?) Или под себя код пишите... тогда причем тут колхозы, артели?

Offtop: p.s. чего то мне это все больше напоминает другого форумчанина, специалиста по XData...

[nickname2019]

Сообщение от Сергей812 а другим?) Или под себя код пишите... тогда причем тут колхозы, артели?

Я думаю, что полезно обсудить, каким образом в идеале должен быть проект с открытым исходным кодом. Я думаю, что в результате обсуждения были высказаны некоторые гипотезы по организации процесса. Некоторые мысли пришли мне в голову буквально позавчера (колхозы и артели), поэтому мне показалось полезным это обсудить (нужно/не нужно).
Я думаю, что эта тема о каких-то перспективных возможных разработках. Если бы это касалось какого то законченного проекта, это, наверное, следовало бы перенести в раздел "Готовые программы".
Публиковать "сырые" разработки я не вижу смысла.
Если когда-то появиться программный каркас, на основе которого можно вести коллективную разработку - я его опубликую.
Опыт гитхабом у меня вышел негативный, так как синхронизация не работала + гитхаб сейчас в любой момент может вынести бан.

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

[Сергей812]

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

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

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

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

[radistMorze]

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

[nickname2019]

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

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

[radistMorze]

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

[nickname2019]

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

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

[Gustavson]

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

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

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

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

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

[nickname2019]

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

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

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

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

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

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

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

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

[radistMorze]

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

[nickname2019]

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

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

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

[veb86]

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

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

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

[nickname2019]

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

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

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

[veb86]

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

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

[nickname2019]

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

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

[veb86]

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

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

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

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

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

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

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