Схема потоков данных на установке CMS/ LHC и средства их обработки
Уровневая архитектура компьютерных ресурсов CMS. Поток данных от детекторов для анализа. Сокращение размера событий: CMS форматы данных и форматы Тир-данных. Иерархия CMS данных. Средства удаленной работы на LINUX машинах в CERN: PUTTY, WinSCP и Xming.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | русский |
| Дата добавления | 17.02.2014 |
| Размер файла | 3,1 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Министерство образования Республики Беларусь
Учреждение образования
«Гомельский государственный университет
имени Франциска Скорины»
Физический факультет
Кафедра теоретической физики
Курсовая работа
Схема потоков данных на установке CMS/ LHC и средства их обработки
Исполнитель: студентка группы Ф-46у
Е.С. Ковалева
Научный руководитель: к.ф.-м.н., доцент
С.Г. Шульга
Гомель 2011г.
РЕФЕРАТ
Объект исследования: потоки данных на CMS и средства их обработки.
Предмет исследования: изучение руководства пользователя CMSSW и составление общей картины потоков данных на CMS.
Методы исследования: сбор и систематизация информации с Интернет-сайта CMSSW, пакет ROOT.
Цель курсовой работы: изучение и подготовка документации для схемы потоков данных и средств их обработки на установке CMS/ LHC.
Задачами курсовой работы являются:
1. Изучить руководство пользователя для CMSSW;
2. Перевод и оформление русифицированной версии руководства по CMSSW;
3. Размещение русифицированного руководства пользователя на сайте группы CMS в ГГУ;
4. Изучить примеры анализа данных.
Список использованных обозначений:
ГГУ - Гомельский государственный университет;
ПК - персональный компьютер;
T0 - уровень 0;
T1 - уровень 1;
T2 - уровень 2.
Введение
CMS предоставляет немалые трудности не только с точки зрения производства открытий в физике, строительства и эксплуатации детектора, но и с точки зрения объема производимых данных и необходимых вычислительных ресурсов. Наборы данных и требования ресурсов, по крайней мере, на порядок больше, чем в экспериментах, выполнявшихся до запуска LHC.
Требования к хранению данных на CMS трудно выполнить в одном месте как по техническим, так и по финансовых причинам. Кроме того, большинство CMS-сотрудников не базируются в CERN, и не имеют значительного доступа к CERN-ресурсам, которые целесобразно использовать для CMS-анализа. Поэтому вычислительная среда CMS была построена как распределенная система компьютеров, сервисов, услуг и ресурсов, которые взаимодействуют друг с другом по системе GRID. Набор сервисов и их взаимодействие вместе составляют средства вычислений, хранения данных и подключения ресурсов, которые CMS использует для обработки данных, архивирования данных, формирования Монте-Карло-событий, и всех видов вычислительной деятельности.
Вычислительная инфраструктура доступна для сотрудников CMS, независимо от их физического расположения.
В курсовой работе впервые сделано исследование возможности удаленной работы для экспериментов LHC, находясь удаленно в Гомеле. При этом применялись средства, которые традиционно применяются для удаленной работы на LHC.
В курсовой работе написано начальное руководство по работе с CMSSW, которое может послужить отправной точкой для желающих быстро освоить соответствующие программы.
1. Уровневая архитектура компьютерных ресурсов CMS
Вычислительные центры CMS доступны по всему миру и построены в трехуровневой архитектуре, которая функционирует как единая согласованная система. Каждый из трех уровней предоставляет различные ресурсы и сервисы.
Рисунок 1 - Уровневая организация обработки данных на LHC
1.1 Уровень-0 (T0, Tier-0)
Первый уровень в модели CMS физически реализован в одном месте, в CERN. Это - уровень-0 (T0). В T0 выполняется несколько функций. Стандартный рабочий процесс в T0 выглядит следующим образом:
1. исходные данные принимаются из так называемой “CMS Online Data Acquisition (DAQ) and Triger system” (TriDAS);
2. сырые данные (raw data), полученные из DAQ, распаковываются в начальные наборы данных (“datasets”), используя триггерную информацию (“immutable bits”). Грубо говоря, ожидается 10 “datasets” в ране (run) при нынешней суммарной энергии пучков 7 ТэВ;
3. переупакованные сырые (raw) данные записываются на ленту;
4. сырые данные распространяются на следующий уровень (Tier-1) так, что две копии каждого элемента сырых данных сохраняются, одна в CERN, другая в Tier-1;
5. выполняется быстрая (“promt”) калибровка, чтобы получить калибровочные константы, необходимые для запуска реконструкции;
6. сырые данные пересылаются для реконструкции;
7. выполняется первую реконструкции и RECO-данные и объект для анализа данных (AOD) записываются в память;
8. распределяет RECO данные между Tier-1 центрами, так что сырые данные и RECO данные соответствуют на каждом Tier-1;
9. распределяет AOD во все Tier-1 центры.
T0 не предусматривает анализа ресурсов и работает только по запланированным мероприятия.
T0 сливает выходные файлы, если они слишком малы. Цель CMS - записать соответствующий объем данных на ленту роботов.
Существует система CAF, которая предлагает услуги, связанные с T1 и T2 центрами и выполняет задержку для критической, неавтоматизированной деятельности.
CAF не является необходимым для нормальной работы Т0, он предназначен для краткосрочной калибровки с человеческим управлением с высоким приоритетом и для физической проверки и физического анализа.
1.2 Уровень -1 (T1, Tier-1)
Существует набор из семи T1, которые являются крупными центрами в странах, сотрудничающих с CMS (крупные национальные лаборатории, например, FNAL, и RAL). Tier-1 в целом могут использоваться для крупномасштабных, централизованно организованных мероприятий и могут предоставлять данные в Tier-2 и получать данные со всех Tier-2. Каждый T1-центр:
1. получает подмножества данных из T0, связанных с размером предоставляемых ресурсов;
2. обеспечивает ленточное архивирование части данных RAW (второй экземпляр, для безопасности), которую он получает в качестве подмножества данных из T0;
3. обеспечивает значительные мощности процессора для следующих работ:
ь Re-реконструкция,
ь Скимминг,
ь Калибровки,
ь AOD.
4. хранит полную копию AOD;
5. распределяет RECO, скимминг и AOD для других T1 центров и CERN, а также связывает группы T2 центров;
6. обеспечивает безопасное хранение и перераспределение Монте-Карло-событий, произведнных на T2.
1.3 Уровень - 2 (Т2, Tier-2)
Более многочисленным является множество Т2-центров ("малые" центры в университетах), но с значительными процессорными ресурсами. Т2 обеспечивают потенциал для пользовательского анализа, исследований калибровки, генерирования Монте-Карло-данных. T2-центры предоставляют ограниченное дисковое пространство, а в них нет ленточного архивирования. T2-центры полагаются на T1 для доступа к большими наборами данных и для надежного хранения новых данных (как правило, Монте-Карло), изготовленных на Т2. МС-генерирование из Т2 может быть направлено в соответствующий Т1 для распределение среди CMS сообщества. Вся другая деятельность Т2 будет определяться потребностями пользователей, данными, размещенными на доступных ресурсах, и потребностями: ленты, диски, рабочая сила, потребности местных сообществ. В T2 организуется работа физических групп, региональных ассоциаций и местных сообществ.
Таким образом, уровни -2 обеспечивают:
1. услуги для местных сообществ;
2. анализ по сети на основе GRID, выполняемый для всего эксперимента;
3. Монте-Карло-данные для всего эксперимента.
По состоянию на октябрь '07 было около 36 T2-сайтов (рис. 1), каждый из которых связан с одним из семи T1-сайтов, или непосредственно в CERN.
2. Иерархия CMS данных
CMS данные организованы в иерархии данных уровней. Каждое физическое событие записывается в каждый уровень данных, где уровни содержат различные подуровни информации о событиях. Различные уровни имеют различные применения. Тремя основными уровнями данных, записанных в CMS являются:
1. RAW: полная информация о событии из Т0 (т. е. из ЦЕРН), содержащая "сырые" данные детекторной информации (от чувствительных элементов детектора, и т.д.). RAW-данные не используется непосредственно для анализа;
2. RECO ("RECOnstructed data"): выход из первого прохода обработки Т0. Этот слой содержит реконструированные физические объекты, но они по-прежнему очень подробны. RECO могут быть использованы для анализа;
3. AOD ("данные объектов анализа"): это "дистиллированная" версия событий RECO-информации; как ожидается, будет использоваться для большинства анализов. AOD обеспечивает компромисс между размером событий и сложностью имеющейся информации для оптимизации гибкости и скорости анализа.
Данные этих уровней более подробно описаны в специальной главе о форматах данных и уровнях. Это желание CMS, что данные уровня записываются в отдельные файлы, хотя приложения будут иметь доступ к более чем одному файлу одновременно (приложение может иметь доступ к RECO и к соответствующим событиям RAW, находящимся в отдельных файлах).
Уровни потоков данных детектора распределяются по аппаратным уровням. Следующий рисунок (рис. 2) показывает поток данных детектора CMS через уровни.
Рисунок 2 - Поток данных детектора CMS через уровни
Основные элементы потока реальных физических данных через аппаратные уровни являются:
· Т0 в Т1
ь по расписанию, критично по времени, непрерывно в течение периода набора данных;
ь надежная передача необходима для быстрого доступа к новым данным, и с гарантией, что данные хранятся безопасно.
· Т1 в Т1
ь распределение данных, как правило, после обработки (например, обработка с улучшенными алгоритмами).
· Т1 в Т2
ь Данные для анализа на уровне 2.
Монте-Карло генерируемые данных, как правило, производятся в Т2 центрах, и архивируются на T1 (рис 3), что делает их доступными для всего сообщества CMS.
Рисунок 3 - Поток данных детектора доступными для CMS
3. Вычислительные рабочие процессы на CMS
Рабочий процесс может быть описан просто как то, "что мы делаем для данных". Есть три основных области документооборота в CMS:
1. В центрах T2: генерируются Монте-Карло события, моделируется отклик детектора, события реконструированы таким же образом, как будут применяться к данным, и события затем перемещаются в ленточные системы хранения для последующего использования;
2. В центрах T0: данные, полученные из детектора CMS, "перепаковываются" - то есть события от несортированных онлайн потоков отсортированы в физические потоки событий с аналогичными характеристиками. Запускается алгоритм реконструкции, производится AOD, RAW, RECO и AOD экспортируются в T1-центры;
3. Пользователь (то есть вы!) подготавливает коды анализа, отправляет код на сайт, где есть соответствующие данные, а затем запускает код на данные и организует сбор информации о результатах.
4. Поток данных от детекторов для анализа
Для обеспечения наиболее эффективного доступа к CMS данным, данные должны быть сначала разделены на физические наборы данных (PDs), а затем они фильтруются как события.
Разделение на физические наборы данных производится, основываясь на триггерных решениях. Первичные данные составлены и размещены так, чтобы сделать жизнь как можно проще, например, для того чтобы свести к минимуму необходимость среднему пользователю работать с очень большими объемами данных. Наборы данных группируются или разделяются триггером в целях достижения баланса в их размере.
Однако первичный наборов данных будет слишком большим, чтобы сделать прямой доступ пользователей разумным или даже возможным. Основная стратегия в борьбе с таким большим количеством событий, это фильтровать их, и сделать в слоях более жесткий отбор событий. В конце концов, триггер 1-го уровня и HLT делают то же самое в онлайн.
Процесс отбора событий и сохранения их на выходе называется “скимминг”. Получаемый набор событий называют “ским”. Предполагаемые моды операций групп CMS-анализа следующие:
1. первичный набор данных и производство скимов; они определяются с помощью триггера (для устойчивости) и производятся централизованно в системе Т1;
2. вторичные скимы производятся физическими группами (скажем группа Хиггса), двигаясь по первичным скимам, вторичные скимы, как правило, производятся членами группы, работающих на кластерах Т2, привязанными к данной группе;
3. при желании пользователь затем еще раз может выполнить скимминг, применяя все более жесткий отбор событий;
4. окончательный результат (с почти окончательными обрезаниями) может быть проанализирован программой FWLite. Он также может быть проанализирован полным фрэймворком, однако мы рекомендуем использовать FWLite, так как он интерактивный и гораздо более портативный.
Первичные скимы (шаг 1) уменьшают размер первичного набора данных с целью сокращения времени последующих слоев скимминга. Цель первичных скимов является сокращение в 10 раз размера по отношению к первичным данным.
Вторичные скимы (шаг 2) должны быть достаточно жесткими, чтобы сделать вторичные скимы допустимыми с точки зрения размера. И все же они не должны быть слишком жестким, так как иначе для определенных анализов может оказаться катастрофическая нехватка данных. Однако, в этом случае понятие “жесткости” зависит от типа анализа и в нем “жизненно” заинтересованы члены группы, вовлеченные в анализ этих вторичных скимов.
Пользовательский отбор (шаг 3) осуществляется пользователем в Т2, и это - основная возможность для сокращения размера результатов, с которыми пользователь будет иметь дело. Во многих случаях, где будет сделан предварительный отбор событий, он и будет является основой анализа. Ожидается, что пользователю может потребоваться повторно запустить этот шаг (например, в случае обнаружения, что сокращения были слишком плотными), но это не проблема, так как третичные скимы в настоящее время работают на вторичных скимах, которые уже уменьшены в размерах.
Как сказано, важно настроить пользовательские скимы как можно ближе к тому, что нужно прямо сейчас: отбор событий должен быть слабее, чем сокращение, которое будет после окончательной оптимизации, но и не слишком свободным - в противном случае скимминг не будет служить своей цели. Если все сделано правильно, то это не только сэкономит время, но и сохранит коллаборационные ресурсы.
5. Сокращение размера событий: CMS форматы данных и форматы Тир-данных
В дополнение к сокращению числа событий, с шагами 1-3 можно также уменьшить размер каждого события:
· удалив ненужные коллекции (например, после того как мы сделаем PAT-кандидаты, использованная информация для большинства целей для AOD не нужна); это называется стрипингом и слимингом;
· удаления ненужной информации из объектов; это называется “синнинг” (thinning). Это сложный вопрос, и еще экспериментальный и не охваченный здесь.
Стрипинг, слиминг и синнинг в контексте анализа будут обсуждаться подробнее ниже.
Начиная с выходных данных детектора ("сырые" данные), информация уточняется, а что не нужно опускается. Это определяет CMS Тиры данных. Каждый бит данных в событии должен быть записан в поддерживаемом формате данных. А формат данных это по существу С++ класс, где класс определяет структуру данных (тип данных с данными-членами). Термин формат данных может быть использован для обозначения формата данных, записанных с помощью класса (напр., формат данных, как своего рода шаблон), или экземпляр класса самого объекта. Пакет DataFormats и пакет SimDataFormats (для моделированных данных) в CMSSW CVS репозитории содержат все поддерживаемые форматы данных, которые могут быть записаны в файл события. Так, например, если вы хотите добавить данные события, ваш Edproducer модуль должен обрабатывать один или несколько из этих классов форматов данных.
6. Данные Тиров после реконструкции (RECO) и AOD
Информация о событии от каждого шага в цепи моделирования и реконструкции логически сгруппированы в то, что мы называем Тир-данными. Тир-данные могут содержать множество форматов данных, для реконструкции данных. Конкретный набор данных может состоять из нескольких Тир-данных, например термин GenSimDigi включает генерирование (Mонте-Карло), моделирование (Geant) и шаги оцифровки. Наиболее важные Тиры с точки зрения физики это RECO (все реконструированные объекты и хиты) и AOD (меньший набор RECO, который необходим при анализе).
RECO данные содержат объекты со всех этапов реконструкции. AOD данные получаются из данных RECO и предоставляют данные для физического анализа в удобном и компактном формате. Как правило, физические анализы не требуют проведения повторного процесса реконструкции. Большинство физических анализов могут работать с AOD данными.
6.1 RECO (Reconstruction)
RECO это имя Тира данных, который содержит объекты, созданные в рамках программы реконструкции событий. Он является производным от исходных данных и обеспечивает доступ к реконструированным физическим объектам для физических анализов в удобном формате. Реконструкция событий состоит из нескольких иерархических шагов:
1. Обработка определенная детектором: начиная с распаковки и декодирования данных детектора, применяются константы калибровки детекторов и реконструируются кластерные и хитовые объекты;
2. Трекование: хиты в силиконовых и мюонных детекторах используются для восстановления глобальных треков. Распознавание образов в трекере являются наиболее ресурсоемкими задачами;
3. Вертексинг: реконструирует кандидаты на первичные и вторичные вершины;
4. Идентификация частиц: производит объекты наиболее связаные с физическими анализами. Создаются стандартные физические объекты, используя широкий спектр алгоритмов (электроны, фотоны, мюоны, объекты потерянной поперечной энергии, струи; распад тяжелых кварков, -распад).
Нормальное завершение задачи реконструкции даст в результате полный набор этих реконструированных объектов, применимых CMS-физиками в физических анализах. Вам нужно будет только перезапускать эти алгоритмы, если ваш анализ требует принимать во внимание такие вещи, как другую калибровку, новые алгоритмы и т.д.
Реконструкция является дорогой с точки зрения CPU, а трекование доминирует в реконструкции. Данные Reco обеспечивают компактную информацию для анализа, чтобы избежать необходимости доступа к сырым данным для большинства анализов. После иерархии реконструкции событий, RECO будут содержать объекты со всех этапов реконструкции:
· На самом низком уровне он будет реконструировать хиты, кластеры и сегменты;
· На основе этих объектов сохраняются реконструированные треки и вершины;
· На высшем уровне сохраняются реконструированные струи, мюоны, электроны, b-струи и т.д.
Прямая ссылка от объектов высокого уровня к объектам с низким уровнем будет возможна, чтобы избежать дублирования информации. Кроме того RECO будет сохранять ссылки на сырую информацию. RECO включает величины, которые необходимы для шаблона типичного анализа, таких как: повторный поиск треков, перегруппировка кластеров в калориметре, и калибровки энергии струи.
6.2 AOD (Analysis Data Object)
AOD данные получены из RECO и представляют собой данные удобные для анализа в физике, в компактном формате. AOD данные могут использоваться непосредственно в физическом анализе. AOD данные будут получаться по тем же или последующим шагам процесса обработки как и для получения RECO-данных; и AOD данные будут легко доступны на нескольких сайтах CMS-членов. AOD будет содержать достаточно информации о событии, чтобы поддерживать все типичные шаблоны физических анализов.
Таким образом, он будет содержать копию всех физических объектов высокого уровня (таких, как электроны, мюоны, тау-лептоны, и т.д.) плюс резюме RECO-информации достаточное для поддержки типичных действий анализа, таких как повторное фитирование треков с улучшенным сшиванием или кинематическими ограничениями, переоценка энергии или положение ECAL-кластеров, основанное на поправках определяемых типом анализа. AOD, из-за ограниченного размера, что не позволит ему содержать все хиты, как правило, не поддерживают ни применение новых методов распознавания образов, ни применение новых констант калибровки, которые, как правило, требуют использования RECO- или RAW-информации.
AOD Тир данных будет содержать физические объекты: треки с соответствующими хитами, калориметрические кластеры с соответствующими хитами, вершины, струи и физические объекты высокого уровня (электронов, мюонов, кандидатов в Z бозон, и так далее). Вследствие того что AOD Тир данных относительно компактный, все вычислительные центры Тир-1 в состоянии сохранить полную копию AOD, в то время как он будет содержать только подмножество сырых и RECO данных.
формат уровневый архитектура компьютерный
6.3 PAT (Physics Analysis Toolkit)
Информация хранится в RECO и AOD таким образом, что она использует наименьшее количество пространства и позволяет большую гибкость. Это особенно верно для DataFormats, которые содержат объекты, которые связаны друг с другом. Однако, доступ к связям между RECO или AOD требует большого опыта работы с C++. Для упрощения анализа пользователя, набор новых форматов данных создаются, как совокупность информации RECO. Эти новые форматы, а также инструменты, используемые для посылки и манипулирования ими, называются Physics Analysis Toolkit, или PAT. Содержание PAT является гибким - это позволяет пользователям определить его. По этой причине, PAT не Тир данных. Содержание PAT может меняться от одного анализа к другому, не говоря уже от одной PAG (group) к другой. Однако PAT определяет стандарт для физических объектов и переменных, хранящихся в этих физических объектах. Это как меню в ресторане - каждый пользователь можете выбрать различные вещи из меню, но каждый читает из того же меню. Это облегчает обмен обоих инструментов и людей между анализами и физическими группами.
6.4 Групповые и пользовательские скимы: RECO, AOD и PAT
Почти во всех случаях первичный ским будет читать AOD и производить AOD с сокращением числа событий. (В физике начального ввода в работу, основной ским может также читать и писать RECO вместо AOD). Пользовательский и групповой ским может также читать и писать AOD (или RECO). Однако, они могут также производить PAT, в соответствии с решением группы или пользователя. В качестве иллюстрации, эти шаги могут быть:
1. первичные скимы читает AOD, записывает AOD;
2. широко-групповые скимы фильтруют события в AOD и производят PAT с подробной информацией (их называют иногда PAT-таплы, они нужны, чтобы выполнить многие сложные работы внутри группы);
3. пользователь модифицирует PAT процесс, чтобы читать PAT и производить другую версию PAT, но с гораздо меньшим содержанием (стрипинг, слиминг), и, возможно, даже сжатые PAT объекты (синнинг).
Все взаимосвязанные операции - скимминг, стрипинг, и синнинг - делают полный Framework. Таким образом, каждый пользователь должен хотя бы знать, эти рабочие места в каждом из шагов, даже если не нужно вносить никаких изменений в любом из этапов обработки. Однако, более вероятно, что некоторые изменения будут необходимы, особенно на последнем этапе, где скимминг и дальнейшая обработка, делается пользователем. В некоторых случаях пользователю может даже нужно записать Framework modules like EDProducers - добавлять новые DataFormats.
7. КОМПЬЮТЕРНЫЕ И ПРОГРАММНЫЕ СРЕДСТВА ДЛЯ АНАЛИЗА ДАННЫХ НА LHC
7.1 Средства удаленной работы на LINUX машинах в CERN: PUTTY, WinSCP и Xming
Многие работы по анализу данных, послупающих с LHC, будут выполняться удаленно. В условиях ГГУ имени Франциска Скорины мы имеем Windows-компьютеры. В то время как в CERN компьютеры работают под управлением OS Linux. Возникает проблема организации взаимодействия удаленных компьютеров, которая усложняется тем, что на компьютерах используются разные операционные системы. Мы здесь опишем схему организации удаленной работы, которая является стандартной и используется повсеместно для анализа данных на LHC. Предварительно, опишем общее состояние вопроса о взаимодействии двух операционных систем - Linux и Windows.
Нас интересует два типа взаимодействия между компьютерами:
· удаленный рабочий стол (в широком смысле слова), то есть, возможность работать с удаленной системой так, как если бы ваши монитор и клавиатура были подключены к этой системе;
· возможность передачи файлов и другой информации между двумя системами.
В идеале нам бы хотелось, чтобы эти возможности были интегрированы в одной программе, но пока что такого идеального решения не существует.
В арсенале Linux и Windows накопилось немало различных средств взаимодействия с другими компьютерами, но проблемы стыковки двух платформ требуют зачастую нетривиальных решений. Причина заключается в принципиально различных подходах к созданию средств взаимодействия на упомянутых платформах.
Linux изначально разрабатывалась как многопользовательская система с возможностью удаленного подключения, как в текстовом, так и в графическом режиме.
Windows в основе своей всегда была системой персонального, ни с чем не связанного, компьютера. Средства взаимодействия по локальной сети всегда шли в виде своего рода «довеска» (вспомните Windows 3.11 for Workgroups, специальные сетевые расширения Windows 95, или, хотя бы, взгляните на линейки последних версий Windows, где полноценные средства взаимодействия с другими компьютерами доступны только в старших и наиболее дорогих изданиях).
Кроме того, Linux всегда опиралась на открытые протоколы, большая часть которых является стандартом в мире Unix-систем. Microsoft, напротив, делает ставку на собственные протоколы, естественно, закрытые и не всегда совместимые со своими предыдущими версиями. Те, кто пишет программы для работы с Linux из-под Windows, работают с открытыми стандартами и спецификациями, а тем, кто решает обратную задачу, приходится нередко заниматься обратной инженерией.
Проблема безопасного доступа к файлам, расположенным на Linux-компьютере из-под Windows вполне решаема.
Для передачи файлов между двумя Linux-машинами используют обычно программу SFTP. SFTP работает «прямо из коробки» практически в любом дистрибутиве Linux (тогда как FTP, например, надо еще устанавливать и настраивать). Кроме того SFTP, в основе которого работают и протоколы SSH, - один из самых безопасных способов передачи информации по сети. Решение, таким образом, напрашивается само собой - установить на компьютер под управлением Windows клиент SFTP и получить безопасный доступ ко всем потенциально доступным файловым ресурсам Linux.
Среди всех клиентов SFTP для Windows обычно выбирают WinSCP. Название программы может ввести в заблуждение. SCP протокол, предназначенный исключительно для передачи файлов, тогда как SFTP может выполнять и другие операции с файловой системой удаленного ПК, на самом деле WinSCP поддерживает и SCP, и SFTP.
WinSCP - самый популярный клиент SFTP/SCP для Windows. И популярность эта вполне заслужена. Программа обладает интуитивно понятным интерфейсом (поддерживаются два варианта интерфейса - в стиле Проводника Windows и в стиле папок Рабочего стола). WinSCP позволяет создать несколько профилей для подключения к разным компьютерам. В профиль можно записать адрес удаленной системы, специальные параметры подключения, имя пользователя удаленной системы и даже пароль (не лучшее решение с точки зрения безопасности), так что позднее для соединения с удаленным ПК вам может потребоваться буквально один щелчок мышью. Программа интегрируется с клиентом SSH PuTTY, при условии, что он установлен в системе.
Для того чтобы получить графическую картинку в удаленном режиме на машине Windows, нужно чтобы наша ОС могла преобразовать графику из Linux в графику Windows. На Linux используется графический протокол X-window. Чтобы Windows понимала этот протокол нам нужно установить на Windows “X-window сервер”.
Наш выбор - “Xming X Server for Windows”. Это бесплатный стабильный X сервер для Windows. Распространяется Xming в виде exe-файла. Он не использует никакие библиотеки и установка не нужна.
Запускаем Xming. На нижней панели появится значек в виде буквы Х, что означает, что Ваша машина готова принимать графику из Linux. Мы будем использовать ту же программу Putty для работы в графическом режиме. Для передачи графики Putty нужно настроить:
1. Запускаем Putty;
2. Слева в разделе Session записываем host-name и порт;
3. Идем в раздел SSH и раскрываем его;
4. В окне слева ставим курсор на пункт Х11;
5. В окне справа появится “Enable X11 forwarding”. Ставим галочку;
6. Если Вы выполнили пункт 2 (host-name определен), то в поле X-display location может появиться “localhost:0”. Без этой записи также можно работать - эта запись подразумевается по умолчанию. Эта запись означает, что удаленная картинка должна приходить на Ваш локальный компьютер, а не “в Америку”;
7. Нажимаем клавишу Open: получаем приглашение Linux. Регистрируемся как обычно.
Мы готовы к работе. Проверяем это:
Ш xterm &
Получаем Х-терминал - это терминал, полученный путем передачи графической картинки. Он отличается от текстового терминала Putty - он белый по цвету фона. Работа на нем - обычная, только трафик больше.
7.2 Пакет ROOT
Основным средством анализа данных на LHC является пакет ROOT. Пакет ROOT является объектно-ориентированным аналогом библиотеки программ CERNLIB, который широко применялся в физике высоких энергий и далеко за ее пределами в 80-х и 90-х годах. Качество этого продукта предопределено тем, что основным автором его является Рене Бран, который написал основные подпакеты CERNLIB: HBOOK, ZEBRA, PAW, PAW++, GEANT3.
Для удаленной работы ROOT можно инсталлировать на Linux или Windows.
Linux - среда родная для ROOT.
Для инсталляции можно использовать компилированный пакет для определенной архитектуры, или исходники, если под Вашу архитектуру нет бинарного дистрибутива. Мы работаем удаленно и на удаленных машинах в Дубне и в CERN пакет установлен.
Поэтому нам нужно только найти его месторасположение - оно определяется переменной окружения ROOTSYS:
Ш echo $ROOTSYS
Ш cd $ROOTSYS
Чтобы правильно настроить ROOT лучше всего использовать готовый скрипт:
Ш source bin/thisrot.sh (только для bash)
Ш source bin/thisrot.csh (только для tcsh, csh)
Теперь, где бы Вы не находились - в любом месте можно запустить ROOT, введя команду
Ш root
Конечно, перед этим необходимо иметь X-сервер на Вашей машине (то есть запустить Xming). Через 5 секунд получаем стартовый экран-загрузки с информацией (заставка). Запуск ROOT без этого стартового окна:
Ш root -l
Чтобы запуск прошел быстрее, нужно указать опцию (b - batch, пакетный режим, работа без графики):
Ш root -b
root[0]
Интерпретатор ROOT-команд готов к работе.
ROOT можно использовать как в режиме интерпретатора команд (или макросов), или в режиме обычной so-библиотеки (so - “shared object”, совместно используемая библиотека).
7.3 “ROOT” и “Visual C++ 2010” в OC Windows
На cайте ROOT в разделе загрузки
root.cern.ch Download Pro, version 5.28/00
находим информацию о запуске ROOT в Windows: поддерживаются ОС Windows 7/Vista/XP/NT/2000. Предлагается обычный инсталляционный пакет для Windows - MSI. Этот пакет также устанавливает переменные окружения. Деинсталлировать можно с помощью "Control Panel"/"Add or Remove Programs".
Для инсталляции ROOT в Windows просто загрузите и стартуйте пакет (двойной клик мышкой на пакете). Однако, до этого необходимо иметь установленным пакет Visual C++:
MS VC++ 7.1 для ROOT-дистрибутива “VC++ 7.1”;
MS VC++ ? 8 для ROOT-дистрибутива “VC++ 9”;
MS VC++ 10 для ROOT-дистрибутива “VC++ 10”.
Бесплатную версию можно скачать с сайта Visual Studio.
Нам предлагается дистрибутив ROOT в бинарном виде - то есть уже откомпилированные библиотеки: root_v5.28.00c.win32.vc10.msi . Этот файл инсталлируется стандартно для Windows. Но прежде нужно установить Visual C++, например 2010.
Оказывается, что можно не устанавливать полный пакет VC++. Нам предлагается пакет “Microsoft Visual C++ 2010 Redistributable Package (x86)”. Его краткое описание такое: “Microsoft Visual C++ 2010 Redistributable Package устанавливает компоненты среды выполнения Visual C++, необходимых для запуска приложений, разработанных с Visual C++ на компьютере, который не имеет установленного Visual C++ 2010”.
Для интерактивной работы с ROOT нам этого должно быть достаточно. Скачиваем пакет “Microsoft Visual C++ 2010 Redistributable Package” (4.5 Мб) и устанавливаем его. После этого кликнем мышкой на root_v5.28.00c.win32.vc10.msi (54.5 Мб). После установки пакет занимает 340 Мб. На панели мы получаем значек
Кликнем на значке и получаем приглашение интерактивного ROOT:
C таким пакетом VC++ мы не сможем писать batch-программу с применением ROOT, но интерактивные скрипты работают в полном объеме. Например, Вы увидите ниже, что ROOT способен загрузить геометрию детектора ATLAS/LHC и отобразить ее на Вашем компьютере в ROOT-браузере.
Для того, чтобы писать полноценные batch-программы, нужно установить Visual Studio, который включает VC++.
7.4 Фрэймворк CMSSW
Framework является основным инструментом CMS для обработки данных, и, таким образом, тесно связывает анализ пользователя несколькими способами:
1. Он используется для получения данных пользовательского анализа: в HLT, реконструкции, скиминг;
2. Он использует PAT- таплы производства в групповых и пользовательских скимах;
3. Это также может быть использовано для создания гистограмм и графиков;
4. Он может быть использован пользователем для дальнейшей корректировки содержания PAT файлов, используемых в анализе.
CMS Framework идеально подходит для создания и наполнения множества гистограмм, которые могут быть использованы для отслеживания того, что происходит в случае обработки. Гистограммы производится таким образом, что могут быть использованы для быстрого определения, является ли работа правильной и имеет ли смысл выходной файл. Это также может быть распространено на более подробные проверки. В самом деле, Full Framework представляет собой прекрасный инструмент для создания многих известных участков.
Fireworks это проект отображения CMS-событий и cmsShow это официальное название исполняемого файла. Оба названия являются взаимозаменяемыми.
Ядро Fireworks построено на вершине EDM (Event Data Model) и облегченной версии программного обеспечения базы (FWLite).
Среда визуализации события (EVE) от ROOT используется для управления 3D и 2D просмотрами и для взаимодействия пользователя с графикой Windows.
Некоторые компоненты EVE были разработаны в сотрудничестве Fireworks и ROOT. В случае операции отображения простые плагины регистрируются в системе, чтобы выполнить преобразование из EDM коллекций в их визуальное представление. В качестве руководящего принципа, Fireworks показывает только то, что доступно в EDM данных события. Видимости элементов коллекции могут быть отфильтрованы с помощью общего выражения (PAT анализатор предназначен для внутреннего использования).
При запуске в автономном режиме (как cmsShow) Fireworks считывает данные из файла EDM ROOT (или набор файлов). Удаленный доступ к файлам возможен для castor, dcache, http, и xrootd. Гибкая фильтрация событий поддерживает управление наборa фильтров, которые могут быть включены, выключены. TTree::Draw предназначен для внутреннего использования, чтобы выбрать событие соответствующее выражению отдельной фильтрации. Возможны полная навигация по событию, прямой доступ к событию путем предоставления ID рана (run), светимости(lumi) и события (event).
При запуске полного CMSSW framework (как cmsShowFF) данные считываются из памяти edm::Event после стандартного событийного завершения обработки. Пользователь может исследовать зарегистрированные пути, модули и статус их выполнения. Кроме того, параметры модуля могут быть изменены, и обработка может повториться с измененными параметрами. Минимальная событийная навигация поддерживается, а событийная фильтрация не поддерживается в этом режиме.
Следующие рекомендации сделают Fireworks доступным для всех:
· Отображения события - не ежедневные bycnhevtyns, интерфейс программы оптимизирован для интуитивно понятного и простого использования;
· 3D-ускоритель рекомендуется, но не обязателен. Новое отображение событий регулярно используется и тестируется на неускоренном компьютере, чтобы убедиться, что производительность является разумной;
· Распространяется также как “stand alone” плэйер со всеми необходимыми компонентами: не нужно удаленное использование X11.
Fireworks доступен как часть CMSSW версии и в виде отдельного архива. Отдельная опция доступна как для linux, (built on SLC5 but should run on all Linux distributions) так и MacOSX. Все необходимые компоненты, включая соответствующую версию ROOT, расположены внутри архива.
ПРИМЕЧАНИЕ Отображение работает только для данных файлов, созданных с CMSSW релизов которые совместимы с форматами данных. Если форматы данных не совместимы, следует использовать cmsShow версии выше или равной версия CMSSW используемой для производства EDM файлов.
Использование cmsShow зависит от выпуска CMSSW. Fireworks интегрирован в CMSSW начиная с выпуска CMSSW_3_1_0_pre6. Чтобы запустить cmsShow, установить и запустить среду cmsShow с вашим сэмплом, небходимо выполнить команду:
cmsShow data.root
В ЦЕРНЕ можно запускать следующую последовательность команд:
cd /afs/cern.ch/cms/slc5_ia32_gcc434/cms/cmssw/CMSSW_3_9_5
eval `scramv1 runtime -csh` # or -sh if use bash
cd /tmp
cmsShow rfio:/castor/cern.ch/cms/store/relval/CMSSW_3_9_5/RelValTTbar/GEN-SIM-RECO/MC_39Y_V6-v1/0009/14F2D01A-9BFA-DF11-8B0F-0018F34D0D62. Root
Зарегистрируемся удаленно на Linux-кластере lxplus.cern.ch и выполним запуск CMSSW, согласно инструкции описанной в руководстве.
Переходим в соответствующую директорию:
cd /afs/cern.ch/cms/slc5_ia32_gcc434/cms/cmssw/
cd /afs/cern.ch/cms/slc5_amd64_gcc434/cms/cmssw/
cd CMSSW_4_2_2
Запускаем команду:
eval `scramv1 runtime -csh` # or -sh if use bash
cd /tmp
cmsShow rfio:/castor/cern.ch/cms/store/relval/CMSSW_3_9_5/RelValTTbar/GEN-SIM-RECO/MC_39Y_V6-v1/0009/14F2D01A-9BFA-DF11-8B0F-0018F34D0D62.root
Рисунок 4 - запуск
Ошибка связана с загружаемым root-файлом. Если скопировать файлы в рабочую директорию, то ошибка исчезает, однако проблемы передачи графических картинок остаются. Нами был получен графический экран вида:
Рисунок 5 - графический экран
После загрузки этого экрана происходит сбой в программе.
Следующий шаг может состоять в локальном использовании “stand-alone” версии smsShow.
Несколько сеансов работы с программой ROOT в графическом режиме также показали неустойчисовость связи при передаче картинок.
Таким образом, основной способ работы при современном состоянии линий связи может быть такой: написание batch-программ и удаленный запуск этих программ в среде Linux. Результаты работы - ROOT-файлы - можно скачивать на локальную Windows-машину и анализировать файлы локально с примененем ROOT.
ЗАКЛЮЧЕНИЕ
Таким образом, в курсовой работе систематизирована информация из базовых частей руководства пользователя для CMSSW. Выполнен перевод основных частей документации по CMSSW. Перевод оформлен в виде Word-документа. В таком виде этот документ можно рассматривать как источник первого предварительного знакомства с CMSSW, позволяющее быстро войти в курс дела.
Изучены средства удаленного доступа на Linux-компьютеры в CERN: установка и использование “Xming X-Window server”, putty и WinSCP.
С применением удаленного доступа на Linux-компьютеры в CERN выполнены некоторые тестовые операции с использованием Framework CMSSW.
Показано, что полноценная удаленная работа в графическом режиме в настоящее время невозможна, ввиду слабости линий связи. Сделан вывод, что в настоящих условиях схема работы с данными может быть такой: написание и удаленный запуск программ в пакетном режиме с применением предустановленного удаленного пакета CMSSW (с помощью Putty), перенос полученных файлов с результатами на локальгую машину и анализ этих файлов на локальной машине с помощью ROOT.
Руссифицированная документация по CMSSW размещена на сайте CMS/GSU-группы.
Результаты работы опубликованы в статье [3].
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
1. Е.С. Ковалева, Н.С. Потапенко. СОЗДАНИЕ САЙТА CMS/LHC-ГРУППЫ В ГГУ. …Сборник … 2011 (в печати).
Приложение
Иконка Xming - сервера на локальной Windows-машине
Настройка Putty для терминала в ОИЯИ (Дубна)
Putty-терминал в ЦЕРН (Женева, Швейцария)
X-терминал, полученный из ЦЕРН с помощью Xming-сервера на локальной Windows-машине
Две панели программы WinSCP: левое окно - локальный Windows-компьютер, правое окно - lxplus-машина в ЦЕРН.
Запуск программы ROOT в интерактивном режиме на локальной Windows-машине
Запуск программы ROOT в интерактивном режиме на Linux-машине в ОИЯИ (Дубна, Россия)
Просмотр ROOT-файла с реальными данными с помощью ROOT-браузера на локальной машине
Размещено на Allbest.ur
Подобные документы
Построение банков данных. Инструментальные средства баз данных Borland. Принцип работы и архитектура баз данных в Delphi. Навигационный способ доступа к базам данных: операции с таблицей, сортировка и перемещение по набору данных, фильтрация записей.
курсовая работа [642,7 K], добавлен 06.02.2014Концепции хранилищ данных для анализа и их составляющие: интеграции и согласования данных из различных источников, разделения наборов данных для систем обработки транзакций и поддержки принятия решений. Архитектура баз для хранилищ и витрины данных.
реферат [1,3 M], добавлен 25.03.2013Термины "логический" и "физический" как отражение различия аспектов представления данных. Методы доступа к записям в файлах. Структура систем управления базами данных. Отличительные особенности обработки данных, характерные для файловых систем и СУБД.
лекция [169,7 K], добавлен 19.08.2013Автоматизация сбора и обработки данных. Основы, таблицы и средства для работы с базами данных. Инструментальные средства и компоненты. Технология создания приложения. Работа с псевдонимами и со связанными таблицами. Система управления базами данных.
методичка [1,5 M], добавлен 06.07.2009Типы изображений (черно-белые, полутоновые, цветные) и их форматы. Устройства, создающие цифровые изображения, и их параметры. Применение и характеристики методов сжатия изображений. Поиск по содержимому в базах данных изображений. Структуры баз данных.
презентация [360,4 K], добавлен 11.10.2013Основные понятия базы данных. Разработка сложной формы для обработки данных. Модели организации данных. Архитектура Microsoft Access. Реляционные связи между таблицами баз данных. Проектирование базы данных. Модификация данных с помощью запросов действий.
лабораторная работа [345,5 K], добавлен 20.12.2011Основные классифицирующие признаки системы управления базами данных. Модель данных, вид программы и характер ее использования. Средства программирования для профессиональных разработчиков. Организация центров обработки данных в компьютерных сетях.
презентация [6,8 K], добавлен 14.10.2013Обзор существующих решений на основе открытых данных. Технологии обработки данных и методы их визуализации. Социальные сети для извлечения данных. Ограничение географической локации. Выбор набора и формат хранения открытых данных, архитектура системы.
курсовая работа [129,5 K], добавлен 09.06.2017Вечное хранение данных. Сущность и значение средства OLAP (On-line Analytical Processing). Базы и хранилища данных, их характеристика. Структура, архитектура хранения данных, их поставщики. Несколько советов по повышению производительности OLAP-кубов.
контрольная работа [579,2 K], добавлен 23.10.2010Расмотрение системы распределенной обработки данных подсистемы "Ведомственная статистика" АИС ФССП России. Основные формы отчётности, производимые подсистемой. Форматы передачи данных. Окно выгрузки шаблона отчетной формы. Тестирование системы приложения.
отчет по практике [879,5 K], добавлен 21.11.2014
