[nickname2019]

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

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

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

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

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

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

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

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