Блог о программном обеспечении

Зачем оно нужно?
Публиковать для себя разные вещи, чтобы потом не искать их у себя по разным папкам.
И, конечно, - делиться открытой информацией с другими.
Коротко по темам Caelinux - самый инженерный дистрибутив линукс;
CalculiX - мощная программа для расчетов по МКЭ;
OpenOffice Basic - то что легче выучить и затем эффективно использовать
Maxima - символьная математика от Вильяма Шеллтера, профессора Остинского университета. Все прочее - понемногу.

Бывает, спрашивают посоветовать 3Д программу

и немало дискуссий на эту тему на форумах.
Тут речь идет не об открытом программном обеспечении, которое я обычно стараюсь популяризовать, считая это вкладом в движение FSF. Будучи инженером, я понимаю что открытое ПО - лучший выбор для образовательных и научных целей, или для единичных работ (в качестве хобби, например), но для производительного труда на рабочем месте - как правило есть нужда в программах более производительных.
Двое из трех человек в случае дискуссий "что лучше?", начинают наперебой советовать именно тот софт, в котором они лучше разбираются. Но на мой взгляд - такой подход не верен в принципе, потому что потребительское качество того или иного софта сильно зависит от специфики работы, которая в свою очередь может быть очень разной. Бывает, что самый дорогой по цене софт незаменим ничем по качеству. Бывает, что люди покупают нечто дорогое или среднее, а оно на самом деле работает в их задаче еще хуже дешевого - универсальных подходов тут нет, потому что инженерная деятельность очень сложная и многообразная.
Единственной универсальной рекомендацией в данном случае является необходимость тщательно изучить варианты и желательно запросить тот или иной софт в пробную эксплуатацию (как правило, такая возможность представляется). Еще раньше можно очертить круг возможных программ, поставить ряд типичных задач и посмотреть решение у других (например поиском на youtube, где есть примеры всего и на все случаи жизни). Главный критерий почти всегда - возможность быстро менять или дополнять модель в процессе проектирования, быстро решать типовые задачи в своей области и, наконец, когда вы станете продвинутым пользователем или заимеете таковых в штате - возможность относительно создавать новую функциональность по мере надобности. Именно такая возможность способствовала в свое время заслуженной популярности AutoCAD, хотя сейчас заметно некоторое охлаждение инженерного сообщества к таким решениям.
Бывают неожиданные случаи когда интересную программу находишь не там, где следовало бы ожидать.
Тут не очень давно пришлось столкнуться с интересной (не особенно дорогой), на мой взгляд, программой Rhino ("Райно"). Эта программа для Windows (с наличием версий для Mac OS X). Раньше мне приходилось читать про надстройки к ней в этом блоге. То есть, это такой гибрид между арт-анимационным видом софта (3dmax, blender3d, Maya и т.д.) где обычно преобладает геометрия сеточного типа и CAD3D программами типа Inventor и Solidworks (только не feature-based и без сборочной части).
Главное достоинство, котрое я успел оценить - довольно качественная поддержка форматов как сеточных, так и CAD-овых (IGES/STEP вида). Можно загружать модели SolidWorks без конвертации (.sldprt)
Это мне больше всего и понравилось.
К сожалению всех возможностей оценить и описать я не могу, за недостатком времени, можете сами попробовать скачать 90-дневную триал версию и посмотреть. По моим впечатлениям - не смотря на архитектурную ориентацию, там вполне можно создавать и довольно точные и аккуратные (в инженерном смысле построения), а поддержка большого количества разнообразных форматов никогда никому не мешала (для меня это важный косвенный показатель, потому что и в самых навороченных пакетаx функции файлообмена часто бывают сделаны через пень-колоду, да и непросто это - учесть огромное количество логик, на которых базируется каждый формат).
Если у вас есть что про нее сказать - можете откомментировать тут, в блоге, буду рад получить такую информацию.

Отдельно хотел бы прорекламировать веб-сайт российского коллеги

http://webcad.pro/rasch.html

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

Конвекция в Elmer-FEM

Natural Convection in a room with a heater


(Дэвид Остербёрг, Швеция)
Играясь с открытым пакетом Elmer-FEM
Естественная конвекция моделируется через комбинацию решений уравнений теплопереноса и Навье-Стокса. Комната обогревается под окном с мощностью 500 Ватт/кв. м.
Комната отдает тепло через окно и стены (на которых сохраняется температура 0 и 15 градусов по Цельсию, соответственно). Начальная температура в комнате - 20 градусов.
Симуляция происходит в режиме реального времени.

