С 14 февраля 2013 года Большой Адронный Коллайдер (БАК) закрыт на модернизацию и апгрейд существующих детекторов. А что делает БАК, когда не работает? О нюансах обработки данных самого масштабного научного эксперимента в истории рассказывает сотрудник ФИАН Руслан Машинистов

    Старший научный сотрудник лаборатории элементарных частиц ФИАН Машинистов Руслан Юрьевич с 2005 года вместе с Игорем Леонидовичем Гавриленко работает в группе программного обеспечения трекинга в эксперименте ATLAS на Большом Адронном Коллайдере над проектом адаптации кода для использования многоядерных процессоров. От эффективности и корректности разрабатываемого ими программного обеспечения напрямую зависит и качество будущих исследований. А, следовательно, и судьба возможных будущих открытий. Мы попросили Руслана рассказать о важности и особенности проводимых ими разработок, их месте в эксперименте.

    Руслан, расскажите, чем занимаются исследователи во время этого перерыва в работе Коллайдера?

    Работы не меньше, чем во время экспериментов! Коллайдеру требуется не только капитальный ремонт, но и апгрейд инфраструктур - подводящих систем детекторов, программного обеспечения (ПО) для обработки данных. Так, одно из направлений модернизации связано с возможностью использования многопроцессорных и многоядерных вычислительных систем. Ведь у нас постоянно растёт эффективность ускорителя, что увеличивает наложение событий и, соответственно, сложность разных стадий обработки данных. Например, реконструкции и трекинга. 

     Что означают термины «реконструкция» и «трекинг»?

    Реконструкция – это процесс получения из «сырых» данных от различных датчиков и детекторов информации о физических частицах, их свойствах и траекториях. Он включает в себя несколько этапов. Первый – это оцифровка данных, а второй – как раз тот самый трекинг: восстановление траекторий движения (или треков) элементарных частиц внутри детектора. С точки зрения ПО, трек – это математическая модель пути, которая задаётся пятью параметрами и определяется по координатам точек, где частица пересекает различные датчики детектора. Поэтому первые два параметра – глобальные координаты датчика в геометрическом пространстве, а другие два – координаты локальные, координаты точки, где трек пересёк детектор в его системе координат. Эта система координат может быть декартовой, сферической, цилиндрической. Одним словом, привязана к геометрии детектора. И, наконец, пятым параметром идёт отношение заряда к значению поперечного импульса.

   Получается, что детекторы в этих экспериментах считаются некими идеальными приборами, которые только регистрируют траекторию частиц и никак на неё не влияют?

    Нет-нет, детекторы влияют и это учитывается. Ведь есть эффект взаимодействия с материей. Частица пересекает различные детекторы из различных материалов, теряет импульс и отклоняется от траектории. С этим связан один из самых сложных моментов обработки, который называется калибровкой детектора. С одной стороны, обладая одной точкой трека, мы можем предсказать, в каком месте частица пересечёт следующий детектор. А с другой, мы потом получаем отличные от предсказанных координаты из детекторного сигнала. И реальное значение где-то посередине, а в процессе калибровки мы как раз делаем так, чтобы наше моделирование начальных данных и сигналы с детекторы давали максимально близкие координаты.

    А когда мы сможем определить: вот эта пролетевшая частица – это электрон или протон?

    После трекинга мы ещё только понимаем, что какая-то частица летела по какой-то траектории. У неё может быть заряд, по сути, положительный или отрицательный. Дальше, за трекингом идёт реконструкция следующего уровня, когда на выходе мы знаем, что у нас за частица – электрон, мюон или, например протон, и какие у неё параметры.

    Как помогут в решении этих задач многоядерные вычисления?

   Начать надо с того, что сейчас, помимо многоядерных вычислений, существует ещё один подход к вычислительным системам, который пытаются внедрить в экспериментальной физике. Это так называемые графические процессоры, которые по сути представляют многомерную матрицу физических процессоров. Грубо говоря, это вычислительные машины на тысяче независимых процессоров. Насколько я знаю, их уже используют в триггерных системах, которые в реальном режиме времени решают, какие события стоит записывать, а какие отсекать. В остальном в использовании графических процессоров есть серьёзные сложности. Они разработны для решения специлизированных задач, а именно – матричных вычислений. Для этого даже существует свой язык программирования. А потому все гигантские коды нашего современного ПО реконструкции для работы на графических процессорах нужно переводить и оптимизировать. Это нецелесообразно! Поэтому пока оптимальным решением является использование центральных многоядерных процессоров. Хотя и в этом подходе есть свои сложности.

    Главная сложность в том, что код очень гетерогенный, разнообразный. Это часто бывает в таких эпических экспериментах. Ведь код пишется разными людьми и на протяжении долгого времени. В результате, используются разные языки, подходы, базы данных. Например, сейчас 99 % кода написано на C++, а когда вся история только начиналась, около 20 лет назад, основным языком был Fortran. Или другой пример – когда я восемь лет назад только пришёл в эксперимент, наш детектор TRT (Transition Radiation Tracker, Трековый Детектор Переходного излучения – прим. Ред.) ещё был на поверхности и проверялся без магнитного поля. Соответсвенно, все траектории были прямые и под них был написан код обработки. А когда включили магнитное поле, они стали уже спиралеобразными и понадобились новые алгоритмы трекинга.

    И к чему приводит такая изменчивость и неоднородность программного кода?

  В результате, большинство вычислений у нас идут линейным порядком – работает только одно вычислительное ядро, а остальные, получается, простаивают. Поэтому разработчики ПО сейчас стараются оценить старый код с точки зрения того, можно ли его малыми усилиями переработать для осмысленного использования преимуществ многоядерных процессоров. И вот со стороны ФИАН этими задачами  занимаюсь я и И.Л. Гавриленко.

    Расскажите, пожалуйста, подробнее о своей работе

   Вот один из примеров – недавно я решал задачу по упрощению кода, который отвечает за работу с параметрами трека. Как мы помним, их пять – глобальные координаты, локальные координаты и поперечный импульс. И вот в начале был какой-то пакет обработки для треков без заряда. Все линии прямые. А потом включили магнитное поле, и заряды частиц стали важны. Нейтральные частицы летели по прямой, а заряженные по спирали. Поэтому разработчики ПО в самом начале кода сделали такую «вилочку» – либо то, либо то. А потом сказали: «У нас у детекторов могут быть разные поверхности». Значит разные системы локальных координат. Ещё одна «вилочка»! Получается такая большая разветвлённость, а код практически везде одинаковый. Меняется только один-два параметра. В конце 2012 года я составил план по объединению таких разветвлений в единый код. Вот как раз такими задачами мы с Игорем Леонидовичем и занимаемся. Или другой пример: мы взяли ресурсозатратные алгоритмы и перестроили внутренним образом так, чтобы каждый новый трек поступал на освободившееся ядро. Первые наши данные показали непосредственную зависимость снижения времени вычисления от числа ядер. Так что принципиальную возможность переделать код, чтобы он эффективно решался на параллельных вычислительных ядрах, мы показали. Но это только первый шаг! Ведь изменения таких ключевых компонентов кода неизбежно повлекут каскадные изменения в десятках, если не сотнях других программных пакетов эксперимента.

    В последнее время много говорят о распределённых, облачных вычислениях. Будет ли как-то использоваться этот подход в экспериментах на коллайдере?

   Будет, но только в следующем за реконструкцией этапе обработки данных –  физическом анализе, который достаточно независимо выполняется физиками по всему миру. И вот, чтобы снизить нагрузку, делается система глобального распределения GRID, которая позволяет физикам ставить свои задания в очередь и организовывает контролируемый доступ к общим данным – трекам, параметрам частиц и так далее.

    Получается, в этом смысле параллельные вычисления уже давно используются? Только вместе ядер выступают живые люди?

    В этом смысле, конечно. Вообще, вся эта модульная и параллельная система логически вытекает из организации менеджмента и управления ЦЕРН. Ведь здесь есть много больших и почти независимых групп – одна, условно говоря, занимается трекингом, другая – физическим анализом, а третья – обслуживанием детектора. Им даются глобальные задания, которые разбиваются на подзадания для минигрупп и так далее. Даже внутри нашего детектора я, например, занимаюсь пакетом, который отвечает за параметры треков. Кто-то соседний – за такую же работу, связанную с алгоритмами пересчёта координат. А третий человек, например, разбирается с программным описанием геометрии детектора. Очень часто мы все делаем похожие вещи, но в различных частях кода. А чтобы не было такого пересечения, чтобы два человека не делали одну и ту же работу, у нас происходят регулярные «митинги» (от англ. meeting – встреча прим. Ред.), то есть рабочие совещания, где люди закрепляют за собой задачи. Примерно вот такой процесс. Очень распараллеленный и эффективный.  

М. Петров, АНИ «ФИАН-информ»