% Created on 02-jan-92 by BGV
%-------------------------------------------------------------------
\documentstyle[12pt,russian,epsf]{iheprep}
\textwidth=6in
\textheight=8.5in
%\textwidth=160mm
\newcommand{\omg}{$ \omega\omega$}
\newcommand{\omgomg}{ $ \pi^-p\rightarrow\omega\omega n$}
\newcommand{\threepi}{\pi^+\pi^-\pi^0}
\begin{document}
\begin{titlepage}
\prepnum{92-xx} { ОЭИУНК }
\author{% Список авторов.
Г.В.~Борисов
}
\title{ Система обработки данных установки ВЕС. \\
I. Структурное построение.}
\bigskip
\end{titlepage}
%
\begin{abstractpage}[xxx.xx]
\engabs{Borisov G.V.}{ Data processing on VES}
Description of data processing on IHEP Vertex Spectrometer is
presented. In the first part of this work the structure of VES
data processing is given, including description of the parallel
processing of events on many computers simultanuosly. Some
principal points of construction of the system of data processing
are also given.
\rusabs{Борисов Г.В.} { Система обработки данных установки ВЕС}
Представлена система обработки данных установки ВЕС. В первой части
описывается структурное построение системы обработки ВЕС. Особое
внимание уделено параллельной обработке событий на многих ЭВМ.
Рассмотрeны также некоторые принципы построения системы обработки.
\end{abstractpage}
\subsection*{ 1. Введение.}
Современный эксперимент в физике высоких энергий невозможен без развитого программного обеспечения
обработки данных (ПООД), создание которого можно выделить в самостоятельную
задачу. Ее сложность и трудоемкость определяется, прежде всего, самим
экспериментом, в котором решаются немыслимые в недалеком прошлом задачи, используются все более
изощренные приборы, участвуют большие коллаборации ученых из разных стран.
Реконструкция изучаемых событий требует значительных вычислительных
мощностей, огромного количества вспомогательных программных и аппаратных средств. Как правило,
для обработки данных задействованы не одиночные ЭВМ, как это было еще 10-15 лет
назад, а целые вычислительные комплексы, включающие в себя болшое число разнообразных ЭВМ, связанных
в единое целое. Увеличение размеров детекторов приводит к "распуханию" событий, возрастанию
информационных потоков, что ложится дополнительной нагрузкой на систему обработки.
При создании ПООД немаловажен также "человеческий фактор"- исследования на современных
установках ведутся сразу по нескольким направлениям, обработкой данных занимается
много людей, зачастую далеких от "высокого искусства программирования", поэтому
организация ПООД внешне должна быть простой и понятной,
иметь хорошо продуманную и гибкую структуру, предполагающую одновременную работу
большого числа физиков, решающих разные физические задачи.
И наконец, к ПООД в настоящее время предъявляются как никогда жесткие требования качества и
адекватности поставленным целям, поскольку на создание и
проведение экспериментов тратятся огромные материальные средства и человеческие
ресурсы, а обработка данных является последним и во многом определяющим звеном
в цепочке получения результатов. Все вышесказанное, а также многие другие не названные
причины говорят о том, что ПООД является одной из
основных составляющих эксперимента, во многом определяющих его успех.
Поскольку создание ПООД - трудная задача, очень привлекательной кажется идея
попытаться создать универсальное ПО, пригодное для обработки любого эксперимента.
По нашему мнению, несмотря на всю свою привлекательность, эта идея неосущестима,
и не осуществима прежде всего потому что нет и не может быть двух одинаковых
экспериментов в физике высоких энергий, каждый из них уникален и отличается
от других набором используемых детекторов, областью исследования, условиями
проведения и т.д. Было бы наивно ождать, что в одной программе можно учесть все
бесконечное разнообразие приборов, которые используются сейчас или будут придуманы
в будущем, предусмотреть все мельчайшие ньюансы, которые необходимо учитывать
при обработке конкретного эксперимента и которые зачастую возникают
помимо или даже вопреки воле экспериментаторов и тем не менее определяют
всю систему обработки.
Здесь уместен небольшой пример. В ЦЕРНе для обработки экспериментов используют
различные типы ЭВМ: IBM, VAX, CRAY и т.д., поэтому при разработке ПООД много
внимания уделяется его машинной независимости, т.е. способности работать без
переделок на любом компьютере. Это требование существенно детерминирует и
во многом затрудняет написание программ, в какой-то степени замедляет их
работу. Из-за этого, в частности, экспериментальные данные пишутся на
внешние носители в машинно-независимом формате при помощи пакета ZEBRA \cite{zebra}
и этим же пакетом раскодируются при чтении. Из-за многочисленных перекодировок
информации, на операции чтения-записи тратится значительно больше времени,
чем при использовании обычных фортрановских операторов READ/WRITE.
В ИФВЭ все используемые нами для обработки ЭВМ одного типа, следовательно
проблема машинной независимости отсутствует (по крайней мере для эксперимента ВЕС),
и нам не нужно беспокоиться о машинно-независимом формате записи данных.
Поэтому мы отказались от услуг пакета ZEBRA в вопросах ввода/вывода, что
позволило осуществлять операции чтения/записи в 8 раз(!) быстрее, чем с его помощью.
%с использованием ZEBRA.
Такой отказ сильно повлиял на внутреннее строение системы обработки,
однако мы сознательно сделали свой выбор, поскольку отказавшись от
универсальности мы смогли существенно сэкономить машинное (да и человеческое) время.
Приводя этот пример, мы вовсе не хотели подвергать критике пакет ZEBRA, несомненно
полезный для решения определенных задач, этот пример призван показать, что
конкретные условия проведения эксперимента определяют использование
тех или иных
программных средств. {\bf Эксперимент и только эксперимент, направленность на достижение
наилучшим и наикратчайшим способом поставленных целей, а не абстрактная
идея универсальности, должна опредлелять структуру
и организацию ПООД, выбор готовых программ и написание новых.
Нужно уметь как можно решительнее преодолевать соблазн использования
готовых программ и пакетов, если они не являются оптимальными для данного
конкретного эксперимента.} По нашему мнению это есть основопологающий принцип,
который должен быть принят за основу при создании любой системы обработки.
%На раннем этапе создания ПООД ВЕС нами рассматривалась возможность использования
%пакета программ для создания и поддержки Базы Данных установки DELPHI \cite{BD}.
%Однако после небольшого периода общения с этим пакетом стало ясно, что это
%пакет-"монстр", требующий затрат огромных человеческих услилий для его освоения,
%настройки под новый детектор и поддержания работоспособности. Этот пакет существенно
%ориентирован на нужды DELPHI и несомненно является там важным и необходимым элементом
%всей системы обработки. Выгоды же от его использования для установки
%ВЕС незначительны, поскольку ВЕС существенно проще DELPHI геометрически и структурно,
%менее подвержен изменениям во времени, да и проблема безработицы не стоит у нас столь остро.
%Поэтому в результате от использования этого пакета нам пришлось отказаться.
Однако мы вовсе не отрицаем использование каких-то общих для разных экспериментов
программных средств, а только определяем условия их применения.
Например, пакет гистограмирования HBOOK \cite{HBOOK} прекрасно вписывается
в нашу систему обработки и мы широко его используем. Пакет динамического
распределения памяти ZEBRA \cite{zebra} используется частично,
в-основном только его MZ-часть, а для чтения/записи данных, как
уже говорилось выше, мы используем свой быстрый (хотя и не универсальный)
пакет. А программу моделирования установки GEANT \cite{GEANT} мы
не используем вовсе, поскольку для проведения парциально-волнового анализа
различных изучаемых в нашем эксперименте систем нам нужно смоделировать
прохождение через установку от сотен тысяч до десятков миллионов
событий, что практически нереально при использовании медленной программы
GEANT. Одно из основных преимуществ GEANT- правильный учет взаимодействий
частиц с веществом практически не имеет значения для ВЕС,
поскольку детектор достаточно прозрачен и однороден для частиц,
вылетающих из мишени под разными углами. Вместо GEANT для установки
ВЕС была написана своя программа моделирования \cite{monte},
учитывающая многие специфические особенности эксперимента и прекрасно
воспроизводящая экспериментальные распределения для различных процессов.
Таким образом, создание ПООД, с одной стороны, задача очень сложная
и трудоемкая, а с другой стороны, для каждого нового эксперимента
она должна во многом решаться заново. Эти два основных момента
и определяют цели написания данной работы, описывающей систему
обработки данных эксперимента ВЕС. Понимая, что ПО ВЕС не может
как готовый продукт быть использовано в неизменном виде для
обработки других экспериментов, мы старались выделить в этой
работе все то существенное, что может оказаться полезным и
интересным для специалистов, работающих в данной области.
Мы ставили перед собой следующие цели:
\begin{itemize}
\item суммировать и изложить в замкнутой форме опыт, накопленный
при создании ПО ВЕС;
\item перечислить и обосновать основные принципы построения
ПО ВЕС, которые, по нашему мнению являются общими для большого
класса систем обработки;
\item сообщить о некоторых технических решениях, которые могут
быть использованы при обработке других экспериментов;
\item дать описание программы реконструкции событий в качестве
справочного материала и для обоснования результатов, которые
получаются и будут получены на установке ВЕС.
\end{itemize}
Во втором разделе этой работы будет дано краткое описание установки
ВЕС и целей эксперимента, в третей части будет приведена структурная
схема ПООД и перечислены основные принципы его построения.
В части 4 будет описана программа реконструкции событий, в
закличение мы дадим описание различных программных средств,
используемых при обработке.
\subsection*{ 2. Установка ВЕС.}
Ниже мы дадим краткое описание установки ВЕС, в котором, не претендуя
на полноту, отметим только те ее особенности, которые существенны
для системы обработки.
Установка ВЕС (см. рис.1) предназначена для изучения адронных
взаимодействий $\pi^-,K^-$ мезонов на легких ядрах с образованием
в конечном состоянии большого числа заряженных и нейтральных
стабильных мезонов ($\pi^{\pm},\pi^0,K^{\pm},\eta$), являющихся
продуктами распада резонансов ($\eta',\omega,\rho,f,a$ и т.д.).
В задачи эксперимента входит наряду с высокостатисическим
анализом уже известных мезонов для уточнения их квантовых свойств
и механизмов распада, поиск новых состояний, в том числе
так называемых "экзотических", то есть отсутствующих в простой
кварковой модели и требующих участия глюонов в их образовании
(глюболы, гибридные и многокварковые состояния, мезонные атомы и т.д.).
Первые результаты, полученные на установке ВЕС, можно найти
в \cite{res}.
Имеющаяся аппаратура позволяет уверенно регистрировать до
6 заяженных частиц и до 8 $\gamma$-квантов одновременно.
За два года работы установки набрано более 100 млн. полностью
восстановленных многочастичных событий, что дает для многих изучаемых
систем рекордную статистику. Установка ВЕС позволяет регистрировать
частицы, вылетающие из мишени под углами:
$\Delta\Theta_x=\pm40^{\circ},\Delta\Theta_y=\pm30^{\circ}$
с импульсами от 200 МэВ для заряженных и $\gamma$-квантов
вплоть до максимально возможных, что обеспечивает
мало меняющуюся эффективность для угловых распределений
в системах центра масс различных частиц. Это свойство особенно
важно для парциально-волнового анализа, который предполагается
проводить практически для каждого изучаемого конечного состояния.
Следует отметить также, что на пути частиц
при их пролете через установку находится минимальное количество
вещества, это делает установку прозрачной и минимизирует число
вторичных взаимодействий.
Пучковая часть установки, предназначенная для определения направления
движения и типа ($\pi^-,K^-,p^-$) пучковых частиц состоит из:
\begin{itemize}
\item 8 плоскостей гексагональных пропорциональных камер,
расположенных вдоль пучка на базе 2.5 метра (в отдельных экспозициях
база увеличивалась до 7 метров) и позволяющих измерять координаты
прохождения пучка с точностью 300 $\mu m$.
\item 3 пороговых черенковских счетчиков (на рис.1 не показаны)
с разными порогами, позволяющих определять тип пучка ($\pi^-,p^-,K^-$).
\end{itemize}
Трековая система установки состоит из:
\begin{itemize}
\item широкоапертурного магнита, создающего слабонеоднородное
поле с апертурой $2.5\times 1.5$ метра и средним интегралом поля
по пучку 0.7 ГэВ/с;
\item 29 плоскостей пропорциональных и дрейфовых камер;
\item многоканального порогового черенковского счетчика
(28 каналов) с порогом для $\pi$-мезонов 4.4 ГэВ/c.
\end{itemize}
До магнита располагается 16 плоскостей пропорциональных камер
(8 Х-плоскостей, 6 Y-плоскостей и 2 плоскости,
налоненные под углами $\pm15^{\circ}$). Шаг между сигнальными
проволочками в пропорциональных камерах 2 мм, расстояние
между крайними плоскостями 90 см. После магнита находится
9 плоскостей дрейфовых камер (3 X-плоскости,3 Y-плоскости,
3 наклонные плоскоти). Шаг между сигнальными проволочками- 1.6 см
для X,Y-плоскостей и 2.4 см для наклонных плоскостей, рассояние
между крайними плоскостями 100 см, размер чувствительной области камер - $256\times192$ см.
Дрейфовые камеры позволяют измерять координаты прохождения
частиц с точнстью 300 $\mu m$. Для повышения точности трековой
системы в центре магнита расположены минидрейфовые камеры (4 Х-плоскости)
с шагом между проволочками 6 мм. Размер этих камер: $192\times 90$ см,
точность определения координаты прохождения частиц 300 $\mu m$.
Трековая система в целом позволяет измерять импульсы заряженных
частиц в широком диапазоне с точностью не хуже чем $\sigma_p/p = 4\cdot10^{-4}\cdot p[GeV]$.
Точность измеремия углов составляет $\approx 3\cdot10^{-4}$.
$\gamma$-кванты регистрируются при помощи ячеистого калориметра из
свинцового стекла (см. рис.2). Размер ячеек в центре $\gamma$-детектора: $43\times 43$ мм,
по краям - в два раза больше ($86\times 86$ мм). При помощи
данного детектора определяются координаты $\gamma$-квантов с точностью $\sigma_{x,y}=???$ см,
а также их энергия с точностью ($\sigma_E/E=???/\sqrt{E}+???$).
Поскольку в задачи эксперимента входит изучение широкого класса
адронных взаимодействий, для выработки триггера и приема события
требуется выполнение минимального набора условий. Более конкретно, требуется:
\begin{itemize}
\item наличие пучковой частицы, попадающей в мишень. Это условие
проверяется по совпадению срабатывания системы из 3 сцинтилляционных счетчиков,
расположенных вдоль пучка, а также антисовпадению с сигналом от счетчика
с дыркой, пропускающей пучок, предназначенного для подавления "гало" вокруг пучка;
\item взаимодействие в мишени. Для проверки этого требования сразу
после мишени находится сцинтилляционный счетчик и измеряется амплитуда сигнала
от прохожедния через него заряженных частиц. Для выработки триггера
требуется превышение этого сигнала над порогом, который
определяется по сигналу от одиночной заряженной частицы. Кроме того,
на значительном расстоянии от мишени, после магнита на линии
движения пучка находятся два счетчика, включенных в антисовпадение.
Для выработки триггера требуется, чтобы {\bf не} сработали одновременно эти два
счетчика, таким спосбом проверяется выбывание частиц из пучка;
\item наличие от двух до шести заряженных частиц после магнита. Для проверки
этого условия после магнита между второй и третьей дрейфовыми камерами находится
годоскоп из двух плоскостей сцинтилляционных счетчиков общей аппертурой $260\times 200$ см.
На каждой плоскости в-отдельности подсчитывается множественность $N_x,N_y$ (число сигналов)
и требуется, во-первых, чтобы эта множественность не отличалась для двух
плоскостей больше, чем на единицу, а во-вторых, чтобы $2\leq N_{x,y}\leq 6$.
\item попадание всех образовавшихся частиц в апертуру установки. Это требование
необходимо для выделения эксклюзивных реакций, в котрых все частицы (как заряженные,
так и нейтральные) регистрируются, и достигается оно, во-первых, при помощи
охранной системы вокруг мишени, подавляющей вылет частиц из мишени вбок, а во-вторых,
при помощи охранной системы до магнита, подавляющей события с заряженными и нейтральными
частицами, которые не попадают в апертуру детектора. Конструктивно эта
охранная система сделана на основе первых четырех плоскостей пропорциональных
камер, на края которых навешены свинцовые пластины. Так как размеры передних
камер несколько превышают апертуру детектора, то любые
частицы, попавшие в их края не будут зарегистрированы, следовательно
такие события нужно отбросить. Для этого сигналы из крайних областей
камер суммируются и включаются в антисовпадение с остальными триггерными
условиями. Свинцовые пластины необходимы для того чтобы $\gamma$-кванты
также давали сигнал в этой охранной системе.
\end{itemize}
Кроме перечисленных приборов, после магнита в районе $\gamma$-детектора
расположена охранная система, регистрирующая частицы, вылетающие за
его апертуру. Она, однако, не включена в триггер, ее сигналы
анализируются уже на стадии off-line обработки и позволяют подавить
события с $\gamma$-квантами, которые не регистрируются $\gamma$-детектором.
Среди особенностей установки хотелось бы выделить следующие важные черты:
\begin{itemize}
\item установка имеет большую апертуру как для заряженных, так и для нейтральных частиц;
\item основная часть трековых детекторов расположена вне магнитного
поля, что существенно облегчает поиск и восстановление треков;
\item слабое магнитное поле в области головных пропорциональных
камер, совместно с минидрейфовыми камерами в центре магнита эффективно
создает вторую ступень трековой системы, которая дает возможность регистрировать
частицы с малыми импульсами (менее 1 ГэВ), не доходящие до конца установки;
\item увеличение размера ячеек на краях $\gamma$-детектора дает возможность
при заданном числе регистрирующих каналов и без значительного ухудшения
точностных характеристик существенно увеличить апертуру $\gamma$-детектора;
\item высоко-скоростная система сбора данных позволяет принимать за
один цикл рабты ускорителя (который длится 0.8-1 сек.) до 2 Мегабайт
данных (800-1000 триггерных событий), что обеспечивает высокую статистику
эксперимента;
\end{itemize}
\subsection*{ 3. Структурное построение системы обработки данных установки ВЕС}
В начале этого раздела хотелось бы еще раз подчеркнуть, что приводимая
здесь схема обработки ориентирована на конкретный эксперимент и
приспособлена ко вполне определенным вычислительным мощностям, и,
следовательно, непосредственное применение ее в других условиях
нужно проводить с осторожностью. Тем не менее, она несет в себе,
по нашему мнению, много общих для широкого класса экспериментов
свойств, которые и хотелось бы осветить.
\subsection*{ 3.1 Параллельная обработка событий}
Общая схема системы обработки представлена на рис.3. Ее главной
особенностью, во многом определяющей все построение, является
возможность параллельной обработки событий (ПОС).
Из всего многообразия различных задач, решаемых при помощи
компьютеров, пожалуй, никакая другая не подходит так идеально
для параллельного вычисления на многих ЭВМ одновременно,
как задача реконструкции событий в физике высоких энергий.
Это объясняется тем, что:
\begin{itemize}
\item обработка каждого события- независимый процесс, не
требующий специального изменения программы и/или какой-либо
информации о результатах обработки предыдущих событий;
\item последовательность обработки событий, как правило, не
имеет значения, следовательно нет необходимости в синхронизации
разных вычислительных процессоров, они могут работать независимо,
ничего не зная о существовании друг друга;
\item восстновление отдельного события не требует больших
вычислительных мощностей (опертаивной памяти и быстродействия),
проблема в том, чтобы обработать много событий, следовательно,
вместо одной суперЭВМ можно использовать несколько десятков
более доступных ЭВМ среднего класса.
\end{itemize}
Именно благодаря ПОС нам удалось в условиях ИФВЭ в сжатые
сроки (около 3 месяцев работы в режиме разделения времени
с другими пользователями) полностью обработать около 200 млн. событий
(доля "полезных" событий, используемых в последующем физическом
анализе превышает $50\%$) со сложной топологией
(от 2 до 6 заряженных частиц и до 8 $\gamma$-квантов одновременно).
Простейшим способом ПОС является разделение всего объема
событий на несколько частей и независимая их обработка на
разных ЭВМ. Такое примитивное распараллеливание несомненно имеет
право на существование, при условии наличия у всех
используемых ЭВМ необходимой переферии (дисковая память,
магнитофоны для чтения/записи). Такое ПОС просто реализовать,
однако сложность контроля за процессом обработки возрастает
вместе с числом задействованых ЭВМ и при большом их
количестве может превратиться в серьезную проблему.
Кроме того, в ИФВЭ примитивная ПОС не может быть реализована
из-за ограниченного числа магнитофонов,
гораздо меньшего, чем число доступных процессоров.
Поэтому организация ПОС для ВЕС осущетсвлена несколько сложнее.
Все операции, связанные с вводом и выводом событий были
отделены друг от друга и от счетных процессов (СП).
Структурно они объеденяются в полностью независимые модули
"Input Manager" (IM) и "Output Manager" (OM) (см. рис.3).
Такое разделение является важной особенностью нашей системы
обработки.
Каждый счетный процесс получает события от IM, обрабатывает их
и передает результаты обработки OM для записи на внешние носители,
он ничего не знает о существовании других СП и
полностью освобожден от каких-либо обращений
к устройствам ввода/вывода, что позволяет неограниченно
увеличивать общее число СП, участвующих в обработке. (На практике,
естественно, существует предел числа СП, в частности, из-за
конечной скорости обмена с устройствами ввода/вывода и т.п.)
В начале каждого цикла работы СП посылает запрос очередной порции
событий и ждет сигнала конца передачи. Получив такой сигнал,
он начинает обработку переданных событий и, закончив ее,
посылает требование принять результаты обработки. После окончания передачи
выставляется запрос новой порции событий и весь цикл повторяется.
Модуль IM управляет входным потоком данных и, кроме этого,
ведет контроль постановки входных лент
(т.е. лент с исходной, "сырой" информацией) на магнитофон.
Он запрашивает ленты согласно специального списка и
проверяет при этом правильность их постановки, чтобы исключить
повторную обработку одних и тех же лент. После этих
подготовительных операций
IM переходит в режим ожидания запроса данных от какого-либо СП.
Получив его, он передает определенное число событий запрашивающему
процессу, передает сигнал окончания передачи
и снова переходит в режим ожидания.
%Конкретная рализация
%этого механизма будет описана несколько позднее.
Модуль ОМ управляет выходным потоком данных.
Подготовив к работе очередную ленту для записи обработанных
событий согласно своего списка лент, он ждет от СП требования
спасения результатов обработки. Получив это требование,
он принимает события от СП и записывает их на внешний носитель.
При этом контролируется объем его заполнения (чтобы исключить
переполнение) и уникальность записываемых событий (т.е. опять
принимаются меры против повторения на выходе одних и тех же
событий). После этого ОМ опять переходит в режим ожидания.
Конкретная реализация данной схемы учитывает реальные возможности
вычислительного центра ИФВЭ, однако применимость ее в других условиях
мало чем ограничена. При этом критичными и системно зависимыми являются только
две проблемы, решение которых следует осуществлять исходя из специфических
особенностей используемых компьютеров:
\begin{itemize}
\item спсоб обмена информацией между СП, IM и OM;
\item синхронизация работы СП, IM и OM.
\end{itemize}
В ИФВЭ все используемые для обработки ЭВМ объеденены в единую
сеть DECNET, при этом каждая ЭВМ имеет доступ к общим для всех дискам.
Исходя из этого было принято решение осуществлять
обмен информацией (передача событий от IM к СП
и далее от СП к OM) через дисковые файлы (см. рис. 4). IM считывает определенную
порцию событий с ленты и после получения запроса от СП записывает ее в рабочий
файл (Input Work File, IWF), доступный для чтения счетному процессу.
У каждого СП свой рабочий файл, так что они друг с другом
никак не пересекаются. IM принимает не
только сигнал запроса событий, но также и уникальный номер СП,
пославшего этот запрос, и записывает информацию именно в тот IWF,
который соответствует данному СП. Анологично этому, каждый СП,
обработав события, записывает их в свой Output Work File (OWF) и
посылает к OM требование принять эту информацию. OM также получает
номер СП, пославшего требование, считывает информацию из соответствующего
OWF и записывает ее на внешний носитель. Такая реализация связи
между процессами выгодно отличается своей простотой, и хотя
некоторая часть времени тратится на промежуточные обмены с дисками,
это замедление гораздо меньше характерного времени
обработки событий и поэтому практически не заметно.
Синхронизация работы всех СП с IM и OM была осуществлена при
помощи специальных 32-битных регистров: Event Flag Clusters
(каждый бит в этих регистрах называется Event Flag (EF)).
Содержимое регистров
доступно для всех задач, работающих на одной ЭВМ, на другие компьютеры
это содержимое передается по сети. Операционная система позволяет
каждому процессу устанавливать или убирать любые EF, проверять состояние
любых EF, ожидать появление одного или группы EF. Для синхронизации
работы СП и IM выделен полный 32-битный регистр
(Input Event Flag (IEF) Cluster).
Структурно он разделен на 3 части (см. рис.5а). Первые 8 бит (IEF00-IEF07)
используются для системных целей, 12 бит
(т.н. флаги запросов, IEF08-IEF19) отведены для
сигнализации запросов от 12 различных счетных процессов, еще 12 бит
(флаги готовности, IEF20-IEF31) отведены для сигнализации
ответов IM на запросы каждого из 12 СП.
Работает система синхронизации следующим образом.
Каждому СП присваивается уникальный номер от 1 до 12 и когда ему нужно
получить очередную порцию информации, он устанавливает свой EF запроса
(процессу номер 1 соответствует IEF08, процессу номер 12- IEF19) и переходит
в режим ожидания от IM флага готовнности (процессу номер 1 соответсвует IEF20,
процессу номер 12- флаг IEF31).
Input Manager ждет появления любого из флагов запроса
IEF08-IEF19 и по его номеру
узнает, какой СП требует информации. Затем IM зачитывает события
со входной ленты, записывает их в соответсвующий IWF, убирает флаг
исполненного запроса, устанавливает соответствующий флаг готовности
(IEF20-IEF31, номер флага соответствует номеру процесса, запрос которого
выполнен) и опять переходит в режим ожидания.
Синхронизация работы СП и OM организована анологично при
помощи Output Event Flag Cluster (см. рис.5б) с очевидными изменениями.
Описанная схема параллельной обработки событий
обладает целым рядом преимуществ и среди
них главным: она работает без сбоев и позволяет многократно
ускорить обработку событий. Среди других отличительных
особенностей данной схемы можно отметить следующие:
\begin{itemize}
\item каждый СП работает абсолютно независимо
от других СП, максимальное число одновременно работающих СП - 12,
хотя это ограничение чисто техническое и при необходимости может быть
легко преодолено.
\item IM и OM обрабатывают запросы различных СП последовательно,
по мере их поступления, при этом не требуется какой-либо
системы приоритетов или арбитража запросов.
\item ввод/вывод осуществляется централизованно и для
нормальной работы достаточно одного магнитофона для чтения
и одного магнитофона для записи.
\item благодаря указанной централизации упрощается контроль
человека за операциями ввода/вывода, которые являются,
несомненно, наиболее уязвимым звеном во всей схеме обработки,
чаще всего вызывающим остановки и задержки.
\item операции ввода и вывода отделены и не зависят друг от друга,
они вообще могут осуществляться на разных компьютерах. Этим достигается
существенная экономия реального времени, затрачиваемого на
них, что может оказаться важным, поскольку ввод/вывод- наиболее
медленные операции, способные сдерживать весь темп обработки.
\item описанная схема ПОС обеспечивает
определенную гибкость всей системы обработки: счетные процессы
могут включаться в обработку в произвольный момент времени и прерывание
работы какого-либо СП никак не скажется на других процессах.
\end{itemize}
\subsection*{ 3.2 Описание геометрии установки}
Организация хранения и доступа к геометрическим и
калибровочным константам (ГиКК)
установки - еще один важный момент в структуре системы обработки ВЕС.
Данному вопросу неизбежно уделяется значительное внимание при
обработке любого эксперимента и для некоторых из них (таких, например,
как эксперименты на встречных пучках) организация работы с геометрией
установки превращается в серьезную и трудно разрешимую проблему,
отвлекающую силы десятков специалистов. Суть ее состоит
в том, что гигантские эксперименты на коллайдерах имеют черезвычайно
сложную внутреннюю структуру, а каждый из используемых детекторов
описывается огромным количеством ГиКК, которые к тому же быстро изменяются
во времени, так что общий объем информации о параметрах установки
может превышать десятки Мегабайт. Поэтому требуются
значительные усилия, для того чтобы как-то упорядочить эту
информацию и извлекать нужную ее часть для различных программ реконструкции.
Для этих целей используют специальные базы данных
(см., например, \cite{BASE}), которые сами по себе являются громоздкими
и сложными в использовании программными продуктами.
На раннем этапе создания ПООД ВЕС рассматривалась возможность применения
одного из вариантов такой специализированной базы данных
(аналога Базы Данных DELPHI) для хранения параметров установки,
однако после детального изучения этого вопроса стало ясно,
что использование Базы Данных для установки ВЕС мало эффективно и не является
обязательным.
Это объясняется тем, что в отличие от экспериментов на коллайдерах,
где Базы Данных нашли широкое применение:
\begin{itemize}
\item геометрия установки ВЕС достаточно простая: плоскости
всех детекторов с хорошей точностью параллельны друг другу
и перпендикулярны оси пучка;
\item конфигурация установки не меняется (или редко меняется) по ходу эксперимента,
все детекторы, как правило, остаются на своих местах, не добавляется
новых детекторов, а те что есть- работают исправно;
\item внутренняя структура всех детекторов достаточно проста и регулярна,
и их характеристики описываются малым числом
калибровочных параметров, к тому же слабо меняющихся во времени;
\end{itemize}
Поэтому, руководствуясь основным принципом построения
системы обработки, сформулированным во Введении,
мы отказались от использования Баз Данных для эксперимента ВЕС,
вместо этого все геометрические и калибровочные константы хранятся
в обычном файле последовательного доступа. Этот файл общий для всех программ,
обращающихся к геометрии установки, имеется также универсальная процедура
доступа к его информации, устроенная так, что
файл с ГиКК зачитывается целиком, при этом {\bf не} предусматривается
возможность выбора какой-либо части информации, относящейся к отдельному
детектору или определенному промежутку времени.
При изменении условий проведения эксперимента (изменение геометрии
и/или перекалибровка детекторов) меняется весь файл,
и так как его размер не очень большой (около 30 Килобайт),
хранение нескольких файлов, отвечающих различным условиям
проведения эксперимента, не вызывает каких-либо сложностей.
В процессе реконструкции полностью обрабатываются та часть событий, которая соответствует
текущему файлу с ГиКК, после этого подключается файл
с другими константами и обрабатываются все ему соответсвующие события, и т.д.
Поскольку число различных интервалов времени, для которых ГиКК можно считать постоянными,
небольшое, переключение между различными файлами достаточно
простая процедура, которая никак не сказывается на процессе обработки.
Так как хранение геометрии установки
внутри программы реконструкции организовано в виде структуры из
ZEBRA- банков (ее описание будет дано в разделе 4),
файл с ГиКК записывается и читается при помощи FZ- пакета
(см. \cite{zebra}), и фактически в дисковом файле находится
прямое отражение структуры геометрии в оперативной памяти.
Такая организация способа хранения данных:
\begin{itemize}
\item выгодно отличается своей простотой;
\item обсепечивает доступ к ГиКК из любых программ;
\item дает возможность без затруднений отслеживать изменение параметров
установки во время сеанса;
\item учитывает возможность многопользовательского режима работы;
\item гарантирует работу с одними и теми же константами для любых
программ обработки;
\item изменение констант в файле возможно только при помощи специальных
процедур, не являющихся общедоступными, это защищает ГиКК от несанкционированых изменений;
\end{itemize}
Однако стоит отметить, что этот способ рботы с ГиКК, по-видимому,
не является универсальным, и по мере усложнения эксперимента более правильным
является использование специализированных Баз Данных с гибкой структурой
и большими возможностями упорядочивания, выбора и изменения всей или части информации.
И тем не менее для конкреного случая установки ВЕС (и целого класса других не слишком
сложных экспериментов) хранение ГиКК в отдельном файле, содержимое
которого используется целиком и может быть изменено тоже только как целое,
является оптимальным решением, существенно упрощающим работу с данными
и не вызывающим каких-нибудь ограничений или неудобств из-за своей простоты.
\subsection*{ 3.3 Вспомогательные элементы системы обработки}
Ниже будут кратко перечислены другие составляющие системы обработки ВЕС
без детального их рассмотрения, так как их назначение и применение достаточно
очевидно (см. рис.3).
Кроме описанных выше основных структурных единиц
(Счетные процессы, Input Manager,
Output Manager, файл с геометрическими и калибровочными константами),
в систму обработки ВЕС входят:
\begin{itemize}
\item набор программ для калибровки детекторов;
\item программы визуализации реконструируемых событий;
\item система контроля за качеством реконструкции событий;
\item программы моделирования установки методом Монте-Карло;
\end{itemize}
Перечисленные программные средства, несмортя на свой вспомогательный характер,
играют важную роль и в том или ином виде должны быть включены
в любую систему обработки.
{\bf Набор калибровочных программ} предназначается для определения
параметров детекторов, необходимых для реконструкции событий.
Эти программы работают со специальными калибровочными событиями
и записывают найденные ГиКК непосредственно
в калибровочный файл. Отметим, что только эти программы и могут изменять
ГиКК. При создании этих программ соблюдался важный
принцип минимального вмешательства человека, т.е. при наличии
необходимого набора калибровочных событий, полное определение
констант происходит автоматически.
{\bf Программы визуализации реконструируемых событий} дают графическое
представление как зарегистрированных событий, так и результатов
их обработки. Роль этих программ особенно важна на этапе создания
алгоритма реконструкции, фактически с их помощью проводится его
тонкая настройка и устранение неизбежных в начале дефектов. Во время обработки
событий эти программы включаются в систему контроля за качеством
реконструкции. Благодаря отмечавшейся выше относительной простоте установки ВЕС,
эти программы также достаточно просты, но тем не менее дают
всю необходимую для работы информацию о геометрии установки, расположении
сигналов от различных детекторов, результатах реконструкции и т.д.
{\bf Система контроля за качеством реконструкции событий} является
необходимым звеном во всей системе обработки. Если общий
объем статистики очень большой и/или набор статистики проводился
в течение долгого периода времени, то из-за каких-либо
неучтенных эффектов во время сеанса возможно внезапное изменение качества
реконструкции событий (простейший пример- изменение
характеристик пучка). Такие изменения важно вовремя обнаружить
и внести необходимые поправки в программы реконструкции.
Для этих целей и служит система контроля за качеством реконструкции.
Данный контроль осуществляется по многим направлениям. Прежде всего это
регулярный просмотр событий при помощи графических программ (см. выше),
в нормальном режиме допускается не более $5\%$ неправильно реконструированных
событий (причинами неправильной реконструкции являются:
особо сложная топология событий, несрабатывание каких-либо детекторов и т.д.).
Кроме этого для каждой обработанной ленты определяются
некоторые характерные величины (такие как число обработанных
событий, доля полностью реконструированных событий и т.д.), говорящие
о качестве реконструкции. И, наконец, наиболее важный вид контроля
следующий. В процессе обработки строятся распределения некоторых
заранее определенных величин, по которым можно судить о качестве реконструкции.
Это такие величины, как:
\begin{itemize}
\item распределение по числу треков событиях;
\item суммарный импульс в событиях с разным числом треков;
\item t-распределения для различных типов событий;
\item масса пары двух $\gamma$-квантов;
\item масса двух заряженных частиц, идентифицированных как К-мезоны и т.д.
\end{itemize}
Эти распределения регулярно обновляются и сравниваются с опорными
распределениями, полученными, например, в начале сеанса. Отличие от них
может свидетельствует о каких-то изменениях
в условиях проведения эксперимента, которые нужно тщательно изучить,
прежде чем продолжить обработку.
И, наконец, {\bf программы моделирования установки методом Монте-Карло}
нужны, как правило, уже на этапе получения физических результатов.
Важно отметить что они работают в точности с теми же геометрическими
константами, что и программы реконструкции. Как уже отмечалось
выше, для моделирования установки были написаны специальные
программы, учитывающие многие особенности эксперимента ВЕС. Описание работы
этих программ, необходимое для обоснования полученных на ВЕС
результатов, предполагается дать в других публикациях.
\subsection*{ 3.4 Некоторые принципы организации системы обработки}
Заканчивая описание структуры системы обработки установки ВЕС,
хотелось бы остановиться на некоторых основных принципах,
которые учитывались при пострении этой системы и которые останутся
неизменными при обработке других экспериментов.
Прежде всего, при создании систем обработки нужно как можно более
последовательно следовать принципу {\bf минимального участия человека
в процессе реконструкции}. Это означает, что после того как программы
реконструкции написаны и отлажены, активное участие человека заканчивается,
и обработка всего объема данных должна проводиться ЭВМ автономно. В частности,
должна быть доведена до автоматизма процедура постановки входных и
выходных лент на магнитофоны, процедуры чтения/записи данных, не допускается
изменение программ реконструкции без особой нужды и т.д. Роль человека
при запущенной системе обработки в идеале должна сводиться исключительно к
контролю за качеством обработки. Естественно, этот идеал бывает трудно достижим,
однако к нему нужно стремиться и организовывать программное
обеспечение соответствующим образом.
В процессе разработки программного обеспечения мы
постоянно руководствовались {\bf принципом простоты}: из различных возможных
вариантов построения разных систем выбирался для реализации простейший.
Несомненно, что чем проще программа, тем она надежнее в работе и понятнее
для других.
{\bf Постоянный контроль качества обработки} - следующий важный принцип,
способы выполнения которого описаны в предыдущем разделе.
Система обработки должна быть устроена так, чтобы всегда имелась
{\bf возможность восстановления (Recovery), т.е. возможность ее
прерывания и перезапуска в любой момент времени.}
Обработка любого эксперимента - длительная процедура, растягивающаяся, как правило,
на несколько месяцев. За это время могут происходить сбои в работе
компьютеров, их остановка, подключение новых ЭВМ и т.д., что неизбежно
приводит к прерываниям обработки, которые случаются
непредсказуемо, в любой момент времени. Система обработки ни в коей
мере не должна быть чувствительна к этим прерываниям и должна
уметь продолжить работу
с той точки, в которой она остановилась
в последний раз. Для этого ПО должно включать в себя процедуру восстановления
(Recovery Procedure, RP).
Процедура восстановления (RP) для ВЕС устроена следующим
образом. Работа счетных процессов может быть остановлена в любой момент.
Поскольку они читают события из индивидуальных файлов на диске и
записывают обработанные события в другие индивидуальные файлы,
то их остановка никак не влияет на работу всей системы. При перезапуске
они обрабатывают буффер с сбытиями (из своего Input Work File)
{\bf с самого начала} и записывают результаты обработки в Output Work File тоже
с начала. Так как каждая порция собыий, которая находится в IWF и
с которой имеет дело СП, достаточно мала (около 1000 событий),
то потери времени на ее переобработку также невелики. Содержимое
OWF вычитывается Output Manager'ом только после того, как обработка IWF
закончена полностью, поэтому каких-либо потерь или удвоений событий
на выходных лентах не происходит.
RP для Input Manager'a организовано так. Каждая входная
лента сначала копируется в специальный дисковый файл, причем таких
файлов предусмотрено как минимум 2, для того чтобы не терялось
время на ожидание конца копирования. После того как лента скопирована
в файл {\bf полностью}, в специальный Input Recovery File (IRF)
заносится информация о том, что данная лента готова к работе.
Если прерывание происходит до окончания копирования ленты, запись о ней в
IRF будет отсутствовать и при
восстановлении эта лента должна будет скопирована заново. Input Manager
при восстановлении (или инциализации) ждет пока на диск не будет скопирована
хотя бы одна лента (номер последней скопированной
ленты извлекается из IRF), а если такая лента уже есть, он начинает работать
(т.е. раздавать события счетным процессорам) {\bf с самого начала} этой
ленты. Таким образом часть событий с ленты, при обработке которой
произошло прерывание, будет обработана заново, однако на выходную
ленту они записаны не будут благодаря специальному фильтру, встроенному
в Output Manager (об этом см. ниже). Потери времени на переобработку
части событий также незначительны, если интервал времени между прерываниями
гораздо больше времени обработки одной ленты.
Восстановление работы Output Manager'a устроено сложнее всего. Обработанные
события пишутся ОМ сначала в специальные дисковые файлы, которых может
быть несколько, их размер фиксирован. После того как
очередной файл полностью заполняется, он записывается на выходную ленту
и информация о номере выходной ленты и номере файла на этой ленте
заносится в Output Recovery File (ORF) (естественно, только после окончания
копирования на выходную ленту). При восстановлении благодаря ORF определяется
номер текущей выходной ленты и число файлов, которые уже есть на этой ленте,
эта лента проматывается до конца записи (по файлам) и, таким образом, становится
готовой к записи новых файлов. Output Manager при восстановлении имеет
информацию о том, в какой файл он записывал события до прерывания. Этот
файл является незаконченным, OM последовательным чтением доходит до конца
последней записи в этом файле и после этого ждет новых событий от СП,
чтобы продолжить запись в этот файл.
Как уже упоминалось, на выходе ОМ встроен специальный фильтр, который
не пропускает на выходную ленту события, которые до того уже были обработаны.
Этим фильтром отсекаются, в частности, повторяющиеся события, которые возникают
при RP для IM. Каждое событие имеет уникальный идентификатор,
состоящий из номера входной ленты, номера спила (Spill соответсвует
одному ускорительному циклу работы ускорителя) и порядкового номера события в данном
спиле. В каждом спиле, в среднем, от 700 до 1000 событий, именно один спил является
тем квантом, которым передаются события от IM к СП для обработки. Спилы при
обработке никогда не разрываются, номера событий внутри спила находятся
всегда в возрастающем порядке. При приеме очередного спила от СП, Output
Мanager определяет при помощи идентификатора номер ленты и номер спила,
к которому относятся принятые события, и
проверяет по специальной таблице, проходил ли через него данный спил
прежде. Только в том случае, если информация
об этом спиле в таблице отсутствует, ОМ записывает его в выходной файл и
вносит соответствующую отметку в таблицу. Эта таблица спасается в отдельный
файл после окончания каждого выходного файла и при восстановлении вновь
зачитывается Output Manager'ом.
Таким образом система восстановления для ВЕС удовлетворяет всем необходимым
требованиям:
\begin{itemize}
\item допускается прерывание любой части системы обработки в любой момент
времени;
\item восстановление каждой подсистемы происходит независимо;
\item гарантируется продолжение обработки в точности с того момента, когда
произошло прерывание любой подсистемы;
\item система обработки защищена от потерь событий или удвоения одних и тех же
событий из-за прерываний;
\end{itemize}
В заключение этого раздела следует отметить еще один принцип построения системы
обработки, который можно рассматривать и как технический момент, но на котором
все-таки стоит остановиться. При создании ПО обработки эксперимента неизбежно
возникает вопрос о том, {\bf что нужно писать на выходную ленту}, т.е. что является
результатом обработки. Для эксперимента ВЕС после многочисленных проб было
принято решение: записывать на выходную ленту (Data Summary Tape,DST):
1)"сырую" информацию {\bf полностью} (т.е. как реконструированные события,
так и те, которые не удалось реконструировать) и 2) конечные результаты
реконструкции для полностью реконструированных событий. Конечные результаты
включают в себя параметры треков и ливней в $\gamma$-калориметре. При этом важным
является тот факт, что промежуточные вычисления (различные варианты поиска треков,
последовательные операции восстановления треков и т.д.) {\bf не сохраняются}.
Сохранение этой информации на выходных лентах привело бы к значительному
распуханию общего числа DST, что вызвало бы большие трудности, перечеркивающие
незначительные преимущества от использования этой информации в последующем.
Такая информация в принципе может понадобиться при перепроверке работы алгоритма
реконструкции для части событий (в случае, например, обнаружения каких-то особенностей
реконструкции), однако получить ее можно и без ее записи
на DST, а переобрабатывая заново интересующие события, используя сохраненную
"сырую" информацию. Этот принцип, незначительный на первый взгляд, приводит
к существенным упрощениям как программ реконструкции, от которых не нужно
требовать способности продолжить обработку события с какого-то промежуточного
этапа, так и формата записи на выходную ленту, который не должен учитывать
многие особенности промежуточных вычислений.
\subsection*{ Выводы}
В данной части описания системы обработки данных эксперимента ВЕС после
краткой информации о самой установке представлена общая схема
организации ПО ВЕС. Подробно разбирается реализация параллельной
обработки событий на многих ЭВМ одновременно, которая является
ключевым звеном во всей структуре ПО. Описан принятый для ВЕС способ
работы с геометрическими и калибровочными константами, необходимыми для
реконструкции событий. Сформулированы некоторые принципы построения
системы обработки ВЕС, подробно разобрана процедура восстановления
системы после непредвиденных прерываний.
\end{document}