Тут о свободных 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 - определение напряжений в основании

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

Коэффициент динамичности при учете пульсационной составляющей (см. черт.2 СНиП 2.01.07-85*), вообще говоря, вычисляется по следующей зависимости (читайте теорию Барштейна - кстати оригинальный метод расчета на ветровую нагрузку):

Внизу иллюстрации, как вы поняли, приведена таблица значений и графики для трех основных значений логдекремента (0.05- при расчетах на резонанс, 0,15 - расч. ветер - металл, 0,3 - ж/б).
Интеграл неэлементарный, вычисляется в Maxima численно. Демонстрирую, как:

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

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

Об офисах

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

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

ЖЕЛАЕМОЕ И ДЕЙСТВИТЕЛЬНОЕ В МЕТОДЕ КОНЕЧНЫХ ЭЛЕМЕНТОВ

(статья поправлена в некоторых существенных деталях и перестроена структурно)

Лет примерно 10 назад широко обсуждался цикл статей, за авторством кузбасского автора Назарова Д.И.

"СОВРЕМЕННОЕ СОСТОЯНИЕ ГЕОМЕТРИЧЕСКИ НЕЛИНЕЙНОГО КОНЕЧНО-ЭЛЕМЕНТНОГО АНАЛИЗА" и "РУССКАЯ РУЛЕТКА или анализ основных ошибок теории геометрического нелинейного метода конечных элементов"

РУССКАЯ РУЛЕТКА или анализ основных ошибок теории геометрически нелинейного метода конечных элементов

http://www.cad.dp.ua/obzors/stat.php
http://www.cad.dp.ua/obzors/st2r.php

И вот тут - ответ на нее
http://www.cad.dp.ua/obzors/stat-new.php


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

Тут, конечно, ошибку нашли, и ткнули носом, что называется.
На чем вроде, инцидент оказался исчерпанным.

За год до этого, была другая статья, но к сожалению - ни автора, ни название я не припомню. Он тоже слегка наехал на ANSYS (почему то, хотя ничего ровным счетем особенного в этой программе нет, кроме популярности, и удобства - которое было верным на тот момент и относилось к "классической версии". Опять же удобство - по сравнению с чистым Fortran 77, на котором все корячились до этого. К слову, опять же, отвлекаясь - ANSYS поскормнее будет того же Abaqus, а сейчас таки и вообще куча замечательных кодов)

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

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

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

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

Итак, что можно сказать про численные методы, применительно к нелинейным задачам? А равно и про все прочие?
Насколько далеко шагнула наука в деле расчетов за последние 15 лет?

А никуда она не шагнула. Наука вообще перестала влять на умы. Вот есть куча мальчиков-зайчиков, которые носятся со своими "Скадами" и "ансисами", а наука где то там выводит двойные, тройные и криволиненые интегралы, никем уже не воспринимаемые и не понимаемые. Наука вытеснена маркетингом, и что самое удивительное, программы то развиваются на самом деле в гомеопатических дозах, проще говоря - не развиваются. Что и не удивительно, потому что наукой разработчики и продавцы софта - не занимаются (в софтверном бизнесе обычное соотношение затрат - 10% собственно на программы, 90% - на маркетинг и промывание мозгов)

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

Что это дало в целом индустрии? Машины и конструкции стали легче и надежней? Да вот как раз все наоборот - зачастую, тяжелей и ненадежней.


Улучшился массовый уровень проектирования? Да нет- массовый то скорее не улучшился. Кстати самые крутые штуки (типа ракеты Сатурн-5 или Восток и прочее - прочее) были сделаны в эпоху, когда мощность крупного вычислительного центра была сопоставима с каким нибудь смартфоном или типа того (тут я могу ошибаться в цифрах).

В чем прелесть все таки современных методов расчета и моделирования?
В том что практически не надо рыться в Тимошенке и Вольмире, в поисках какой нибудь пластинки, а можно взять и посчитать десяток задач вроде этой пластинки в лоб за пару часов? Кстати Тимошенко то рулит до сих пор, и аналитические методы очень даже рулят - для той же верификации МКЭ, чтобы было с чем сравнивать. Упругая, допустим, задача - работает теорема единственности решения. Не важно в чем - в справочнике или в ANSYS-е.
Отдельно верифицируются крупные задачи, там где может играть роль накопление ошибок округления (везде - все тот же  REAL(8) )

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