The website of the project can be found at http://www.csc.fi/english/pages/elmer.


Кстати, в свете этого примера, нельзя не упомянуть подобную программу созданную с несколько иной специальной целью - симуляции распространения пламени. Программа открытая, профинансирована американским государством и доступна по ссылке ниже
http://code.google.com/p/fds-smv/
тут - сравнительно недорогая версия адаптированного под российские нормы (методики МЧС) интерфейса к ней: http://pyrosim.ru/

Софт данного типа (Elmer-Fem, fds) не имеет красивых кнопочек и конечно ориентирован на минимально грамотных (в компьютерном и физическом смыслах) пользователей, что не делает его менее точным и полезным.

Другая ссылка (от того же автора). Симуляция волны в http://www.dual.sphysics.org/ более 1000 миллионов частиц. Сравнительно новый и довольно прогрессивный метод, созданный как ни странно с арт-целями. Впрочем надо разделять реальную симуляцию (которая конечно требует прилично ресурсов и времени, и упрощенную в программах типа 3Dmax/Blender3d - картинка получается правдоподобная, ресурсы требуются сравнительно небольшие (можете попробовать сами - youtube уроки в помощь), но численные результаты (которые художников не волнуют) конечно могут быть далеки от реальности.
blender3d.org любим конечно же не только художниками и аниматорами, физики и все желающие довольно часто используют его как платформу для визуализации результатов, посредством python.

Немного на тему размера сетки и анализа результатов

Данный пост навеян темой, помеченной как важная.
Постараюсь сфомулировать свой ответ.
С одной стороны - ответ очевиден. МКЭ - численный метод, для стержневых элементов это разновидность метода перемещений и сетка в общем случае не важна (в некоторых частных случаях - это зависит от математической реализации КЭ и вида задачи), для оболочечных и объемных элементов - чем мельче сетка, тем лучше результат.
Существуют так называемые графики сходимости - в которых по горизонтальной оси откладывают парамер мелкости (например количество элементов) а по вертикальной - требуемый результат (перемещение, напряжение, момент и тд). С измельчением сетки результат ассимтотически стремиться к некоторому конечному числу (исключения - точки сингулярности, где напряжения и моменты - стремяться к бесконечности). Начиная с некоторой мелкости (в зависимости от типа элемента, особенности конструкции, нагрузок и тд) - точность результирующей величины становится достаточной для инженерных целей. Если это верификационная задача и точное значение известно - можно сравнивать с ним. Если точное значение не известно - можно судить по поведению графика, насколько близко он подошел к пределу.
Зависит, как уже было упомянуто - от типа элемента (математической формулировки, которая бывает разной), от градиента рассматриваемой величины в данной области (например если величина меняется резко - сетка нужна мельче). Имея некоторый опыт решения верификационных задач в своей программе, инженер может вполне достоверно судить о достаточности дискретизации.
Сильно мелкая сетка увеличивает время счета - нет смысла сильно мельчить. К тому же любая математическая модель (даже самая подробная) - является приближением к истине, и зачастую требуется лишь оценить результат (сильно детализированные модели очень часто приводят к ошибкам чисто человеческим, из за сложности контроля и оценки результатов).
 Это все - ясно и очевидно.
