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

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

Об анализе результатов при расчете объемными и оболочечными элементами

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












Открытые программы как я уже писал выше - хороши для обучения. В них работать конечно помедленней, но зато есть возможность понять откуда и как получается результат, повозиться с разными типами элементов и с разными сетками. Кстати - немаловажные знания о принципе работы консольных программ и библиотек, на уровне компьютерной грамотности образца середины 90х, добавляют немало к unix-way в познании предмета.
В конечном итоге программа - сколько бы она не стоила, думать за человека не будет, и такой момент как корректное приложение граничных условий требует специфичных знаний, потому что на самом деле в МКЭ нет никаких "балок" и "опор", а все это должен задавать пользователь, который имеет представление о сути расчетных методов.
Но все таки кроме собственно расчета и получения напряжений есть еще такой момент как анализ результатов. Казалось бы, чего проще? Получил напряжения и сравнил с допускаемыми. Такой подход работает в нормативных документах, но там он применим к так называемым "номинальным" напряжениям, то есть F/A или M/W (последние называются еще "фибровыми" - fiber stress) а по МКЭ получаются напряжения локальные, с учетом многочисленных концентраторов, поэтому максимальные напряжения даже для малонагруженной конструкции как правило велики и легко превышают значение предела текучести.
Тут стоить заметить, что анализ напряжений зависит от вида конструкции и режима ее работы (строительная ферма - это одно, а подкрановая балка тяжелого режима работы - другое). Есть многочисленные методики расчета на усталость (то есть до возникновения трещины после определенного количества циклов) и есть методики механики разрушения.
Просто знать напряжения - не значит ничего, нужно уметь их правильно анализировать.



Бывает, спрашивают посоветовать 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) Вторая группа предельных состояний при линейном расчете - это действительно приближенное решение, и линейный расчет тут используется для приближенной оценки, но не как точный метод.
Если вы даже сделаете нелинейный расчет - в предельной стадии вы получите тот же самый результат что и по МПР.
Поэтому, ввиду условности линейного решения для расчета жбк, волноваться о сетке там можно гораздо меньше чем в случае например стальных конструкций, где "задать арматуру" нельзя. Любая разумная степень дискретизации жб плит дает вам систему уравновешенных усилий в любом случае. Полученные в результате расчета внутренние усилия могут рассматриваться как осредненные на заданное полосе, как если бы вы делали это осреднение для более мелкой сетки (замечу, что для армирования результаты всегда осредняют - смотрите например пособия к МикроФе, одной из лучших программ для железобетонщиков). Осреднение - вполне законный и грамотный способ экономить арматуру, а "запасы" по арматуре для жбк иногда прямо противоположны благим намерениям - переармированное сечение разрушается хрупко, с меньшими предельными деформациями, а это кстати тоже одно из условия применимости МПР к расчету.

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

Pro-Cast как пример специализированного софта.

Хороший пример специализированного софта в очень важной отрасли, такой как литье:
 

  
То есть, решать такого плана задачи можно конечно и мультифизичными программами общего назначения типа Abaqus, Cosmol, ANSYS и даже, допустим, для открытого софта вроде CalculiX или Elmer-FEM такие задачи вполне посильны (эйлерова жидкость, сопряженная термо-механика). Но практически конечно же делать это сложно - в любом случае потребуется специальная подготовка,
одни только физические характеристики расплавов не понятно где брать (это очень дорогие и сложные эксперименты). В данном случае - все в одном флаконе, и конечно же такой софт на соответствующем производстве незаменим.
 Плюс такие вещи, как прогнозирование дефектов и т.д. В точности также для грунтов используется Plaxis и т.д. - узкоспециальный софт, тщательно подогнанный под конкретные технические задачи всегда имеет преимущество над общим.

До кучи про Procast и аналоги ("Полигонсофт", LVMFlow)


Тут о свободных CAD-ах

Попробую провести некоторый обзор свободных CAD программ.
Сначала список
1) Salome http://www.salome-platform.org/
2) Freecad http://sourceforge.net/projects/free-cad/
3) gcad3d http://www.gcad3d.org/
4) SolveSpace http://solvespace.com/index.pl

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