Итак, все ли можно посчитать в современном МКЭ пакете или далеко не все?
Далеко не все можно и имеет смысл считать, и во многих случаях формулы рулили и будут рулить всегда, хотя бы потому, что НДС в них - малая часть задачи. Или в конечном итоге нагрузки и условия так нечетко определены, что чего то там моделировать нет просто практического смысла.

Коротко: передачи, что по AGMA, что по ГОСТ. На формулу НДС - несколько десятков коэффициентов, за которыми там НДС теряется. Плюс - нагруженность, условия работы. Все это всегда считалось и будет считаться как много лет назад. Никакие успехи численных методов особо не помогут.

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

Нелинейная устойчивость (решаемо на самом деле относительно легко явными методами http://www.impact-fem.org/ даже например)

ширина раскрытия трещин ЖБ (на опыте при одинаковых с виду перемычках может варьировать на порядок, как тут что то считать точно - не понятно).

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

(статья в режиме правки, уже ближе, но не все)

Новый визард Caelinux 2013

Поясню, что это за зверь, и зачем он нужен. На самом деле это довольно стандартный (и наиболее современный) метод расчета конструкций. Из коммерческих программ такое делается например с помощью FeaCrack
Смысл расчета таков. Напряжения, как известно, конструкцию в общем случае не разрушают. В любой конструкции полно мест, где максимальные напряжения очень большие (теоретически равны бесконечности). Называется это stress singularity. Как можно оценить каким то лимитом бесконечно большое число? Собственно решением этого вопроса занимается механика разрушения, в которой оперируют несколько иными критериями (гуглите КИН, J-интеграл). Смысл этих критериев, если коротко, в одном - материал разрушают не напряжения, а напряжения, осредненные по некоторой области. И разрушают не сразу, а за некоторое количество циклов, пока трещина подрастет до критической величины. Причиной хрупкого разрушения почти всегда являются дефекты. Поэтому дефектоскопия - обычное дело в производстве. Но разрешающая способность методов дефектоскопии не бесконечна, следовательно возможен какой то минимальный дефект. Отсюда проистекает метод проектирования - включить в наиболее вероятное и неблагоприятное место конструкии так называемую эллиптическую трещину. А затем оценить конструкцию с точки зрения механики разрушения. Такой метод достаточно трудоемкий, поэтому в чистом виде его применяют очень не часто - как минимум для ответственных частей самолетов, ядерных реакторов, корпусов подводных лодок и так далее. Более примитивный метод - оценки напряжений, без привлечения аппарата механики разрушения применяется гораздо чаще. Надо правда уметь интерпретировать результаты, а не просто сравнивать полученный максимум (очень чувствительный к качеству сетки) с каким то "пределом текучести". Кстати - пример профессионального анализа напряжений  приведен тут http://calculix.de/fw05lav.html 
PS Для строителей, если таковые будут читать, сразу поясню, что тема хрупкого разрушения (тем более механики разрушения) для них менее актуальна. Большинство строительных конструкций работают в благоприятном циклическом режиме, и будучи нагруженными к тому же значительной постоянной компонентой к хрупкому разрушению не склонный даже с острыми дефектами. Исключение тут - низкие температуры (решается во многом выбором стали) и иногда частные перепады температур (были на практике случаи, когда например, трещина появлялась в нижнем поясе ферм именно у ворот цеха). То есть конечно, как вы знаете - СНиП монтажную сварку (которую невозможно проконтролировать) предает анафеме и рекомендует высокопрочные болты. Но на практике это критично далеко не всегда, и при невысоком уровне номинальных напряжений вполне может работать. 

Обработчик ошибок в функциях OpenOffice Basic

Зачастую написать даже простую функцию, обработав все исключения (типа деления на ноль) бывает непросто. Да, собственно, весь смысл использования Basic теряется, если тратить много времени на отладку и тестирование, это уже не программирование без программирования, чем Basic и ценен.
Особый случай, когда у вас целая таблица из вбитых пользовательских функций, скажем, на 300 значений - кликать OK по окну сообщения об ошибке 300 раз не очень приятное занятие (обычно в таком случае надо вырубать офис аварийно, запускать чистый файл, отключать макросы, потом открывать-править проблемный файл, то что вызвало ошибку, опять включать макросы...
Избежать всего этого геммороя можно только вставив в каждую функцию обработчик ошибок.
Обработчик ошибок вставляется по следующей схеме


Function sample(x)
On Error GoTo ErrorHandler

' .... тут тело функции с вычислениями


sample = чему то

Exit Function
ErrorHandler:
sample ="случилась страшная ..ня"
End Function

Например следующая функция при x=0 автоматически обрабатывает исключение, предотвращая ошибку. При нулевом x выдается текстовое значение "n/a" (само собой в данном случае подразумевается тип Variant для значения функции - то есть в зависимости от контекста может быть числом, текстом и т.д. Если тип переменной не объявляется, то по умолчанию предполагается именно этот универсальный тип)

Function calculatehyp(x)
On Error GoTo ErrorHandler 

calculatehyp=1/x

Exit Function
ErrorHandler:
calculatehyp="n/a"
End Function

Рекурсия в OpenOffice

Самый наверное простой пример - с вычислением факториала
Вот - простая пользовательская функция в несколько строчек

 Function factori(n) 
 If n=0 Then factori=1 
 If n=1 Then factori=1 
 If n>1 Then factori=factori(n-1)*n 
 End Function

Тут следовало бы добавить условие n<=170, потому как на 171 уже вылетает ошибка, в связи с лимитом максимальной величины. Вообще каждую функцию по возможности следует обрамлять обработчиком ошибок, чего тут не сделано.
Другой пример - функция массива, которая в процессе выполнения генерирует другую функцию, а затем вычисляет значение по ней. В данном случае делается это для того, чтобы программа "понимала" формулу, введенную как текстовая строка, как формулу.


 Function TableOfResults( formula As String , LowerPoint As Double, UpperPoint As Double, NumOfValues As Integer)
'Create UserFunction in the New Module
   oBLibs = BasicLibraries
   oBL =  oBLibs.getByName("Standard")

'Text of new Function
Dim TextOfFunction As String

TextOfFunction = "Function results_by_formula(x)" & CHR(10) & "results_by_formula="& Str(formula) & CHR(10) & "End Function" & CHR(10)  

'Write the test of new function into the new module

If oBL.hasByName("New_Module") Then oBL.removeByName("New_Module")

oBL.insertByName("New_Module", TextOfFunction)

Dim ResArray(1 To NumOfValues+1 , 1 To 2) As Double



For i=1 To NumOfValues+1
ResArray(i,1)=LowerPoint+(i-1)*(UpperPoint-LowerPoint)/(NumOfValues)
ResArray(i,2)=results_by_formula(ResArray(i,1))
Next i

TableOfResults=ResArray
End Function 

Функция массива означает то, что при вводе нужно пользоваться сочетанием клавиш CTRL+SHIFT+ENTER. А при последующей правке следует выделить весь диапазон, занятый вычисленными значениями.
Вообще функции массива - это замечательное преимущество OpenOffice Basic перед VBA. Но удобно пользоваться ими далеко не всегда.
<Скачать пример тут>

Basic и об языках программирования для инженера

В этом посте я напишу о Basic и немного остановлюсь на языках программирования.
Начнем с того, что такое Basic и чем он хорош и плох. И нужно ли знать инженеру какие либо языки программирования или нет.
В целом вы можете прочитать о Бэйсик в википедии http://ru.wikipedia.org/wiki/BASIC
Важной вехой развития языка была система http://en.wikipedia.org/wiki/CA-Realizer  В России о ней почти ничего не известно, не получила распространения в свое время. Сейчас интернет несколько повычищен, и даже скрины с нее сложно найти.
Коротко - это была ультра простая и эффективная RAD для Бэйсик, с упором на инженеров. В целом - все как в Visual Basic или Delphi, плюс такие компоненты как построение графиков и так далее. Система 16 битная, сейчас программы на ней едва ли можно использовать нормально.
Популярным и самым известным на все времена был и останется Microsoft Visual Basic, который в конечном итоге CA-Realizer и одолел (то есть сложно сказать - как именно одолел, но последний даже с учетом популярности свернул свое развитие).  Visual Basic также не смотря на популярность прекратил свое существование по причинам общей политики корпорации, которая решила что надо продвигать C# и создала взамен Бэйсик Visual Basic.NET - адскую смесь бэйсика с си-шарпом, которая собственно Бэйсиком не является, а скорее является его антирекламой и антиподом.Частью этой политики является в том числе и продвижение парадигмы ООП - можете погуглить и почитать что это такое и критику на этот счет.
Так какой язык лучше для инженера и нужен ли он вообще?
Коль инженер использует компьютер в повседневной работе - язык программирования всего лишь средство взаимодействия с компьютером, и поэтому конечно знать какой то язык необходимо. Чтобы точнее выразиться, несколько строчек кода в текстовом редакторе, это своего рода интерфейс, который вкупе с copy&paste>correct it позволяет быстро достигать желаемого.
Иногда то что привыкли понимать под интерфейсом (запустить ярлык, открыть файл, нажать кнопочку, потом нажать другую кнопочку) на самом деле менее эффективно, чем все то же самое реализовать несколькими строчками кода.
Человеку выбирая тот или иной язык легко впасть в искушение и выбрать инструмент коммерческий и высокопрофессиональный, но никак не простой. По принципу "так все большие дяди делают".  Не разу я не видел чтобы такой подход приносил кому либо практическую пользу. Для профессиональных коммерческих программ используют разные языки в зависимости от желаемой цели. В целом такой подход "брать пример" - порочен даже не только в вопросе программирования а и во многих областях жизни - грубо говоря если вы слесарь, то вы не будете ориентироваться на образ жизни миллионера. Миллионером вы от этого не станете, а проблемы поимеете. Слесарь ведет собственный образ жизни по своим средствам, получая в конечном итоге не меньше, а то и больше (в каком хотите смысле). Если вы маленькая компания - вы не можете строить бизнес процессы ориентируясь на крупные компании, вы опять же вылетите в трубу.
Язык программирования должен быть максимально прост для вас и понятен, должен быть достаточно популярен чтобы найти справочную информацию и должен быть свободен чтобы (читайте выше про CA-Realizer) не зависеть от глобальной политики крупных компаний, и оставить себе возможность свободного выбора.
К слову, не так мало хороших и открытых языков - скорее почти все.
Языки совместимые с WEB-ом в настоящий момент наиболее хороши, с учетом того что скоро, вполне возможно, локальный софт исчезнет совсем и вся активность переместится в веб и облака.
Basic скорее жив чем мертв. Строго говоря VB.NET - не бэйсик и скорее всего просуществует недолго.  Есть так называемый rapid-q basic и rq-work basic, это такой порт с паскаля на бэйсик, который популярен у французского комьюнити в основном, но это тоже полудохлое направление. Более живым языком похожим на Бэйсик является Паскаль. Не смотря на ликвидацию техасской компании Borland у паскаля есть вполне достойный открытый последователь - Lazarus Free Pascal. Переход с Бэйсика на паскаль не так уж и сложен. Если вы занимаетесь расчетами в электронных таблицах - все еще живы такие языки как VBA и Open Office Basic
про последний применительно к инженерному делу вы можете прочитать статьи по ссылкам

http://myooo.ru/content/view/172/95/

http://myooo.ru/content/view/173/95/

А также посмотреть книги вот тут

http://www.pitonyak.org/

Хороший пример для выбора - Python. Это более сложный и мощный язык, нежели бэйсик, для простых вещей он как правило избыточный. Минус пайтона - некоторая сложность распространения конечных программ, необходимость для пользователя устанавливать сам пайтон и к тому же не всякий еще и сможет запустить его из консоли. То есть пайтон - это такой язык вечных исходников, поэтому лучше всего распространять приложения на нем вместе со всеми библиотеками (что увеличивает вес дистрибутива, но зато делает его работающим "из коробки". Инструментов для создания пользовательского интерфейса к Пайтон много, начиная со стандартного TK, но это далеко не Вижуал Бэйсик по удобству и скорости.
Кроме того существует два рабочих направления python - второй и третий, что создает некоторую сумятицу.

javascript - открытый бразузерный язык, то есть средой его исполнения является веб-браузер. Это язык, обласканный google, наверно не будет лишним скиллом выбрать именно его. К тому же есть возможность писать пользовательские функции для электронных таблиц Google.


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