[nickname2019]

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

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

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

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

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

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

[Нубий-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 через "обертки", на случай, если придется менять математическую библиотеку?