Содержание к диссертации
Введение
ГЛАВА 1 Методы обработки данных лидарного зондирования атмосферы 8
1.1 Лидарное зондирование атмосферы 8
1.2 Лидарный метод дифференциального поглощения 8
1.3 Методы сглаживания и численного дифференцирования экспериментально измеренных функций 13
1.4 Методы регуляризации 23
ГЛАВА 2 Моделирования, обработки и анализа данных лидарного зондирования атмосферы 33
2.1 Требования к программному обеспечению лидарного зондирования атмосферы 33
2.2 Основные идеи по обеспечению эффективности разработки программного обеспечения в научных исследованиях 36
2.3 Технологии объектно-ориентированного анализа и проектирования 39
2.4 Архитектурные решения и шаблоны проектирования 44
2.5 Интеграция вычислительной подсистемы с подсистемой графического интерфейса пользователя 54
2.6 Сценарии возможных изменений и расширений создаваемого программного обеспечения 58
ГЛАВА 3 Программные комплексы лидарного зондирования атмосферы 61
3.1 Обзор программного обеспечения лидарного зондирования атмосферы 62
3.2 Информационная система ODRIS 68
3.3 Программная система MOLSA 82
Выводы 86
Заключение 88
Литература 90
- Лидарный метод дифференциального поглощения
- Основные идеи по обеспечению эффективности разработки программного обеспечения в научных исследованиях
- Интеграция вычислительной подсистемы с подсистемой графического интерфейса пользователя
- Информационная система ODRIS
Лидарный метод дифференциального поглощения
Концентрация исследуемого газа в методе дифференциального поглощения (МДП) находится из отношения сигналов, полученных на двух длинах волн. Одна длина волны (On) совпадает с центром некоторой линии спектра поглощения газа, где поглощение для данной линии максимально, а друга длина волны вне линии (Off). При этом длины волн должны быть достаточно близки, поэтому обычно вторая длина волны попадает в крыло той же линии поглощения, что и волна On. Схема эксперимента изображена на рис. 1.1. Впервые данный метод был предложен Счетландом, который применил МДП для зондирования водяного пара[17]. К настоящему времени МДП применяется для зонирования многих газовых компонент атмосферы[4]: ОЗ, Н20, N02, S02, NO и др. Определение концентрации газа из лидарных сигналов основано на уравнении лазерной локации. Величину хд (1.5) называют оптической толщей атмосферы. Концентрация зондируемого газа находится из отношения измеренных на двух длинах волн лидарных сигналов. Прежде чем перейти к рассмотрению отношения сигналов перенесем из левой в правую часть значение фонового излучения в уравнении лазерной локации (1.1). Обозначим через N v) разность между лидарным эхосигналом и фоновым излучением (1.6). Запишем отношение лидарных сигналов, полученных в одном сеансе ли-дарного зондирования МДП: Перенося известные составляющие уравнения в правую часть, и логарифмируя обе части, с учетом выражений (1.1-1.6) получим: На практике ВпХ и agam,x задается на основе моделей или сторонних экспериментов; Л д - энергия зондирующих импульсов, известная априорно. Величина фонового излучения определяется либо из дополнительных наблюдений, либо на основе сигналов принятых с высот, где они сильно ослаблены и их существенную долю составляет фоновое излучение атмосферы. В левой части Aks также определяется на основе моделей. Для того, что бы разрешить уравнение (1.10) относительно р его следует продифференцировать. Так как в правой части этого уравнения содержится отношение функций измеренных экспериментально, и, следовательно, с погрешностью, то данная задача является некорректной или некорректно поставленной.
При лидарном зондировании погрешность вносится за счет следующих особенностей эксперимента: незнание точного значения коэффициента дифференциального поглощения, нестабильность частоты излучения, сдвиг центра линии поглощения газа давлением воздуха (особенно для вертикальных трасс), доплеровское уширение линии рэлеевского рассеяния, инерционность ФЭУ, - а так же за счет прочих факторов, не поддающихся точному учету. Ошибку измерений уменьшают путем накопления и усреднения сигнала. То есть при проведении лидарного зондирования производят множество лазерных «выстрелов» (50-60 тысяч), фиксируя каждый раз отклики. Отклики, пришедшие с одной и той же высоты, суммируют, и затем усредняют, уменьшая влияние случайной погрешности. Впервые условия корректности задач сформулировал Ж. Адамар в 1923г. Некоторое время считалось, что приближенное решение задачи, не соответствующей условию устойчивости по Адамару, искать бессмысленно, так как любые малые изменения правой части приводят к большим отклонениям решения, которое, соответственно, не может считаться приближением к точному решению. Тем не менее, во многих областях науки и техники встречаются некорректные задачи, решение которых имеет важное прикладное значение. Поэтому, существует необходимость в создании методов решения некорректно поставленных задач. В настоящее время создано множество методов решения обратной задачи лидарного зондирования, которые можно разделить на два основных класса. Методы первого класса сводятся к численному дифференцированию отношения лидарных сигналов. Для уменьшения влияния погрешности измерения на результаты дифференцирования применяется предварительное сглаживание данных измеренных экспериментально.
В случае лидарного зондирования МДП сглаживают либо ли-дарные эхосигналы, либо величину, стоящую в правой части уравнения (1.10). Сглаживание можно провести, например, методом скользящего среднего. Затем к результату сглаживания применяется какой-либо достаточно простой метод численного дифференцирования. Также возможно провести приближение экспериментальной функции сглаживающим сплайном, а затем дифференцировать полученную аналитическую функцию. Во многих исследованиях, научных статьях, описывается обычно какое-либо одно сочетание. Возникает закономерный вопрос: что произойдет, если применять к одним и тем же исходным данным различные методы или комбинации методов? На этот вопрос мы попытались дать ответ в 1.3, рассмотрев наиболее часто встречаемые численные методы. Второй класс методов направлен на преобразование уравнения (1.10) к интегральному уравнению Фредгольма 1-го рода и последующему его численному решению с учетом некорректности. Тихонов А.Н. впервые сформулировал понятие условной корректности и предложил метод нахождения регуляризованного решения, являющегося, в определенном смысле, приближенным решением исходной задачи. В данной работе, в 1.4, будут описаны два метода относящиеся ко второму кассу, в которых так же используется регуляризация для обеспечения устойчивости решения.
Основные идеи по обеспечению эффективности разработки программного обеспечения в научных исследованиях
Из требований предъявляемых к программному продукту следует, что новое ПО будет более сложным, чем ранее созданное. Как указано в [36]: "Сложность программного обеспечения - отнюдь не случайное его свойство". Это свойство ПО вызывается следующими основными причинами: 1. сложность реальной предметной области; 2. трудностью управления процессом разработки; 3. необходимостью обеспечить гибкость ПО; 4. отсутствием средств описания больших дискретных систем. Следует определить, что является предметной областью в нашем случае. Наша предметная область - комплексные исследования пространственно-временного распределения газовых составляющих и других параметров атмосферы по данным лидарного зондирования.
Таким образом, мы ставим целью не только решение какой-либо одной задачи в области ЛЗА, а именно комплексное исследование с применением традиционных и новых методов и алгоритмов. В области ЛЗА создано множество программных средств, решающих отдельные задачи, но проведение комплексного исследования имеющимися средствами, с помощью разрозненного ПО, будет долгим и трудоемким процессом. В литературе таких исследований встречается не много[37]. По нашему мнению это вызвано именно отсутствием соответствующего программного обеспечения. Сложность выбранной нами предметной области заключается в том, что требуется объединить множество существующих методов и алгоритмов и организовать их применение в рамках одной программной системы с выполнением всех требований, изложенных в 2.1. Соответственно, для преодоления возникающих при этом проблем следует применить новый подход к созданию ПО. Процесс разработки осложнен так же тем, что за время создания системы меняются начальные требования. Следовательно, должна быть предложена архитектура, облегчающая приспособление к изменениям. Для обеспечения гибкости системы необходимо выбрать такие структурные элементы, чтобы построение системы осуществлялось оптимально: быстро, но с возможностью эффективной перестройки. С точки зрения системного подхода [38, 39] это значит, что требуется спроектировать и использовать слабосвязанные структурные элементы, чтобы изменение в одном из них не вызывало волну модификаций в других. Сложность, связанная с описанием больших дискретных систем присуща всем достаточно сложным программным системам. Так как процесс создания ПО слабо автоматизирован, и пока основывается большей частью на труде человека-программиста, вполне вероятны ошибки связанные с ограниченными возможностями человека по обработке информации. Так как конечной целью является создание программного обеспечения, то в большой степени успех зависит от выбора языка программирования. Наилучшей является ситуация, когда для реализации используется какой-либо один язык программирования (ЯП). Но мы в своем выборе ограничены, во-первых, тем, что большинство численных методов обработки данных реализовано на языке Fortran.
Во-вторых, нам необходим язык или среда программирования, позволяющая эффективно строить современный визуальный интерфейс. Современные реализации языка Fortran предоставляют такие возможности, но они сильно отстают по своему составу и эффективности применения от других сред, таких как: MS Visual C++, MS Visual Basic, Borland С Builder, Borland Delphi и др. Положение спасает тот факт, что современные технологии программирования позволяют создавать исполняемые модули на разных ЯП и затем использовать их совместно в рамках единой программной системы. Для обозначения такого способа компоновки ПО применяется термин «смешанное программирование» («mixed language programming»). Выбор ЯП определяет стиль программирования и, соответственно стиль мышления. В [7] выделяются следующие стили (парадигмы) программирования: - процедурно-ориентированный; - объектно-ориентированный; - логико-ориентированный; - ориентированный на правила; - ориентированный на ограничения. Первые два достаточно широко применяются для создания программного обеспечения в различных областях. Остальные для создания специфического круга приложений: баз знаний, экспертных систем. Рассмотрим более подробно процедурный и объектно-ориентированный подходы (ООП). Исторически процедурный подход возник раньше и большинство программистов изначально обучаются именно этому подходу. В процедурном подходе основными смысловыми конструкциями являются алгоритм и процедура его реализующая. Второй подход возник позднее. Многие авторы[7,39,40,41] считают его развитием процедурного подхода. И действительно многие процедурные языки стали подмножествами свои последующих версий с включением средств объектно-ориентированного программирования. Однако основное отличие этих двух парадигм программирования заключается в подходе к анализу и представлению предметной области. В ООП программист оперирует понятиями объектной модели предметной области. Достоинства ООП проявляются именно при построении больших и сложных систем. Часто об ООП говорят лишь в контексте создания приложений с мощным графическим интерфейсом, поддерживаемым современными операционными системами Unix, MS Windows, IBM OS/2 и другими. Это является лишь подтверждением того, что ООП подходит для работы со сложными предметными областями. Современное приложение даже с несложной функциональностью, но использующее графический интерфейс построить сложнее, чем его консольный аналог.
Однако это только один из аспектов применения ООП. Программист имеет возможность использовать не только готовые решения, но и создавать собственные иерархии классов и объектов, являющиеся моделями любой предметной области. Во многих источниках указано[7, 36, 40], что объектный подход позволяет строить программные системы более высокой сложности нежели процедурный. К тому же, при удачном построении иерархии, обеспечивается гибкость системы, возможность адаптации к изменяющимся требованиям. Из анализа литературы [7,40] можно сделать вывод о том, что процедурный и объектно-ориентированный подходы взаимно дополняют друг друга и являются инструментами разных масштабов. Объектно-ориентированный подход это инструмент стратегического масштаба, применяется для принятия и реализации архитектурных решений. Процедурный подход это инструмент тактических решений, связанных с реализацией легко обозримых задач. Итак, первая идея заключается в том, чтобы использовать ООП для создания архитектуры или каркаса программной системы, а для реализации численных методов использовать процедурный подход и соответствующие ЯП. При этом создаваемую систему условно разделим на уровни по степени использования абстракций или сущностей предметной области: уровень, где используются численные методы и процедурный подход, будем называть низким уровнем системы, а уровень где рассматривается общая структура системы и соответствующие решения, основанные на ООП, будем называть высоким уровнем. Естественно, что система может иметь несколько уровней с постепенным переходом от низкого уровня к высокому. Для увязки системы в единое целое применим возможности смешанного программирования (mixed language programming). Предлагаемый принцип позволит нам, с одной стороны, воспользоваться преимуществами ООП при построении сложных систем и, с другой стороны, применить накопленный багаж программного обеспечения и специализированных библиотек для выполнения численных расчетов. Архитектурные решения должны обеспечить минимально возможную взаимосвязь между уровнями создаваемой системы. Изменения в составе применяемых численных методов и алгоритмов не должны оказывать влияния на высокие уровни системы, и наоборот изменения в архитектуре не должны отражаться на уровне численных методов. Таким образом, по нашему мнению, будет достигнута возможность быстрой адаптации системы к изменяющимся требованиям.
Интеграция вычислительной подсистемы с подсистемой графического интерфейса пользователя
Современный графический интерфейс пользователя (ГИП) предоставляет мощные средства представления информации. Этими средствами не следует пренебрегать в научных исследованиях. Особенно при проведении комплексного анализа массивов информации. Большинство современных языков программирования высокого уровня оснащаются стандартными средствами построения ТИП. В своей основе эти средства являются инструментами генерации кода, который затем исправляется и дополняется в соответствии с требованиями. Генерируемый код является объектно-ориентированным. ГИП - является одной из первых областей, в которых были созданы обширные объектно-ориентированные библиотеки программных компонентов. В силу своих концептуальных свойств стандартные объектно-ориентированные иерархии ГИП хорошо интегрируются с подсистемами, реализующими базовую функциональность создаваемых систем. ГИП играет подчиненную роль в создаваемых системах. Приведем модель взаимодействия подсистемы ГИП и вычислительной подсистемы (ВП). Для нашей системы требования ГИП содержатся в п.6-12 требований к системе сформулированные в 2.1. В тоже время и пункты 1-4 связаны с графической подсистемой. Так при проектировании требуется принять решение о том, каким образом осуществляется ввод параметров, как должен быть представлен пользователю алгоритмический список, какие диалоги применять при сохранении и загрузке данных. Класс «Основное окно» - окно, существующее в системе в единственном экземпляре. При создании системы, мы предполагаем использовать многодокументный сценарий приложения. Это означает, что в системе существует одно главное окно и произвольное множество подчиненных окон. Минимизация основного окна вызывает минимизацию подчиненных. То есть основное окно является обрамляющим для подчиненных.
Главное меню программы также располагается в «Основном окне». Класс «Окно проектов» создается только в одном экземпляре. Этот класс отображает список созданных проектов в системе. Для каждого проекта создается древовидный список этапов решения задачи и порождаемых при этом окон: таблицы, графики, параметры. Кроме представления списка этот класс предоставляет доступ к элементам списка для управления подчиненными окнами: восстановление, минимизацию, вызов объектов класса «Ввод параметров» и т.д. «Окно графа алгоритма» - объект создаваемый для каждого экземпляра проекта. Показывает в графическом виде взаимодействие между этапами решения задачи. Также предоставляет возможность активировать определенный этап для изменения параметров и пересчета выходных данных. «Окно таблиц данных» - может иметь несколько экземпляров на каждый этап расчета в зависимости от количества рассчитываемых величин. В данном окне в виде таблицы представляются результаты расчетов на данном этапе. Именно в данном окне реализуются возможности определяемые требованиями 6-10, 12. «Окно диаграмм» - может создаваться произвольное количество экземпляров по требованию пользователя. Отображает данные в графическом виде. Может совмещать данные из разных таблиц и разных проектов. «Окно статистики» - представляет результаты статистической обработки произвольно выбранных из таблиц данных. «Ввод параметров» - окно, предоставляющее возможность изменять параметры данного этапа. Создается по одному экземпляру данного класса на каждый этап. Для обеспечения интеграции вычислительной части в экземплярах классов «Этап» и «Проект» требуется создание полей-ссылок на объекты классов ГИП. Это необходимо для обеспечения автоматического обновления в таблицах и диаграммах. С другой стороны современное приложение с графическим интерфейсом - это событийно управляемая система. Событиями являются: нажатие клавиши, щелчок «мыши», операции перетаскивания. Каждое из событий генерирует сообщение, обрабатываемое приложением. Следовательно, требуется механизм обратной идентификации объектов вычислительной подсистемы через объекты интерфейса. Например, пользователь выделил столбец таблицы для построения диаграммы, значит, требуется создать «Служебный:Узел» для построения диаграммы и присоединения в качестве потомка. Каким образом можно определить, к какому конкретно узлу, какого проекта следует присоединить служебный узел? Либо в оконном классе следует предусмотреть поле-ссылку на узел, либо предусмотреть атрибут, который будет хранить составной ключ, идентифицирующий проект и этап. Этот атрибут должен быть заполнен при создании экземпляра окна. Это, собственно, и называется механизмом обратной идентификации. Также для интеграции подсистем следует предусмотреть специальные типы данных. Например, для хранения составных ключей при отображении данных из нескольких проектов на одной диаграмме. Все множество классов и объектов можно разделить на категории или слои (рис. 2.5). Это предоставляет возможность увидеть систему в новом ракурсе, более обобщенно. На рис. 2.5 слой "А" объединяет классы и объекты графического интерфейса пользователя. Слой "В" -алгоритмический, объединяет классы и объекты, ответственные за организацию процесса поэтапного решения основных задач и обеспечение служебных функций. Слой "С" - слой свободных процедур для численного решения локальных задач. Из рисунка видно, что слои "А" и "С" не взаимодействую друг с другом непосредственно.
То есть слой "В" скрывает или, говоря термином ООП, инкапсулирует детали графического интерфейса от процедур численных расчетов. В слое "В" можно выделить еще два составляющих слоя "В1" и "В2" (рис. 2.5). Слой "В1" - классы для организации правильной последовательности применения численных процедур, то есть, алгоритма решения задачи. К этому слою можно отнести классы «Узел» и «Проект». Слой "В2" объединяет классы, которые обеспечивают универсальное представление данных и параметров в системе, осуществляют передачу данных и параметров в численные процедуры и представление результатов их работы. На данном уровне не принимается в расчет последовательность применения методов (как на уровне "В1"), здесь рассматривается только механизм передачи параметров и возврата ре Первый из возможных сценариев - добавление начальной вершины на граф алгоритма. Это соответствует появлению новой смежной задачи в предметной области, решение которой на определенных этапах совпадает с решением предыдущей задачи. Примером подобной ситуации являются вершины Р7, Ре на рис. 2.1в, и вершины S7, Sg на рис. 2.2в. Эти вершины являются конечными, поэтому вершин потомков у них нет. Для модификации программного обеспечения следует выполнить следующие действия: 3. Добавить в алгоритмический список еще один экземпляр объекта «Узел» с соответствующим номером, и ссылками на узлы предки. Например, для S7 предками являются Si и S4. 4. Добавить объекты реализации. Для вершины S7 существует ее реализация на графе это S7 и некоторое произвольное количество узлов S7, где п=1,2.... Для S7 создаем новый подкласс класса «Этап», назовем его «Новый:Этап». Этот класс наследует базовую функциональность класса «Этап», остается определить реализацию метода _Расчет. Для этого требуется знать ключи для извлечения необходимых данных из «Хранилища». И, соответственно, необходимо наличие свободных процедур для решения локальной задачи. Второй случай: добавление вершины «вразрез». Пусть вершина Sio помещается на граф таким образом, что Si становится потомком новой вершины, a S2 - предком. Для модификации программного обеспечения в этом случае следует выполнить следующие действия: 1.
Добавить в алгоритмический список еще один экземпляр объекта «Узел» с соответствующим номером, и ссылками на узлы предки. 2. Для вершин, у которых новая вершина является предком изменить соответствующую ссылку в коллекции «Предки». 3. Для Sj o создаем новый подкласс класса «Этап», назовем его «Новый:Этап». Реализуем метод _Расчет для вновь созданного подкласса. 4. В зависимости от того, какие данные и с какими ключами помещаются в «Хранилище» на выходе метода Расчет следует внести изменения в программную реализацию вершин-потомков нового узла. Относительно четвертого пункта можно сделать одно замечание. Если на новом этапе расчета данные меняются лишь по значению, но не по типу и помещаются с новым ключом, то на этапах, зависящих от
Информационная система ODRIS
Большие объемы информации и сложность исследуемых процессов предполагает разработку нового программного обеспечения [61, 62]. Такие системы должны стать инструментом для комплексного анализа и получения качественно новых знаний о предмете исследования. Одной из таких систем является созданная нами информационная система (ИС) ODRIS (Ozone Data Reconstruction and Information System). Система разработана в среде Visual Basic 6.0, для операционной системы Windows 95/98/2000 и работает с приемлемой скоростью при следующих ресурсах: процессор с производительностью не ниже Pentium 166, объем памяти 32 Мб, объем дискового пространства для установки без базы данных 15 Мб. ИС ODRIS позволяет проводить накопление, обработку и анализ разнородной экспериментальной информации (данные лазерного и пассивного зондирования, профили газовых компонент и общее содержание, приземные значения метеопараметров и др.) с целью выявления временных и пространственных закономерностей в поведении изучаемых компонент стратосферы.
Новая ИС обеспечивает следующий комплекс возможностей: 1) быстрый и удобный доступ к различным экспериментальным и «обработанным» данным. 2) современные и традиционные методы обработки экспериментальных данных и методами анализа (Фурье-анализ, статистический анализ, пространственно-временной статистический анализ и корреляционный анализ) как первичных, так и вторичных (обработанных) данных (профили озона, температуры, и отношения рассеяния, а также ОС озона и двуокиси азота); 3) создание архивов экспериментальных и «обработанных» данных для комплексного их использования при решении задач геофизической направленности; применение всего набора методов с целью решения достаточно широкого круга, как обратных задач, так и задач геофизического анализа; Основные составные части системы следующие (рис. 3.1): 1. «календарь» - подсистема ввода и выбора из базы данных измеренных или обработанных значений для последующих манипуляций с ними; 2. подсистема обработки выбранной информации; 3. подсистема статистического анализа данных; 4. подсистема составления отчета, печати и графики. Рассмотрим функциональное наполнение каждого из блоков ИС и их взаимодействие. Программа «календарь» представляет собой программу считывания, записи и управления информационными потоками на пути от базы данных до «активного» блока - блока расчета параметров. Настоящая версия ИС содержит простую и наглядную структуру хранения информации об «обработанных» значениях для профиля озона, температуры и отношения рассеяния, об измеренных озонных сигналах, температурных сигналах; аэрозольных сигналах. ИС сохраняет файлы, содержащие параметры, при которых были получены обработанные данные.
В качестве исходных данных, в ИС поступают лидар-ные данные, полученные в Институте Оптики Атмосферы СО РАН с помощью УФ-лидара с передатчиком на длинах волн 308/353 нм и телескопом с диаметром приемного зеркала 1м [63]. Данные л ид арного зондирования представлены в виде текстовых файлов с трехколоночной структурой. В первом столбце расположен номер строба зондирования, во втором и третьем - сигналы в виде числа, полученные в данном стробе от излучения на длинах волн 308 нм и 353 нм соответственно. Кроме того, ИС позволяет использовать при анализе и другие данные: ОС озона, профили N02, температурные профили, профили аэрозольного рассеяния и другие данные в соответствующем формате. Так как данные атмосферных наблюдений зависят от метеорологической обстановки и носят нерегулярный характер, блок «Календарь» обеспечивает наглядное представление временной сетки измерений рис. 3.2а и удобный интерфейс выбора данных для последующей обработки. На рисунке 3.26 показан выбор данных за 1999 год при этом, пользуясь древовидным списком, можно выбирать данные сеансов зондирования за целый год, за отдельные месяцы, за отдельные дни, а также отдельные сеансы зондирования. На рис 3.26 слева - список данных в базе данных, справа - список выбранных пользователем данных для последующей обработки.
Следующим по важности блоком является блок обработки измеренных лидарных сигналов относительно профиля озона, температуры и отношения рассеяния. Основные элементы интерфейса для определения параметров восстановления приведены на рис.3.3. Отдельные части блок-схемы процесса обработки экспериментальных данных рассмотрим более подробно. Определение вертикального профиля озона из лидарных эхо-сигналов, полученных с помощью лидара дифференциального поглощения, сводится к задаче дифференцирования функции (формула из п.1). Последовательность действий для восстановления вертикального распределения озона, температуры, отношения аэрозольного рассеяния из данных эксперимента лидарного зондирования представлена на рис. 3.4а, б, в. Для дифференцирования оптической толщи мы используем разностный метод и метод сплайн-функций [64]. Для предварительной обработки сигналов используется метод скользящего среднего. Внутренняя структура системы построена в соответствии с методом, изложенным в главе 2: изменение параметров на одном из этапов решения задачи приводит к пересчету этапов-потомков. Рассчитанные величины отображаются в виде таблиц и графиков.