Но тем не менее, открытые CAD программы представляют определенный интерес и попробую объяснить - какой.
Тут еще также стоит заметить, почему в список выше не включен blender3d
(http://www.blender.org/ ). Это в большей мере профессиональный софт по своему назначению (особенно с последних версий), и служит он конечно же для построения 3d моделей, но это не для инженеров а для арта и форматы геометрии там - сеточные и сплайновые, особой точности в общем случае не предполагают, принципы немного иные, и для инженеров не очень полезны (хотя можете погуглить blendercad, типа тут http://www.cad4arch.com/cadtools/).
Под CADом я буду понимать 3D программы, оперирующие с форматами типа STEP/IGES, в обе стороны (т.е. с сохранением). Важный момент - потому что многие препроцессоры МКЭ программ (в том числе GMSH, NETGEN, CalculiX CGX) - геометрию тоже строят, но ориентированы на построение расчетных сеток, и, хотя могут читать STEP, но обратно его не пишут.

Salome - наиболее мощный (по совокупности возможностей но не по удобству) инженерный пакет, исторический прародитель наиболее мощных коммерческих САПР, типа Catia, в принципе тоже является в большей мере препроцессором, но имеет очень функциональный геометрический модуль, основанный на ядре OpenCascade.
Под Windows существует экспериментальная сборка, не очень удачная,
самый наверно лучший способ опробовать Salome - в составе дистрибутива caelinux. Дает возможность строить параметрические модели, как посредством пользовательского интерфейса (через определение параметров), так и через запись и корректировку пайтон скриптов.При этом при выполнении определенного действия в дереве появляется соответствующая feature, но изменить ее непосредственно из интерфейса - нельзя, нужно перегружать скрипт.
В чем преимущества и недостатки скриптовой паратеризации по сравнению с feature based. Преимущество - в гибкости. Например - у вас есть тело с отверстиями. В скрипте вы можете прописать не только параметры вроде диаметра или привязки, но и поменять количество отверстий и принцип по которому они привязаны к телу. Недостаток в том, что нужно работать с командным скриптом, перезапускать его несколько раз в процессе написания, для того чтобы убедиться, что он работает правильно.
Salome имеет достаточно бедные интерактивные возможности - нельзя практически ничего произвольно начертить на экране, задать изменяемые размеры - все приходится вводить вручную через координаты.
Строить таким образом сложные модели гораздо трудозатратней, чем например в SolidWorks, но для типовых моделей в массовом производстве параметризация очень удобна (можете например построить вал, шестерню, фланец - и так далее и затем генерировать ее автоматом просто поменяв параметры).
Еще одна существенная особенность, важная именно для последующего использования в расчетах - в отличие от программ типа SolidWorks у пользователя есть возможность полностью контролировать отдельные примитивы (типа поверхностей, точек, линий и т.д.), что позволяет во многих случаях подготовить геометрию для нанесения автоматической сетки с определенными свойствами. Это в некотором роде CAD пакет "классического типа", в котором вы полностью контролируете геометрию на элементарном уровне и соответственно можете ей (при наличии опыта) должным образом управлять. Ближайший аналог Salome - это препроцессор классической версии ANSYS.

Free-cad - базируется на том же ядре, что и Salome, и таже имеет скриптовые возможности на том же принципе (python) плюс зачаточные возможности feature-based параметризации. То есть можно выделить любую поверхность существующего тела и нарисовать на ней произвольный эскиз (с параметрическими изменяемыми размерами). Далее, соотвтетственно - сделать вытяжку или рез согласно этого эксиза.
На сегодняшний день (версия 0.13) в эскизной части не поддерживаются сплайны, также хромает экспорт dxf фигур в эскиз (либо невозможно, как в случае сплайнов, либо надо много дорабатывать ручками).
Отдельно от эскизного существует draft модуль - с обычным черчением на плоскости и образмериванием.Отдельно от draft - Drawing модуль, в котором можно создать произвольную проекцию построенного тела на плоскость (правда сохранить в dxf напрямую нельзя, экспорт выполняется через svg формат, который нужно переоткрывать и сохранять в Inkscape)
Сборочный модуль пока находится в стадии тестирования (в бета версии),
тем не менее отдельные функции точной сборки доступны через привязки Draft http://youtu.be/lfinO3EGXeo )
В целом конечно Freecad-у далеко до современного полнофункционального пакета, но для простых вещей он работает не хуже солидворкса, и сохраняет пока преимущества скриптовых возможностей, описанные выше для Salome.
(Совсем ничего не написал про архитектурный модуль - можете погуглить или сами попробовать).
Упор на "массового пользователя" в развитии Free-cad имеет и некоторые недостатки - нарушается unix-way (делай отдельный модуль для определенной цели, но делай его хорошо), программа стремительно растет в размерах при этом переполняясь какими то второстепенными (или даже совсем убогими) фичами, которые к тому же и не работают толком. Но, поскольку программа все таки свободная - ничего не мешает существовать ее кастомным вариантам сборки, которые подчищены от несуществующих функций, сохраняя все преимущества существенных.

Наконец - две последние программы в списке, совсем не большие, написанные одним человеком, gCAD3D - с упором на скрипты (построение поверхностей) и SolveSpace - с упором на интерфейс (в линукс работает через wine), основной их минус в том, что сохраняемые STEP файлы записываются не корректно, и открываются не везде (в отличие от OpenCascade-based программ, в которых эта функция разработана на хорошем уровне).


Зависимость натяжения вант от температуры

Относительное изменение хорды оттяжки ε=ΔL/L связано с напряжением уравнением нити:

где P=p/A, Н/м^3 – поперечная нагрузка, Н/м, отнесенная к площади А, м^2; индекс "0" относится к величинам исходного состояния.
Примем за исходное состояние – состояние при температуре t и обозначим Δt=t-t0. При изменении температуры ствол деформируется на величину α·Δt, что повлечет за собой изменение длины оттяжки на ΔL = α·Δt·(sinβ)^2, где β – угол наклона оттяжки к горизонту. С изменением температуры поперечная нагрузка (собственный вес) не меняется, поэтому можно принять:
P = P0 = γ = g·cosβ /A,
где g – погонный вес, Н/м; А – площадь ванты.
Подставляя указанные величины в уравнение нити и производя преобразования, получаем разрешающее уравнение, позволяющее скорректировать напряжение с учетом изменения температуры:
или
где
Действительный корень уравнения определяется формулой:
Определив из уравнения величину напряжения при заданном перепаде температур определяем как обычно - умножением напряжения на площадь.
Указанная методика рекомендована в книге
Petersen, Chr. (1970): Guyed masts and chimneys, Verlag Ernst & Sohn, Berlin-München-Düsseldorf, Germany.
Ниже приведен код пользовательской функции для OOo Calc

Function otemp(T, T0, N0, A, g, E, L, beta, h)
' Возвращает тяжение стальной оттяжки мачты, тс, при заданной темературе T
'Описание величин
't = Заданная температура
'T0 - Начальная температура (среднегодовая температура воздуха)
'N0 - Начальное тяжение ванты, тс, при температуре T0
'A = Площадь оттяжки, мм2
'g = Погонный вес отттяжки, кгс/м
'E = Модуль Юнга оттяжки, кгс/см2
'L = Длина оттяжки, м
'beta = Угол наклона оттяжки к горизонту в градусах
'h = Высота ствола под оттяжкой
'Переобозначение переменных и перевод всех величин в систему кгс, см, рад.

N0=N0*1000
A=A/100
g=g/100
L=L*100
beta = beta*3.1416/180
h=h*100

alpha = 0.000012
Gamma = g * Cos(beta) / A
Delta = t - T0
s0 = N0 / A
C = Gamma ^ 2 * L ^ 2 * E / (24 * s0 ^ 3)
B = (1 - C - alpha * Delta * E * (1 - (h / L) * Sin(beta)) / s0)
z = 1 / 6 * (108 * C + 8 * B ^ 3 + 12 * Sqr(81 * C ^ 2 + 12 * C * B ^ 3)) ^ (1 / 3) + 2 / 3 * B ^ 2 / ((108 * C + 8 * B ^ 3 + 12 * Sqr(81 * C ^ 2 + 12 * C * B ^ 3)) ^ (1 / 3)) + 1 / 3 * B
'Искомое усилия тяжения в тс
N = z * s0 * A / 1000
otemp = N
End Function

Пример использования функции:

Maxima - определение напряжений в основании


[Напряжение.PNG]

Maxima и СНиП Нагрузки и Воздействия

Коэффициент динамичности при учете пульсационной составляющей (см. черт.2 СНиП 2.01.07-85*), вообще говоря, вычисляется по следующей зависимости (читайте теорию Барштейна - кстати оригинальный метод расчета на ветровую нагрузку):
[kdyn.PNG]
Внизу иллюстрации, как вы поняли, приведена таблица значений и графики для трех основных значений логдекремента (0.05- при расчетах на резонанс, 0,15 - расч. ветер - металл, 0,3 - ж/б).
Интеграл неэлементарный, вычисляется в Maxima численно. Демонстрирую, как:

[kdyn2-maxima.PNG]

Немного о математической оптимизации в инженерном деле...

Когда занимаешься деланием чего то, и имея некоторые исходные данные создаешь определенный продукт, рано или поздно встает вопрос об оптимизации. Вопрос об оптимизации очень неоднозначный.
Есть некоторые основные положения, которые можно сформулировать.
1) Математическая оптимизация как правило не нужна. Некоторые расчетные программы тем не менее имеют соответствующий модуль и ценят его высоко (чуть ли ни следующий уровень по цене). Почему это не нужно? Ну вот например я делаю вырезы в швеллере, чтобы облегчить вес. Простейшая, сравнительно легко решаемая задача для ANSYS. Но тут есть два момента - во первых оптимальное решение от исходного (типа нарисуй  те дыры навскидку) отличается процентов на 10-15. Это вообще типичная величина выгоды для математической оптимизации по сравнению со стандартным решением. Во вторых чтобы сэкономить этот десяток килограмм придется потратить цену раз в 10 большую чтобы просто вырезать их аккуратно.Таким образом подобная оптимизация если где то и нужна - то только в массовом производстве. Да и в массовом - в большинстве случаев имеет значение унификация, стандартизация, использование роботов в производстве и сокращение затрат на монтаж - то есть формальный оптимум по весу как правило очень далеко.
2) что оптимизировать - вес или деньги? Конечно как бы деньги и имеет смысл оптимизировать. Но деньги складываются из затрат труда и стоимости материалов. Затраты труда на практике пронормировать очень сложно. Можно только укрупненно и приблизительно.
3) критериев оптимизации как правило много. Потому что любой дизайн - нечеткое множество состояний. Так например оптимально, но неудобно по конструктивным соображением. Или например, нечто - уменьшает вес, но понижает живучесть в целом, если что то случиться.То есть не просто критериев много - но и формализовать их тоже сложно. Наконец даже чисто математически - оптимальная конструкция такова, что в ней напряжения распределены равномерно. То есть уже любой участок являясь напряженным - становится потенциальным слабым звеном - достаточно отклонения или дефекта в каком то одном месте, чтобы получить возможную проблему.
Я будучи студентом довольно много научных трудов и теорий читал по оптимизации, и насколько могу понимать - для научного работника это идеальный тип проблемы, которую можно решить. И вроде бы - практическая значимость обеспечивается по определению. Но к сожалению - все это не так, и если даже оптимизация чего либо и происходит - то научные труды нужны как раз меньше всего.
4) Говоря об оптимизации невозможно не отметить так называемую топологическую оптимизацию. То есть когда берется бесформенный кусок материала, прикладывается нагрузка и алгоритм, шаг за шагом просчитывая конструкцию, удаляет материал из слабонапряженных мест.
Такой вид оптимизации реализован в ANSYS Design Space, для плоских случаев можно использовать открытую (гениальную по простоте) программу
http://forcepad.sourceforge.net/
Опять же с практической точки зрения это в большинстве случаев бесполезно, потому что формообразование в индустрии (кроме может быть литья, да и то с большими оговорками) не таково, что взял и слепил что хочешь.




Об офисах


Говоря о разных офисах, на первое место конечно ставят Майкрософт Офис.
Вообще его старые версии мне очень нравятся. Я постоянно порываюсь купить, но увы - он по большому счету мне просто не нужен и даже даром.
Новые версии - слишком избыточно. То есть далеко до профессиональной системы, но слишком сложно для программы набора текста с картинками и таблицами.
Семейство открытых офисов - да, начиная со второй версии в них стало можно работать (особенно если пользоваться родным форматом). Да и сейчас их целых два и тоже неплохи сами по себе.
Есть еще такая легкая и минималистичная штука как Abi.
Инженеру нужно что то с рамками - конечно тут как минимум Опен Офис.
Наконец - Google Docs - тоже прекрасно и минималистично. Для студента например - лучше не придумаешь. Формулы набираются, таблицы вставляются, символы все под рукой.

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