Орловский государственный технический университет
ПРИНЦИПЫ ПОСТРОЕНИЯ ГРАФИЧЕСКОГО РЕДАКТОРА CAD/CAE-ПРОЦЕССОРА ДЛЯ ПРОЕКТИРОВАНИЯ РОТОРНЫХ СИСТЕМ
Долгов Е.П., Иванов Д.А., студенты,
Соломин О.В., к.т.н., докторант
г. Орел
Актуальность решения задач динамики роторных систем на сегодняшний день обусловлена многими факторами. К ним можно отнести: бурное развитие технологий, связанных с высокими оборотами вращения деталей (приводы CD-ROM, НЖМД, гидротурбины электростанций и т.д.), уникальность конструкторских решений, относящихся к данной предметной области, итерационный характер проектирования деталей. В связи с этим на передний план выступают компьютерные средства моделирования - CAD/CAE-процессоры, призванные автоматизировать процесс разработки и внедрения роторных систем.
В настоящее время конструкторам предоставлен широкий спектр пакетов прикладных программ для моделирования и расчета роторных систем. К ним можно отнести ANSYS, NASTRAN, COSMOS/M, APM WinMachine, AutoCAD. Однако стоит отметить, что данные программы предназначены для решения широкого круга задач и не имеют четкой предметно ориентированной направленности. Некоторые из них позволяют в полном объеме учесть все аспекты моделируемой области, однако это оказывается сопряженным с большими временными затратами на разработку и расчет полученной модели.
«Легкие» пакеты программ лишены вышеуказанных недостатков, но удобство их использования напрямую связано с ослаблением функциональности. Так, например, пакет DyRoBeS предназначен для всестороннего анализа многоопорных роторных систем, но в то же время не позволяет смоделировать турбоагрегаты [3].
Таким образом можно говорить об отсутствии на рынке полноценных CAD/CAE-систем, ориентированных исключительно на решение динамики роторных систем. Основными составляющими такой системы являются графическое ядро (редактор), совмещающий в себе функции пре- и постпроцессора, и непосредственно сам процессор - модуль, производящий вычисления относительно созданной модели.
Исходя из вышесказанного, сформулируем основные требования к CAD/CAE-системе для решения задач динамики роторов. Учтем тот факт, что поиск решения в большинстве случаев осуществляется путем пересмотра параметров существующих роторных систем, а не конструирования «с нуля».
1) Простота создания модели роторной системы. Время, затрачиваемое на создание в программе узла произвольной сложности, должно измеряться несколькими часами.
2) Возможность импорта и экспорта данных для обеспечения совместимости с существующими пакетами.
3) Поддержка сетевого взаимодействия с целью создания эффективной распределенной системы для конструирования и расчета.
4) Наличие обширной библиотеки (базы данных) стандартных деталей, с возможностью последующей их модификации и пополнения базы.
5) Легкая расширяемость как со стороны графической, так и расчетной подсистемы. В системе должны быть заложены механизмы, позволяющие усложнять как трехмерные графические модели, так и алгоритмы их расчета.
Характерным для всех машиностроительных систем является центральное положение подсистемы машинной графики и геометрического моделирования (специализированного графического редактора). Основными процедурами проектирования в данном случае являются определение пространственных форм, взаимного расположения объектов и их негеометрических параметров [1].
В системе вместо проектируемого объекта используется его модель, отражающая интересующие конструктора свойства объекта. Очевидно, что выбор способа представления данных (модели) во многом определяет мощность всей системы. Среди множества представлений остановимся на двух. Первый - задание граничных элементов модели - граней, ребер, вершин. Он достаточно просто реализуется при помощи графической библиотеки OpenGL [2], но обладает существенными недостатками - громоздкостью представления и отсутствием какой-либо системы в указании элементов.
Второй - метод конструктивной геометрии. В данном случае модель представляется в виде совокупности базовых элементов и выполняемых над ними теоретико-множественных операций (чаще всего ограничиваются тремя - объединение, пересечение и разность). Это представление наиболее подходит для представления в ЭВМ, поскольку легко реализуется как описание на специальном языке, структура связанных объектов небольшого числа заранее определенных классов или же в виде концептуальной схемы базы данных.
Использование метода конструктивной геометрии сопряжено с преобразованием данных, если в качестве базовых элементов выбраны примитивы, отличные от воспроизводимых графической системой ПК. Задача преобразования, а также проведения операций над объектами выполняется отдельной подсистемой графического редактора - геометрическим конвейером. К его функциям относят [1]:
- преобразование графических объектов;
- представление (развертка) линий в растровой форме;
- выделение окна;
- удаление скрытых линий;
- закраска изображения.
Преобразование осуществляется с помощью операций масштабирования, поворота и переноса. Для всех операций определена матричная форма, которая и реализуется аппаратно средствами OpenGL. Представление графических объектов в растровой форме необходимо для выведения их на битовую карту видеосистемы (пиксели видеомонитора). Удаление скрытых от наблюдателя линий производится алгоритмом z-буферизации. Основная его идея заключается в присвоении пикселям картины на экране монитора третьей координаты, которая определяет удаление точки от глаза наблюдателя.
Пока речь шла о многогранных объектах. В общем же случае они могут представлять собой и достаточно гладкие пространственные формы. В этом случае удобно прибегнуть к использованию NURBS-тел (аппроксимация B-сплайнами). Их внутреннее представление укладывается в метод конструктивной геометрии (объект с вектором параметров), а реализация осуществляется посредством библиотеки OpenGL.
Для связи графического ядра системы (CAD) и расчетного модуля (CAE) удобно применять внутренний язык заданий. Это позволяет, во-первых, производить параметризацию, т.е. существенно снизить долю участия инженера (конструктора) в процессе моделирования, а во-вторых, использовать внешние по отношению к графическому редактору расчетные модули при знании семантики языка модуля и наличия транслирующего узла.
Во внутреннем языке заданий должны задаваться объекты расчета, ассоциируемые с ним параметры, алгоритмы расчета или ссылки на них, а также само задание. На этом же языке должна осуществляться и обратная связь между процессором и постпроцессором. Здесь же должна быть определена семантика передаваемых данных, поскольку в результате расчета получается набор дискретных чисел.
Рассмотрев все основные подсистемы графического редактора, мы можем представить его функциональную структуру (рисунок 1). На рисунке также выделен модуль логики диалога, ответственный за согласование действия всех подсистем, а также оконная подсистема, основанная на формах операционной системы и организующая взаимодействие редактора с пользователем.
Существенным является и организация канала передачи данных между подсистемами. Это может быть как файловая пакетная передача, так и обмен через сетевые протоколы. Последний способ является предпочтительным, поскольку позволяет организовывать рабочие группы пользователей, либо же кластерные системы для CAE-систем.
Рисунок 1 Функциональная структура графического редактора
графический редактор роторный программа
Завершающим звеном в разработке графического редактора является постпроцессор. В его задачи входит отображение двумерных данных (графиков, диаграмм, траекторий и т.п.) и трехмерное моделирование (отображение изменения состояния модели во времени, выделение особых зон модели, трансформация и т.п.).
Литература
1. Норенков И.П. Основы автоматизированного проектирования: Учеб. Для вузов. 2-е изд., перераб. и доп. М.: Изд-во МГТУ им. Н.Э.Баумана, 2002. 336 с.
2. Мейсон Ву, Том Девис, Джеки Нейдер, Дейв Шрайнер OpenGL. Официальное руководство программиста. М:Диасофт., 2002 г. 592 с.
3. www.rodyn.com