Далее - ниже, некотрое "лирическое" отступление от темы.
Есть теория упругости и ее уравнения. Уравнения согласно теореме единственности имеют единственное точное решение для каждой величины. Их вы и находите используя МКЭ.
Но помимо точного решения в математической постановке (то есть в том смысле - как точно численный метод решает теоретическую задачу) есть еще такой важный момент- насколько теория упругости далеко отстоит от реальности, то есть насколько точна оценка физически а не математически.
Это уже не имеет отношения к строймеху а скорее к теории того или иного вида конструкций с учетом назначения и условий работы. Тут я не имею в виду, как некоторые могут подумать, задачу в нелинейной постановке - нелинейность тоже по сути одно из теоретических приближений. Имеется в виду то, что вот например - балка посчитана и в ней есть некоторые напряжения. И то, как она шмякнется кому нибудь на голову, грубо говоря. Я хочу особо отметить - что это разные вещи.
С высоты опыта обследований и испытаний - могу вас заверить, что шмякнуться может и 100% правильно посчитанная конструкция без теоретического перенапряжения. И перенапряженная в несколько раз может стоять столетиями. Языком теории множеств - расчет очерчивает совершенно четкую границу безопасности в пространстве переменных. Реальная же граница - размытая и является нечетким множеством в силу вероятностной природы множества параметров, влияющих на безопасность (хотя бы - той же нагрузки или прочностных характеристик, дефектов, подвижек грунтов, вероятности того что монтер в тот вечер выбухает немного больше пива чем обычно и утром с похмелья недокрутит болт по ошибке - и т.д.)
Даже в условиях лабораторных испытаний наличествует некоторый разброс, а уж на практике - тем более. Просто почитайте какую нибудь книжку по авариям, соберите статистику - увидите сами, что случаев разрушения от того что напряжение превысыло допускаемое на сколько то процентов очень немного.
Расчеты, тем не менее нужно стараться выполнять правильно, не смотря на то, что это один из многих факторов, тем не менее он достаточно существенный. Просто следует отделять мух от котлет, чтобы не смешиать чисто математические и теоретические вопросы с практическими.

Возвращаясь к началу темы о размерах КЭ, следовало бы чуть подробней остановиться на специфике расчетов железобетонных конструкций (плит и оболочек).
Железобетонные конструкции расчитываются по нормам на основе так называемого метода предельного равновесия. То есть если вы вспомните картинку из учебника ЖБК в которой показана прямоугольная эпюра напряжений в бетоне с ординатой Rb и напряжение предела текучести в стали с ординатой Rs - вы можете наверно сами понять, что теория упругости там близко не валялась. Тем не менее, расчет производится как правило в упругой постановке, и более того - для ЖБК он не является приближенным (типа как обмануть какие то нелинейности), а - абсолютно точным - с точки зрения допущений того самого метода предельного равновесия.
Если вы помните теорию упругости - там имеется несколько групп уравнений, в том числе и уравнения отвечающие за равновесие (то есть функции внутренних усилий, удовлетворяющих конкретно этим уравнениям образуют множество уравновешивающихся с внешней нагрузкой внутренних усилий). Этого факта (равновесности упругого решения) вполне достаточно для применимости МПР. Другие группы уравнений (те что отвечают за закон Гука) в данном случае просто не важны - по той причине что сами сечения (то есть арматуру и бетон) вы подбираете отдельно уже на основе МПР.
То есть - пока сечения (и предельные моменты) не заданы вами, то МПР имеет формально бесконечно много решений, причем линейное решение - один из частных случаев (его даже используют иногда не напрямую а с дополнительной процедурой так называемого "выравнивания моментов"). И если бы линейный расчет там использовался как приближенный к нелинейному - вы бы как минимум должны были бы задавать изначально сечения с арматурой и не задавать всякого рода "коэффициенты" к модулю упругости - а высчитывать его в результате сложных процедур в зависимости от стадии деформирования.
Тут нужно добавить еще, что
1) МПР работает только в предельной (по первой группе) стадии, то есть когда образуется достаточное количество пластических шарниров - моменты в них принимают те значения, которые вы сами назначили.
2) Линейный расчет как разновидность МПР -  не годится (строго говоря) для "расчета при обследовании" - то есть когда вам надо проверить уже назначенные сечения.
3) Вторая группа предельных состояний при линейном расчете - это действительно приближенное решение, и линейный расчет тут используется для приближенной оценки, но не как точный метод.
Если вы даже сделаете нелинейный расчет - в предельной стадии вы получите тот же самый результат что и по МПР.
Поэтому, ввиду условности линейного решения для расчета жбк, волноваться о сетке там можно гораздо меньше чем в случае например стальных конструкций, где "задать арматуру" нельзя. Любая разумная степень дискретизации жб плит дает вам систему уравновешенных усилий в любом случае. Полученные в результате расчета внутренние усилия могут рассматриваться как осредненные на заданное полосе, как если бы вы делали это осреднение для более мелкой сетки (замечу, что для армирования результаты всегда осредняют - смотрите например пособия к МикроФе, одной из лучших программ для железобетонщиков). Осреднение - вполне законный и грамотный способ экономить арматуру, а "запасы" по арматуре для жбк иногда прямо противоположны благим намерениям - переармированное сечение разрушается хрупко, с меньшими предельными деформациями, а это кстати тоже одно из условия применимости МПР к расчету.

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