В базу знаний

Рекомендации по оформлению моделей в программном комплексе EULER

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

6 мин чтения

Компьютерные динамические модели многокомпонентных механических систем существенно отличаются от CAD-моделей и FEM-моделей в плане визуальной понятности и возможностей контроля их правильности. Правильность CAD-моделей практически на сто процентов можно проконтролировать по их визуальному представлению на экране компьютера. Визуальное представление FEM-моделей позволяет практически полностью понять их структуру, но для окончательной проверки правильности модели необходимо проконтролировать свойства используемых конечных элементов. Значительно труднее понять устройство и проверить правильность динамических моделей многокомпонентных механических систем. Это связано со следующими основными факторами:

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

Поэтому описание модели сложной механической системы в значительной мере напоминает код на языке программирования, который надо стремиться делать максимально понятным.

 В документе описаны рекомендации по следующим аспектам формирования компьютерной модели:

  • комментарии;
  • именование объектов;
  • структура модели;
  • именование проектов и внешних ссылок;
  • переменные датчики с заданным начальным значением.

Комментарии

Все исходные данные и объекты важные для понимания модели должны иметь собственные комментарии (комментарии объекта), например:
scalar m1 “масса первого тела”=…

При наведении курсора на объект в справочнике проекта всплывает подсказка с комментарием объекта. Использование комментариев объектов позволяет делать короткие имена объектов без потери понятности. Короткие имена удобны для использования в формулах и других объектах.

Именование объектов

Стандартные имена в EULER формируются исходя из типа объекта и его порядкового номера, например: скалярные величины – scalar1, scalar2, scalar3; точки – point1, point2, point3 и т.д. Однако для больших проектов стандартные имена могут вызвать затруднения для понимания модели. Поэтому рекомендуется именовать объекты по смыслу или с привязкой к каким-либо объектам или смыслам. В первую очередь это относится к объектам, которые невозможно увидеть на виде проекта: скаляры (scalar), функции (function), датчики (sensor) и т.д. Их имена логичнее задавать с соответствующими общепринятыми обозначениями, например: масса объекта – m, длина – L, жесткость – k, функция силы – func_F (где func – function), ускорение – a, скорость – v и т.д.

Звенья рекомендуется называть с заглавной буквы и, желательно, кратко: A, B, C, Base, Axle, Hub и т.д.

Шарниры и силовые элементы рекомендуется именовать в соответствии со звеньями, используемыми при задании этой связи, например: шарнир, соединяющий тела A и B – joint_A_B; объект контактного взаимодействия звеньев C и D – cont_C_D.

Имена агрегатов рекомендуется начинать со строчной буквы a, например: aR (где a - assembly).

Для правых и левых объектов модели рекомендуется давать имена с одинаковым корнем и суффиксами _R, _L (где R – right; L – left), например: Hub_R, Hub_L.

В качестве разделителей частей имен (префиксов, суффиксов, корневых обозначений и т.д.) рекомендуется использовать переход от строчных букв к прописным или знак «_». Пример имен для точки A: point_A, pointA, p_A, pA.

В сложных проектах полезно снабжать имена префиксами, отражающими тип объекта. Наиболее часто используемые сокращенные префиксы:
p – точка;
a – агрегат;
p – точка;
func – функция;
j – шарнир.

Структура модели

Рекомендуется разделять модель на блоки по смыслу, по типам объектов или как элементы конструкции, например:
//
// Исходные данные
… формирование основных параметров модели в верхней части проекта, для быстрого доступа к ним
//
// Геометрия
… создание точек, линий, геометрических тел и т.д.
//
// Звенья
… определение входящих в состав модели звеньев
//
// Шарниры и силовые элементы
… формирование шарниров, силовых элементов и вспомогательных объектов
//
// Узел конструкции или агрегат
… формирование объектов, описывающих узел конструкции или вставка агрегата, формирование связей объектов узла или агрегата с остальными объектами проекта
//
// Системы управления и измерения
… формирование алгоритмов управления, изменений механизма, создание датчиков и т.д.
//

Именование проектов и внешних вспомогательных файлов

Файлы эйлеровских проектов имеет смысл называть кратко и емко, по той же логике, что объекты модели – удобнее пользоваться сокращенным названием, а развернутое описание можно поместить в комментарии в самом проекте. Также следует оставлять комментарии внутри файлов с табличными данными tbl и tb2. Там можно оставить информацию о том, при каких параметрах конструкции получены данные, в какой системе координат, указать источник данных. Для аэродинамических коэффициентов обязательно указать точку приведения, ориентацию связанной системы координат, характерные площадь и длину, для которых вычислены коэффициенты.

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

Переменные датчики с начальным значением

Переменные датчики с начальным значением используются для различных целей, но все случаи подразумевают создание нескольких датчиков и других объектов, которым следует давать понятные имена.

  • Переменный датчик с переопределением значения

В этом случае реальное значение переменного датчика в проекте определяется после его декларации с начальным значением. В процессе расчета начальное значение не используется, оно всегда заменяется реальным значением. Переменный датчик с переопределением значения может использоваться при моделировании управляемых объектов. Например:
sensor D = var( D0 );
…
// Объект управления, на вход которого подается значение sName
…
…
// Система управления
…
// формирование сигнала управления по параметрам движения объекта управления
sensor D_1 = …
sensor D_2 = currentValue( D, D_1 );

Все три датчика D, D_1, D_2 всегда имеют одинаковое значение. Если сигнал управления определяется простым выражением, его можно записать непосредственно в параметрах датчика по методу currentValue:
// формирование сигнала управления по параметрам движения объекта управления
sensor D_1 = currentValue( D, … );

  • Переменный датчик с обновляемым значением
Переменный датчик с обновляемым значением может использоваться при задании алгоритма системы управления. Датчику, значение которого используется для обновления, можно присвоить суффикс new:
sensor D = var( D0 );
sensor D_new = … ;
reform reform_update_D = updateSensor( D, D_new );
event event_update_D = reformsBySensor( list( reform_update_D, … ;

  • Переменный датчик, определяемый дифференциальным уравнением
При использовании переменного датчика с методом «производная переменного датчика» для решения дифференциального уравнения (системы ДУ), одинаковое значение имеют датчик, выражающий правую часть ДУ, и датчик «производная переменного датчика».
sensor D = var( D0 );
sensor D_diff = … ;
sensor D_diff1 = diff( D, D_diff );

Если правая часть определяется простым выражением, количество объектов можно сократить:
sensor D = var( D0 );
sensor D_diff = diff( D, … );

В этом же случае можно при помощи объектов «изменение механизма» обновлять значение датчика:
sensor D_new = … ;
reform reform_update_D = updateSensor( D, D_new );
event event_update_D = reformsBySensor( list( reform_update_D, … ;

  • Корень уравнения
При создании датчика по методу «Переменный датчик как корень уравнения» его значение равно значению датчика невязки:
sensor D = var( D0 );
sensor D_root = … ;
sensor D_root1 = diff( D, D_root ).