Помимо этого, за счет скриптового режима программа позволяет устраивать презентации и показы. Несложная командная система не требует длительного изучения и освоения. Программу можно освоить за 30-40 минут.
Разработанную программу можно использовать на лабораторных работах студентов, для отображения полученных ими результатов. Она может использоваться сотрудниками институтов или предприятий для отображения результатов моделирования как в процессе программирования и отладки моделирующей программы, так и в процессе демонстрации результатов. Таким образом программа console имеет университетский уровень.
Раздел 2.
Технология разработки программного обеспечения для визуализации инженерных расчетов
Введение
Десять - пятнадцать лет назад ЭВМ либо не имели возможности графического вывода, либо графические дисплеи были очень слабы и не подходили для качественного вывода информации. Печатающие устройства существовали только для символьного вывода. Поэтому все результаты расчетов выводились в виде числовых распечаток, по которым проводился анализ, строились графики и т.д. Пять - десять лет назад графические системы позволяли выводить графики с приемлемым качеством изображения, но только для одномерных случаев. Вывод двухмерных случаев в виде поверхностей требовал огромных вычислительных затрат, с которыми не справлялись процессоры тех лет.
В наше время, когда высокого быстродействия достигли не только ЦП и математические сопроцессоры, но и графические сопроцессоры вывод результатов в графическом виде ускорился в сотни раз, построение трехмерных изображений и их преобразование заметно упростилось. Поэтому для всех современных САПР и инженерных программ необходимо представление результатов в виде графиков, поверхностей и т.д. Как и всякий процесс, написание программ обработки результатов для последующего графического вывода и вывод имеет свою технологию. В данном разделе и будет рассмотрена такая технология.
2.1 Этапы разработки программного обеспечения для визуализации инженерных расчетов.
Для начала выделим основные этапы создания ПО для визуализации инженерных расчетов (далее просто ПО).
1. Постановка задачи. Формирование требований к выводимой информации.
2. Создание структуры данных и интерфейса с рассчитывающими программами.
3. Построение математической модели отображаемой информации (2 подхода):
Использование готовых библиотек OpenGL или DirectX, а также готовых компонент ActiveX.
Построение собственных математических моделей.
4. Создание интерфейса пользователя.
Итак, мы видим пять основных этапов, различных по сложности и объему работ. К тому же, благодаря большому количеству разработчиков библиотек для графического вывода у нас есть два качественно разных подхода.
Рассмотрим каждый этап в отдельности более подробно.
2.2 Постановка задачи
Очень важно правильно сформулировать задачу и требования к ПО. Это поможет избежать лишних затрат на создание ненужных подпрограмм вывода, либо переделки готовых программ для дополнения необходимого. Так же при постановке задачи необходимо решить стоит ли использовать подход с построением собственных математических моделей, или достаточно ограничиться уже готовыми библиотеками и компонентами, пусть и платными. В дополнении необходимо учесть необходимость вывода числовой информации, а так же создание “твердой копии”, т. е. распечатки на принтере.
При определении вида графической информации, нужно решить для каких случаев она будет выводиться - двумерных или же только одномерных. При выборе двумерных случаев у нас тоже есть выбор: можно выводить в виде поверхностей, либо в виде “контрастной заливки”, или же оба этих случая. При постановке задачи на вывод надо учитывать собственные вычислительные ресурсы и необходимую скорость создания приложения.
При определении подхода к построению математической модели вышеуказанные два фактора так же играют главную роль. Собственная модель может обойтись дороже, так как на ее создание уйдет время и, к тому же, как правило, такие модели не задействуют вообще или не на полную мощность возможности графического сопроцессора, а это шаг назад. В связи с этим в последнее время создание собственных математических моделей становится все менее целесообразным и экономически выгодным.
2.3 Создание структуры данных и интерфейса с расчетной программой
Этот этап очень важен. От структуры данных зависит быстродействие создаваемого ПО, компактность кода и файлов, в которых хранятся результаты расчетов.
Интерфейс с рассчитывающей программой может быть совершенно различным. Информация может передаваться через оперативную память (ОЗУ), через файловую систему в виде бинарных файлов или, более объемных, текстовых файлов. Файлы могут быть компрессированы или нет. Какой из способов выбирать зависит от нескольких факторов:
1. Скорость выполнения расчета - если рассчитывающая программа проводит быстрый анализ, то, возможно, целесообразнее не создавать лишних файлов на внешнем носителе и использовать ОЗУ.
2. Частота изменения входных данных - при частой смене входных данных для расчетов намного эффективнее будет применение передачи результатов через ОЗУ, с вызовом программы визуализации как подпрограммы.
По этим двум факторам можно сказать еще следующее: если программа выполняет расчеты долго, или входные данные не меняются (используется итеративный процесс) целесообразней будет использование файловой системы для долгосрочного хранения.
3. Объем передаваемой информации - если объем очень большой, то эффективнее будет хранить его в виде файла.
Выбор вида файла (бинарный или текстовый) зависит от языка программирования. Однако следует учесть, что бинарный файл меньше по объему.
Компрессировать или нет файл с результатами определяется следующим фактором: если вы пишете ПО для большой САПР и программисты, принимающие участие в этом проекте используют одну и ту же подпрограмму компрессии, то в этом случае следует выбрать сжатый файл. Если же вы пишите университетскую программу или программу для предприятия, на которой будут смотреть результаты своих программ инженеры вашего коллектива, то в этом случае, для упрощения процесса написания рассчитывающих программ следует выбрать не сжатые файлы.
В структуру данных также включается управляющая информация для ПО. Она может включать в себя различные параметры как-то: границы массивов данных, значения или шаги по осям, виды представления. При выборе файлового интерфейса ее можно хранить либо отдельно от основных данных, либо вместе с ними. Это уже зависит от вкуса программиста.
2.4 Построение математической модели отображаемой информации.
2.4.1 Использование готовых библиотек
В наше время, как отмечалось выше, большинство разработчиков программного обеспечения, связанного с графикой, используют стандартные библиотеки от крупных производителей программ (Microsoft, Silicon Graphics, 3Dfx). Этими библиотеками являются: OpenGL, DirectX, Direct Draw. Их использование ускоряет процесс разработки программы, к тому же они в полной мере задействуют графический и математический сопроцессоры, что увеличивает производительность. Эти библиотеки включают в себя и аппроксимацию и методы работы с двухмерными и трехмерными объектами, такие как аффинные преобразования и методы скрытия невидимых линий, т. е. Так же исчезает необходимость в затратах на сложный процесс математического моделирования.
Помимо этого, некоторые производители компиляторов поставляют пакеты обработки результатов математического анализа для отображения в графическом виде. Обычно эти пакеты поставляются в виде компонентов ActiveX (для Windows-платформ). Реже поставляются готовые универсальные оболочки. Программы, написанные для них не нуждаются в разработке интерфейса пользователя большой сложности, что, например, для языка Visual Fortran, использующего только WIN32 API, заметно сокращает время и затраты на создание ПО для визуализации. Частным примером такого пакета является рассматриваемый в данной дипломной работе Compaq Array Visualizer (версия 1.5), включающий в себя компоненты ActiveX: Avis2D (для отображения двумерных массивов данных) и AvisGrid (для отображения числовых данных в виде таблицы).
Использование таких компонент и пакетов еще больше ускоряет процесс разработки (хотя, вследствие дороговизны пакетов не дает более экономически выгодных результатов). К преимуществам разработки на готовых универсальных оболочках является стандартизация, т.е. пользователю или инженеру нет необходимости изучать новые программы и их системы интерфейсов и меню. Таким образом, недостающего экономического эффекта можно достигать путем сокращения расходов на обучение персонала.
Негативная сторона заключается в затратах на обучение программистов, а так же в затратах на оболочки визуализации. Помимо этого библиотеки, а тем более оболочки, могут не иметь нужных вам функций (например: неудобно выводить данные в логарифмическом масштабе при использовании Avis2D). Кроме того, для использования данного подхода, так как в этом случае крупные производители ПО не применяют технологию “открытого кода”, практически невозможно учесть ошибки, содержащиеся в коде скомпилированных библиотек и оболочек. Такие ошибки обнаруживаются только в процессе использования программы. Но, по сравнению с исправлением программы с собственной математической моделью, это занимает гораздо меньшее время, так как там ошибки могут содержаться не только в коде, но и в модели.
2.5 Построение собственных математических моделей
При разработке своей математической модели (далее: модели) необходимо учитывать быстродействие машин, на которых должна исполнятся программа. Таким образом можно пропустить некоторые из описанных ниже математических и алгоритмических методов.
Интерполяция.
Результаты вычисляемые рассчитывающей программой представлены в табличном виде. Для сглаживания графиков и поверхностей необходима интерполяция данных. Существует множество алгоритмов и методов интерполяции. Наиболее быстрым и часто применяемым методом является сплайн-интерполяция, которую мы рассмотрим более подробно.
Кусочно-полиномиальная интерполяция заключается в том, что между любыми соседними узлами сетки функция интерполируется кубическим полиномом (кубическая сплайн-интерполяция). Его коэффициенты на каждом интервале определяются из условий сопряжения в узлах:
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
