Grupo de estudos dos Dados Abertos do Experimento ALICE

ALICE: A Large Ion Collider Experiment, um experimento de física de partículas do Large Hadron Collider, CERN

Fonte: http://aliceinfo.cern.ch/Public/ev411_run244918.png

Descrição do Projeto

O projeto visa à familiarização e divulgação das técnicas de análise de dados do experimento ALICE, um dos detectores do LHC, desenvolvido com o objetivo de estudar uma fase da matéria denominada quark gluon plasma. Todo ano, o LHC realiza séries de colisões entre pacotes de núcleos de átomos de chumbo (Pb), que são pesados o suficiente para liberar os quarks contidos dentro de seus prótons e nêutrons e criar novas partículas, ao se chocarem. O detector ALICE recolhe informação de tais colisões, como partes das trajetórias de certas partículas, sua posição inicial e carga. O projeto em questão busca construir conhecimento acerca da forma como são interpretados e utilizados os dados, sendo um dos principais objetivos a elaboração de um sistema de visualização 3D das colisões chumbo-chumbo que serve, sobretudo, para fins didáticos e de aprendizagem.

Tabela de Conteúdos

• Grupo de estudos dos Dados Abertos do Experimento ALICE
  • Descrição do Projeto
  • Tabela de Conteúdos
  • Principais Características
  • Atividades Preliminares
  • Histórico
  • Tarefas
  • Documentação
    • Abordagem do software Aliroot
    • Evolução das partículas no tempo
    • Animação no Blender
    • Histogramas
    • Geometria do detector
    • Elaboração da geometria do detector
    • A função addALICE_Geometry() e as dimensões do detector
      • TPC - Time Projection Chamber
      • EMCal - Electromagnetic Calorimeter
      • ITS - Inner Tracking System
      • TRD - Transition Radiation Detector
    • Automatização das etapas da animação
    • Teste de rendimento da animação
    • Preparo para o PCAD
      • Escrevendo as ações no arquivo log
      • Lendo as ações do arquivo log
    • Abordagem utilizando máquina virtual
  • Próximos Passos
  • Glossário
  • Estudos complementares
  • Contatos
  • Documentos
  • Referências

Principais Características

• Este grupo de estudos utilizará os dados do Experimento ALICE disponíveis no CERN Open Data Portal
• Os eventos estudados englobam princípios da Física de Partículas Elementares e da Teoria da Relatividade Especial.

Atividades Preliminares

Para fins de familiarização com os conteúdos necessários para o entendimento do projeto, são relevantes os arquivos e links disponíveis abaixo.

• Introdução ao Plasma de Quarks e Glúons
  • Vídeo do canal Fermilab
• Introdução ao Detector ALICE
  • The ALICE experiment at the CERN LHC, Journal of Instrumentation, V. 3, N,r 08, p. S08002 (2008)
  • Introdução_ao_Detector_ALICE_-Pezzi__Dez_2017.pdf

Histórico

Tarefas

Abaixo, são descritas as tarefas propostas para o decorrer do projeto, que serão atualizadas na medida em que for obtido maior grau de precisão de seus objetivos. Para conhecer as tarefas correntes, veja a seção "Próximos Passos".

Tarefa 0: Organizar a documentação do projeto.

• Manual do CTA
• Gerenciamento de projetos do CTA - 08 de Julho de 2016

Esta Wiki é feita a partir do Modelo de Documentação Padrão do CTA. O registro dos progressos serão feitos nas Tarefas, enquanto os sumários dos encontros do grupo estarão nos Fóruns.

Tarefa: Familiarização com as ferramentas de análise de dados. Listar opções e documentar procedimentos de uso. Enquanto as ferramentas necessárias para uso dos dados abertos estão descritas no CERN Open Data Portal, pode ser utilizado o Aliroot oficial de análise de dados da colaboração ALICE - cujos links são os dois primeiros abaixo -, apesar de talvez nem tudo estar acessível publicamente.

• Off-line environment

• Getting started with analysis in ALICE

• Getting started with ALICE software

• ALICE Analysis Framework

• Meet a TTree - Container para dados de HEP

• Analysis Object Data (AOD)

• Visualization

  • Raw-data Display and Visual Reconstruction Validation in ALICE - Matevˇz Tadel
    • Artigo
    • Apresentação

Tarefa: Geração de gráficos, tabelas e estatísticas dos dados. Primeiramente, visa-se executar exemplos com um evento isolado, para depois generalizar os resultados para uma infinidade de eventos. Cada choque de pacotes de núcleos atômicos constitui um evento.

• Distribuição de multiplicidade de partículas dos eventos, distribuição de p_t (momento relativístico transversal) e posições dos vértices.
• Caracterização das trilhas: tipo de partícula e variáveis cinemáticas.

Tarefa: Criação das trilhas no Blender.

• Exemplos (alguns são simulações)
  • Ver último minuto de Preparing for heavy ion collisions
  • Quark gluon plasma (QGP) @ RHIC
  • Quark Gluon Plasma (QGP) Video 1
  • Quark Gluon Plasma (QGP) Video 2
  • CERN-MOVIE-2010
  • Heavy Ion Collision Event Animation (ATLAS)
  • ALICE Animations

Desafio da primeira fase do Grupo de Estudos: A partir dos conhecimentos adquiridos com as etapas anteriores, criar visualizações 3D dos dados obtidos pelo detector ALICE. As visualizações serão utilizadas em atividades de divulgação científica.

Documentação

A análise de dados provenientes das colisões de partículas do detector ALICE pode ser feita por meio de duas principais abordagens: através de uma plataforma de máquina virtual, já previamente configurada com uma interface que torna a análise intuitiva e mais direta, ou através de um software de análise de dados, chamado Aliroot, que com o auxílio de programas na linguagem C++, obtém a informação diretamente dos arquivos disponíveis. Ao passo que a máquina virtual torna os processos mais simplificados, a abordagem do software proporciona maior capacidade de familiarização com o quadro geral do armazenamento de dados e sua obtenção, portanto o projeto dedica-se especialmente a este último método. De qualquer maneira, estão documentadas aqui características de ambas as abordagens.

Abordagem do software Aliroot

Conhecida como ALICE Off-line Project, por não precisar de conexão à internet durante a análise dos dados, consiste essencialmente no download de arquivos do tipo ESD - Event Summary Data - com extensão .root, diretamente do portal de dados abertos do CERN, e em seguida na execução de programas específicos para coletar e fazer reconstruções e simulações com os dados desejados. Cada arquivo contém informações a respeito de uma série de eventos, sendo cada evento definido como uma colisão de pacotes de partículas (que podem se tratar de colisões próton-próton ou chumbo-chumbo). Como mostra a imagem abaixo, a reconstrução do evento é feita com a ajuda de uma simulação prévia:

Fonte: http://alice-offline.web.cern.ch/Activities/Reconstruction/index.html

O próprio CERN disponibiliza páginas que introduzem a análise no ALICE e também a plataforma de análise ALICE. Foi desenvolvida, também, de maneira extraoficial, uma abordagem alternativa utilizando a linguagem de programação Rust.

O grupo de pesquisa instalou o software Aliroot seguindo as instruções disponíveis no repositório AliESD_Example deste GitLab. É recomendável clonar o repositório (usando o comando git clone https://git.cta.if.ufrgs.br/ALICE-open-data/AliESD_Example.git) em um diretório de nome alice, onde também deve ser instalado o Aliroot. O último passo no arquivo README.md, referente à instrução de instalação, pede para executar o macro runAnalysis.C, que se trata de um código exemplo, na linguagem C++, que realiza uma análise sobre um determinado arquivo ESD, que deve ser baixado diretamente do CERN Open Data Portal. Para teste, recomenda-se os arquivos da amostra Pb-Pb data sample at the collision energy of 2.76 TeV per nucleon pair from run number 139038. Tais arquivos ESD devem ser colocados no diretório clonado do repositório do Git, de nome AliESD_Example, e devem ser referenciados no macro runAnalysis.C na linha

chain->Add("AliESDs.root");

em que "AliESDs.root" é o arquivo ESD. Podem ser adicionados outros arquivos ESD; basta repetir o comando e acrescentar outros arquivos à cadeia.

O código que determina o tipo de análise que será feita, no entanto, está no arquivo AliAnalysisTaskMyTask.cxx. Este faz um loop nas trilhas das partículas resultantes da colisão entre íons e escreve arquivos com informações relevantes para a caracterização das mesmas, como o momentum nas três dimensões espaciais e a carga. A função que deve ser editada para alterar os dados extraídos é a função UserExec, da classe AliAnalysisTaskMyTask.

Para uma melhor referência dos dados que podem ser obtidos no arquivo ESD, pode-se usar as estruturas chamadas TTree, espécie de plataforma desenvolvida pelo CERN para armazenar informações de experimentos com altas energias. Basta acessar o Aliroot e, em seguida, abrir o TBrowser, no qual podem ser reconhecidos os membros de arquivos do tipo .root, conforme abaixo:

aliroot

new TBrowser

Isso abrirá uma janela de navegação; deve ser selecionado algum arquivo ESD, como ilustra a imagem.

Mais informações a respeito das funções criadas para obter os dados dos arquivos ESD podem ser encontradas nas bibliotecas do GitHub do Aliroot. As principais bibliotecas utilizadas foram:

• AliESDEvent.h
• AliESDVertex.h
• AliESDtrack.h
• AliExternalTrackParam.h (porém essa não se encontra no mesmo endereço que as outras)

Podem ser úteis, também, os seguintes itens:

• Slides do ALICE Offline tutorial (Slide 30 mostra uso de PID - Particle Identification)
• Dicas do uso do Aliroot
• Códigos relevantes:
  • Código fonte da classe que cria as trilhas ESD
  • Exemplo com visualização de trilha a partir de um arquivo ESD
  • Exemplo para análise de classes ESD
• Unidades de medida utilizadas na Física de Partículas:
  • Basic Units and Introduction to Natural Units
  • Particle Physics Units

Evolução das partículas no tempo

A partir da edição do código exemplo mencionado acima, na função UserExec do arquivo AliAnalysisTaskMyTask.cxx, foi executada uma análise para escrever arquivos texto contendo dados relevantes relacionados às informações gerais de cada evento e às trilhas destes, chamados respectivamente esd-summary.dat e esd-detail.dat.

O primeiro contém o número de trilhas do evento, as coordenadas x, y e z do vértice da colisão, de acordo com o sistema de coordenadas cartesianas utilizado, e o módulo do campo magnético gerado pelo solenoide que envolve a região.

Fonte: https://en.wikipedia.org/wiki/ALICE_experiment

O segundo contém a massa da partícula associada a cada trilha, bem como sua carga e componentes do momentum linear e velocidade nas direções x, y e z no instante da colisão - também de acordo com o sistema de coordenadas, sendo usados valores negativos para sentidos contrários ao de crescimento de cada eixo.

Pode-se conferir a versão do código AliAnalysisTaskMyTask.cxx que gera tais arquivos. Note que a velocidade não é obtida diretamente de uma função do Aliroot, mas calculada a partir dos valores de momentum linear usando cálculos de relatividade, pois tratam-se de partículas em velocidades próximas à da luz.

Através destas informações básicas é possível construir um modelo simplificado da evolução de cada partícula no tempo, utilizando equações do Eletromagnetismo. O modelo é simplificado pois não inclui decaimento de partículas ou quaisquer tipo de interações com a matéria ou mesmo entre elas próprias durante sua propagação. Dito isso, foi elaborado um programa na linguagem C - como pode-se dizer, um subset da linguagem C++ -, de nome sol-analitica.tpc.c, que lê os arquivos gerados esd-summary.dat e esd-detail.dat e gera um terceiro arquivo texto de nome positions.txt, que contém a evolução das trajetórias das partículas no tempo. Este último possui cinco colunas: a primeira, com o índice da trilha; a segunda, com vários instantes de tempo; a terceira, quarta e quinta com as respectivas coordenadas em x, y e z daquela trilha. As coordenadas das partículas são representadas apenas no interior do raio externo do TPC.

Assim, pode-se gerar gráficos com uma "aproximação", pelos motivos mencionados, de um evento selecionado a partir de um arquivo ESD. A imagem abaixo é a representação das trajetórias de um evento com 15 trilhas, projetadas no plano xy, isto é, sem a dimensão longitudinal do detector (a direção z).

Deve-se conseguir obter a mesma figura fazendo todo o processo explicado utilizando um dos arquivos ESD da lista mencionada do CERN Open Data Portal. Segue a sequência de passos:

1. Fazer o download deste branch do repositório AliESD_Example, que atualmente contém os programas necessários, e entrar no diretório sol-analitica ;
2. Com o Aliroot instalado (instruções em README.md ), executar o programa runAnalysis.C no ambiente ROOT do ALICE;
3. Compilar e executar o programa sol-analitica-tpc.c;
4. Plotar um gráfico das colunas 3 e 4 do arquivo positions.txt gerado, que contém as coordenadas x e y das trilhas.

Para maiores detalhes no algoritmo de desenvolvimento do programa da evolução temporal das trilhas, confira a apresentação de slides.

É passível de observação que todos os códigos foram programados a fim de selecionar um evento com um número "razoável" de trilhas - entre 15 e 30 - a partir dos ESDs, de maneira a impedir uma poluição visual da representação gráfica do mesmo, no caso de um número excessivamente grande de trilhas, ou a análise de um evento com um número demasiado baixo de trilhas. Tal restrição não foi imposta no desenvolvimento da animação das trilhas em três dimensões, descrito a seguir.

Animação no Blender

O Blender é um programa gratuito e aberto para criar animações. Foi utilizado aqui com o propósito de gerar a visualização em 3D de eventos de colisão de partículas no detector ALICE. Com essa finalidade, foi criado um projeto no GitLab do grupo de colaboração ALICE-open-data, de nome ALICE Blender animation. A animação foi desenvolvida unicamente por meio de scripts na linguagem Python, utilizando orientação a objeto, de maneira que são dispensadas aqui informações sobre a interface do Blender. Todo o código foi pensado a partir de um exemplo de script para Blender que simula um sistema solar, disponível no site do Instituto de Física da UFRGS. No repositório, além do arquivo README.md, existem quatro arquivos principais que estruturam toda a animação, brevemente detalhados abaixo.

• particle.py: é o arquivo que define a classe das partículas, ou seja, que contém as características a ser adicionadas posteriormente a cada objeto animado do Blender e como eles devem se propagar pelo espaço a partir das condições intrínsecas da partícula que representam. É notável que este código define duas classes: a classe base Particle, que guarda o vértice, carga e massa da partícula; e a classe derivada ParticlePropagator, que configura o campo magnético, lê os valores de momentum nas três direções e define outras propriedades, para em seguida definir a propagação das partículas.

• drivers.py: este arquivo define a classe animationDriver, responsável por configurar aspectos gerais da animação, como qual câmera será utilizada, duração, número de quadros, porcentagem de resolução, etc. Suas classes derivadas, definidas em seguida, configuram a maneira como são determinados os dados que serão passados para as partículas, os objetos do tipo Particle. A classe genDriver gera partículas com valores de momentum que seguem uma distribuição gaussiana, nas três direções, e seus objetos devem ser inicializados com o desvio padrão dessa distribuição como argumento. A classe dataDriver é a mais importante no que tange aos objetivos deste projeto: ela lê todos valores de massa, carga, momentum e vértices das partículas a partir do arquivo texto gerado diretamente pela execução dos códigos para análise dos dados abertos ALICE, e seus objetos devem ser inicializados com o nome deste arquivo texto como argumento.

• scene_functions.py: é onde são definidas as funções que de fato executam a animação, não sendo definidas quaisquer classes. A função init() configura o ambiente, limpando o cenário e adicionando as câmeras e um cilindro que representa o TPC do detector, por sua vez definido na função addALICE_TPC(). Já addCameras() disponibiliza os tipos de câmera a ser escolhidos, que mostram a visualização de diferentes perspectivas. createSceneParticles() recebe como argumento uma lista com as partículas da classe Particle e cria os objetos do Blender para as partículas, acrescenta cores a cada uma, define seus tipos, configura as sombras e retorna uma lista com estes objetos, que tratam-se na verdade de pequenas esferas. Por último, animate() recebe como argumentos uma lista de objetos do Blender - como aquela criada por createSceneParticles() -, uma lista de objetos do tipo Particle e um objeto do tipo animationDriver, com o propósito de fazer os objetos animados seguirem a propagação conforme definido na classe ParticlePropagator.

• animate_particles.py: finalmente, é o arquivo em que são especificados os parâmetros desejados para a animação e o caminho do diretório onde será salva, além de chamar as funções definidas nos arquivos anteriormente descritos para construir a cena, animá-la e renderizar tudo.

Para gerar a animação, basta digitar o comando blender -noaudio --background -P animate_particles.py para executar o código em animate_particles.py. Ela será salva como um arquivo .mp4 no caminho especificado no código, que pode ser alterado. É válido lembrar que, para tal, o Blender deve estar instalado.

Observa-se, ainda, que o código desenvolvido pode ser usado para diversos fins, isto é, não apenas para eventos do ALICE - ou, sequer, de colisão de partículas -, graças à maneira como está organizado. A programação orientada a objeto proporciona uma facilidade de modificar aspector específicos de um código sem, todavia, a necessidade de preocupar-se com a maneira como isso irá afetar todo o restante do mesmo. Um usuário poderia, por exemplo, facilmente criar uma nova classe de driver para ler arquivos com dados de partículas diferentes dos mencionados, ou ainda definir uma nova maneira de propagar os objetos, que não na presença de um campo magnético, tudo isso fazendo alterações pontuais nos códigos.

É importante ressaltar que os arquivos do projeto são abertos e estão disponíveis para utilização, modificação e divulgação por toda a comunidade.

Histogramas

Histogramas são formas interessantes de representar dados, pois mostra a distribuição de frequências de determinada grandeza. Com o Aliroot, é possível modificar o código em C++ para incluir histogramas específicos, com os dados do evento analisado, no arquivo AnalysisResults.root, que é gerado a partir da execução do runAnalysis.C. Este arquivo, no entanto, deve ser acessado por meio de um TBrowser, visitando o arquivo com os resultados da análise e abrindo seus diretórios, como mostrado na figura:

Instruções sobre a construção de histogramas com o Aliroot podem ser encontradas no CERN User's Guide - Chapter 5: Histograms. No repositório do projeto AliESD_Example foram incluídos histogramas com os momentos transversais Pt, com as massas das partículas presentes - o que identifica e distingue as partículas - e com o número de eventos varridos nos arquivos ESD analisados. O código declara o histograma na função UserCreateOutputObjects() do arquivo AliAnalysisTaskMyTask.cxx, e o preenche na função UserExec() do mesmo arquivo.

Histograma com as massas das partículas presentes

Geometria do detector

Uma vez implementada a base da animação, como descrito até aqui, o próximo objetivo passa a ser adicionar os elementos do detector ALICE à animação. Tais elementos tratam-se na verdade das chamadas geometrias, elaboradas em alguma linguagem de programação, com a finalidade de representar objetos e formas físicas. As geometrias, no entanto, não são tão trivialmente compatíveis entre os formatos existentes, isto é, geometrias geradas a partir de linguagens diferentes muitas vezes contém elementos incompatíveis entre si.

Por exemplo, geometrias no formato CAD - Computer Aided Design - utilizam os chamados tesselated solids, sólidos construídos a partir da mescla de elementos primários como vértices, arestas, faces, polígonos e superfícies. Tais sólidos, todavia, não estão implementados no ROOT, que através da sua classe TGeometry, mencionada a seguir, utiliza primordialmente a técnica CSG - Constructive Solid Geometry - para criar novos objetos a partir de operações booleanas aplicadas a objetos mais simples, como união ou intersecção.

Tessellated solids. Fonte: https://en.wikipedia.org/wiki/Polygon_mesh

Constructive Solid Geometry. Fonte: https://en.wikipedia.org/wiki/Constructive_solid_geometry

Cabe aqui estabelecer uma distinção: um dos desafios da colaboração ALICE é encontrar uma maneira apropriada de converter projetos em CAD, uma ferramenta mais simples e intuitiva de se construir geometrias, para um formato utilizável pelo ROOT, o software oficial da organização. O principal objetivo do presente projeto, porém, trata-se de exportar as geometrias já disponíveis do detector, em formato ROOT, para um formato utilizável no Blender, o programa escolhido para a animação das trilhas.

Enquanto a solução mais promissora para o primeiro problema parece residir em uma conversão entre os formatos ROOT e GDML - Geometry Description Markup Language, uma linguagem derivada de XML, compatível com o ROOT e outros softwares de simulação física como o Geant4 -, uma solução possível para o segundo problema pode ser a interface TGeoCad, uma funcionalidade do ROOT que possibilita a criação de arquivos no formato STL, ou STEP, a partir de geometrias já implementadas no mesmo. Arquivos STEP são mais facilmente intercambiáveis com CAD e outros formatos.

Conforme disponível no artigo TGeoCad: an Interface between ROOT and CAD Systems, a interface TGeoCad requer a instalação de um outro software, chamado Open Cascade, que contém bibliotecas relevantes. As versões mais recentes do Open Cascade, no entanto, estão estruturadas de uma maneira sutilmente diferente da versão originalmente acessada pelo TGeoCad, o que provavelmente é a causa de tal interface também estar indisponível nas versões mais recentes do ROOT. A dificuldade do grupo na procura por uma alternativa para converter geometrias do ALICE para um formato utilizável no projeto levou o grupo a abandonar tais tentativas e partir para a criação de uma geometria utilizando modelagem 3D. De qualquer maneira, esse é um caminho que ainda pode ser explorado, e os registros importantes do processo estão registrados na página de wiki Documentação da instalação da interface TGeoCad.

Elaboração da geometria do detector

Como explicado acima, foi buscada uma alternativa para a construção das peças do detector na animação usando software. Naturalmente, foi escolhido o Blender como programa para tal tarefa, pois é o mesmo que gera a animação em si e é um dos melhores recursos abertos para criar cenários em três dimensões.

Até o presente momento, haviam sido apenas exploradas algumas funcionalidades básicas do Blender, portanto deu-se a necessidade de expandir os conhecimentos acerca do mesmo, para assim projetar com mais qualidade as peças do detector. Após algum tempo de imersão no software, com a ajuda de tutoriais disponíveis nos Estudos Complementares dessa página, foi optado pela abordagem de utilizar a tela padrão de edição de objetos do Blender como um recurso para entender quais os códigos equivalentes, em python, para gerar cada peça, como descrito a seguir, principalmente por meio de operações booleanas. É importante ressaltar que no projeto é utilizada a versão 2.79 do programa, ao passo que os tutoriais disponíveis são na versão 2.8. Dentro do que foi utilizado, porém, explorar um pouco os menus da versão antiga foi o suficiente para se adaptar.

Assim, o procedimento adotado foi, ao incluir um objeto na interface padrão do Blender, como na imagem abaixo,

verificar na aba Scripting o código em python correspondente para aquela função.

Analogamente, consulta-se o código para efetuar translações, mudanças na escala, operações booleanas (ver seção acima) e outras operações necessárias. Para algumas tarefas utilizadas frequentemente, porém, como a adição de uma casca cilíndrica - um cilindro com um cilindro "subtraído" do meio, como mostrado abaixo -, foram definidas funções com a finalidade de encurtar e simplificar o código.

Desta maneira, por exemplo, para auxiliar na tarefa mencionada, criou-se a função subtract(that,fromThat), em que dois objetos são dados como entrada - o objeto that e o objeto fromThat. A função então faz a operação booleana da diferença entre o segundo e o primeiro objeto, isto é, "subtrai" o objeto that do objeto fromThat, por fim excluindo este último.

Foi criado um arquivo modelo no Blender, de nome alice-geometry.blend, onde era testado o código para gerar cada peça do detector e, assim, armazenar a geometria junto com o respectivo código salvos. A partir do mesmo, era copiado o código e colado no arquivo scene_functions.py, em que constam as funções para gerar os objetos da cena, conforme explicado na seção anterior Animação no Blender. As definições das funções de simplificação do código - como a função subtract() -, todavia, foram adicionadas a um novo arquivo chamado blender_functions.py, acrescentado também ao repositório principal do projeto, com a finalidade de maior organização dos códigos.

Vale lembrar que as cores são meramente ilustrativas e não representam a realidade.

A função addALICE_Geometry() e as dimensões do detector

A função addALICE_Geometry() é aquela dentro do arquivo scene_functions.py que é responsável por adicionar à animação as peças do detector. A unidade utilizada nas dimensões dos objetos adicionados, no código, foi o metro, pois esta é a usada na animação das trilhas. Abaixo, seguem as referências consultadas na elaboração de cada peça, na ordem em que elas aparecem no código.

TPC - Time Projection Chamber

O TPC foi a primeira peça adicionada à animação, presente desde as primeiras versões do projeto da animação. Anteriormente, porém, como pode ser observado no link, tratava-se apenas de um grande cilindro com o raio e comprimento próximos às dimensões reais. Na seguinte geometria, o TPC está representado por dois cilindros concêntricos, um para representar a parte ativa de sua câmara interna e outro para a externa.

Referências:

• The ALICE Time Projection Chamber
• Technical Design Report for the Upgrade of the ALICE Time Projection Chamber - ênfase na tabela da página 18 do arquivo, posta abaixo:

No entanto, para fins da animação, foi optado por manter a representação do TPC como um cilindro único:

EMCal - Electromagnetic Calorimeter

Referências:

• ALICE EMCal Physics Performance Report - ênfase na tabela da página 16 do arquivo
• The ALICE Electromagnetic Calorimeter: EMCAL - página 2

ITS - Inner Tracking System

Foram construídas as três camadas do ITS, como observado na tabela abaixo: a interna (Inner Layer), intermediária (Middle Layer) e externa (Outer Layer), conforme as dimensões dispostas.

Referências:

• Technical Design Report for the Upgrade of the ALICE Inner Tracking System - páginas 22 e 23 do arquivo

TRD - Transition Radiation Detector

O TRD foi particularmente difícil de elaborar, pois se fez necessário partir a "casca cilíndrica" em 18 partes diferentes, como mostra a figura. Tal tarefa foi feita por meio de um modelo matemático que retira precisamente "fatias" da peça principal, de forma a deixar apenas o conteúdo que interessa. Para mais detalhes, é válido lembrar que sempre se pode consultar o código.

Referências:

• ALICE Technical Design Report of the Transition Radiation Detector - páginas 28 até 30

Automatização das etapas da animação

O repositório do projeto de animação ALICE Blender animation está organizado da seguinte maneira: no diretório animate, estão armazenados os códigos em python para confecção da animação no Blender (ver seção Animação no Blender), enquanto no diretório aliRoot estão os macros em C++ para análise de dados (ver seção Abordagem do software Aliroot). No diretório principal, encontra-se o arquivo workflow_sketch.sh, um script em shell que automatiza as etapas necessárias para gerar os clipes animados, desde a coleta de dados através dos arquivos ESD até a renderização dos clipes finais. Na interação do usuário com o projeto, portanto, basta especificar um arquivo ESD para análise e executar o script conforme as instruções, não sendo necessário realizar manualmente as etapas de análise de dados, seleção a dedo dos eventos desejados e execução dos códigos em python para animá-los usando o Blender. O usuário também tem à sua disposição algumas opções de uso, como a personalização dos eventos a animar de acordo com certos critérios, como listado abaixo.

Quanto à referência a um arquivo ESD, existem duas opções: o usuário pode utilizar um arquivo já baixado ou especificar um link para download automático. No primeiro caso, basta que o arquivo ESD possua nome "AliESD.root" (sem aspas) e esteja no mesmo diretório que o próprio workflow_sketch.sh, isto é, o diretório principal do projeto. No caso do download automático, basta incluir a URL do arquivo ESD, diretamente do CERN Open Data Portal, como o argumento da opção "--url", conforme explicado a seguir.

As opções de uso do script devem ser dadas junto com sua execução, com espaços para separar a opção e sua devida entrada, como por exemplo ./workflow_sketch.sh --fps 24 --duration 8. Este exemplo configura o número de frames por segundo como 24 e limita a duração do clipe a 8 segundos. Algumas opções possuem mais de uma forma de ser referenciadas. Por exemplo, para especificar as câmeras com que se deseja animar como OverviewCamera e BarrelCamera, pode-se utilizar tanto -c Overview,Barrel como --cameras Overview,Barrel. Naturalmente, existem valores padrão para cada opção, caso suas entradas não sejam informadas, assim como existem opções cujo uso não requer uma entrada. A seguir, a descrição detalhada do funcionamento de cada uma das opções de uso, suas possíveis entradas e seus valores padrão.

Teste de rendimento da animação

Durante aproximadamente dois dias, foi deixado um notebook gerando uma série de animações de colisões de partículas de eventos do Experimento ALICE por meio do código desenvolvido, com o fim de conhecer os recursos utilizados no processo: tempo e memória. Foram gerados três clipes - um para cada câmera - de cada um dos quinze eventos selecionados a partir do ESD Run139038_Orbit7548473_BunchCross1534, com crescente multiplicidade. O objetivo principal foi estimar a quantidade dos recursos necessários para se gerar um número maior de clipes, inclusive de eventos com multiplicidade bem mais elevada que aquela mais alta contemplada no teste, de 1004 partículas.

O teste consiste na execução de um script em bash que executa, por sua vez, para cada multiplicidade desejada, o script workflow_sketch.sh, responsável pela automatização das etapas do projeto, com a instrução de animar apenas um evento, com todas as três câmeras. Eis o código usado: efficiency_data_collecting.sh

O seguinte gráfico, gerado no gnuplot com o código plot_memory.sh, representa a memória computacional máxima utilizada, para clipes de cinco segundos, no processo de extrair os dados e gerar as animações nas três câmeras de cada evento acionado.

Similarmente, o próximo gráfico representa os tempos computacionais conhecidos como real time, user time e kernel time no processamento dos (mesmos) três clipes de cinco segundos de cada evento. Segue uma breve explicação dos tempos mencionados.

real time: O tempo de fato gasto na execução do processo do início ao fim, como que medido por um ser humano com um cronômetro.

user time: O tempo acumulado gasto por todas as CPU's durante a computação

kernel time (ou system time): O tempo acumulado gasto por todas as CPU's durante tarefas relacionadas ao sistema, como alocação de memória.

Nota: Ocasionalmente, a soma user time + kernel time pode ser maior que o real time, pois múltiplos processadores podem trabalhar em paralelo.

Este gráfico também foi gerado com o gnuplot, pelo código plot_time.sh.

Outras configurações a respeito dos clipes gerados para o teste:

Resolução: 100%

FPS: 24

Geometrias incluídas: ITS, TPC, TRD, EMCal

Transparência: 1 (padrão)

Ao passo que foi observada uma "anomalia" no terceiro evento do último gráfico, isto é, um ponto que desvia bastante do padrão de pontos, suspeitou-se de algum tipo de falha externa da análise de rendimento, caso contrário deveria haver alguma particularidade em tal evento, ausente nos demais. Para averiguar as hipóteses, foi repetido o teste com as mesmas condições, porém apenas com os seis primeiros eventos contemplados na primeira amostra, e um evento adicional com multiplicidade muito próxima à do evento investigado, conforme consta no script em bash efficiency_data_collecting_2.sh.

Observou-se que o ponto original foi "corrigido" de modo a adaptar-se ao padrão dos outros pontos, enquanto o novo evento introduzido também se encaixou adequadamente, como mostra o gráfico abaixo.

Em ambos os gráficos gerados, na primeira análise, nota-se um padrão linear de pontos até a multiplicidade um pouco maior que 600. Na análise da memória, isso é coerente com a memória RAM do notebook utilizado, de 8GB, pois é aproximadamente neste valor de uso de memória que o gráfico torna-se praticamente constante.

Preparo para o PCAD

Como objetivo do projeto, foi proposta a utilização dos recursos disponibilizados pelo Parque Computacional de Alto Desempenho (PCAD), da UFRGS, para gerar um número significativo de clipes de colisões de partículas do detector ALICE, por meio do projeto de animação. Com isso em mente, foram tomadas algumas providências para aprontar o projeto de forma a facilitar sua execução nas máquinas do Parque, cujo acesso é dado somente via ssh, isto é, remotamente. A principal delas foi a elaboração de um arquivo log contendo o relato das etapas de todo o procedimento realizado pelo código, em cada execução, desde a extração de dados até a montagem final do clipe animado. Para cada etapa, são registrados data e hora, conforme no exemplo abaixo, gerado a partir de uma execução com a chamada ./workflow_sketch.sh -n 1 -m 5 -t 2 --mosaic.

Por meio de um log como este, não apenas é possível estudar o desempenho computacional das etapas do processo, mas também tornar o script principal (workflow_sketch.sh) inteligente, no sentido de que ele pode verificar quais etapas já foram concluídas, por meio da leitura deste log, caso o processo porventura tenha sido interrompido, e continuar a partir de onde parou. A seguir, a documentação da abordagem de construção do código com escrita e leitura do log, dentro do script principal, na linguagem shell.

Escrevendo as ações no arquivo log

Para escrever a data e a hora de cada etapa do processo, foi criada a função timestamp:

timestamp() {

	date +"%y-%m-%d, %T, $1"

}

Por meio dela, para registrar qualquer etapa no arquivo log, escreve-se, por exemplo:

timestamp "${UNIQUEID}, DATA_ANALYSIS, FINISHED" >> $PROGRESS_LOG

em que a variável $PROGRESS_LOG é definida, no começo do código, assim:

export PROGRESS_LOG=$(pwd)/progress.log

o que refere-se ao arquivo progress.log, contido no mesmo diretório que o próprio script (workflow_sketch.sh).

O exemplo acima acrescenta, portanto, ao final do arquivo progress.log, a linha referente à finalização da etapa de análise de dados, como na imagem logo mais acima. Desta forma, basta que, para cada uma das etapas do código, seja antes verificada a presença da respectiva mensagem de conclusão no arquivo progress.log.

Lendo as ações do arquivo log

A leitura, ou verificação, das etapas já concluídas do processo pode ser feita da seguinte maneira, com o comando grep:

if ! grep -q "DATA_ANALYSIS, FINISHED" $PROGRESS_LOG; then

	(código para fazer a análise)
	(...)
	
	timestamp "${UNIQUEID}, DATA_ANALYSIS, FINISHED" >> $PROGRESS_LOG

fi

A primeira linha essencialmente diz: "se (if) não (!) for encontrada a expressão "DATA_ANALYSIS, FINISHED" dentro do arquivo $PROGRESS_LOG (grep -q [expressão] [arquivo]), então (then) execute o código para fazer a análise e escreve no arquivo $PROGRESS_LOG a devida mensagem (com timestamp)".

Assim, o script somente executará as etapas que não constam no log, uma vez todas elas estão colocadas de forma semelhante à mostrada. Quando o processo chega ao fim, é escrita a mensagem "JOB FINISHED", possibilitando que em uma próxima execução, ao ser conferida a presença desta mensagem, o processo comece pelo início novamente.

Abordagem utilizando máquina virtual

É o método indicado pelo CERN para análise dos dados abertos disponíveis no portal.

• Instruções de configuração da máquina virtual
• Artigo que descreve o ambiente da máquina virtual

Próximos Passos

A próxima etapa do projeto, atualmente, é utilizar os recursos disponibilizados pelo Parque Computacional de Alto Desempenho (PCAD), da UFRGS, para gerar um número significativo de clipes de colisões de partículas do detector ALICE, por meio do projeto de animação descrito.

Glossário

Aqui são descritos termos importantes para o assunto da pesquisa.

A partir de ALICE Offline Reconstruction:

• Dígito: Sinal digitalizado obtido por uma placa sensível de um detector em um dado instante de tempo.
• Cluster: Conjunto de dígitos adjacentes (no espaço e/ou tempo) que foram presumivelmente gerados pela mesma partícula atravessando o elemento sensível de um detector.
• Ponto do espaço reconstruído: Estimativa da posição onde uma partícula atravessou o elemento sensível de um detector (frequentemente, isso é feito calculando o centro de gravidade do cluster).
• Trilha reconstruída: Conjunto de cinco parâmetros (como a curvatura e os ângulos com respeito aos eixos coordenados) da trajetória da partícula junto com a matriz de covariância estimada em um dado ponto do espaço.

Estudos complementares

• Particle Tracking
  • Slide presentation: Introduction to Charged Particles Tracking
  • Pattern Recognition and Event Reconstruction in Particle Physics Experiments [pdf]
  • Event reconstruction and particle identification in the ALICE experiment at the LHC [pdf]
  • A fast introduction to the tracking and to the Kalman filter
• Particle Identification
  • Particle Identification by Christian Lippmann
• Quarkonia Production
  • Heavy quarkonium: progress, puzzles, and opportunities (2011)
  • Heavy quarkonia and Quark-Gluon Plasma: what did we learn and what are we learning?. E. Scomparin (2014)
• ALICE MasterClasses
• Theory of Special Relativity
  • University of Sussex
  • Macquarie University
• C++ Material
  • Learn C++
  • Codecademy C++
• Git tutorials
  • ALICE Git tutorial
  • GitHub basic workflow
  • Codecademy: Learn Git
  • Pro Git Book
  • Basic Git Commands
• Python
  • Codecademy: Learn Python
• R
  • Codecademy: Learn R
• Blender
  • Tutorial Blender 2.8 em Português

Contatos

• Mantenedor do projeto: Rafael Pezzi
• Gerente do projeto: Breno Lemos
• Outros contribuidores: Lucas Schnorr, Pedro Widniczck, Stefan Rossegger (email: stefan.rossegger@gmail.com)

Documentos

• Introdução_ao_Detector_ALICE_-Pezzi__Dez_2017.pdf
• ALICE.odp
• Slides-programa.odp

Referências

• TTree
  • TTree Class Reference
• ROOT
  • ROOT Guide for Beginners
  • Root User's Guide
  • Aliroot Tutorial
• Geometry in ROOT
  • geomAlice.C File Reference
  • MFT PCB Supports
  • TGeoCad: an Interface between ROOT and CADSystems
  • Overview of EVE - the Event VisualizationEnvironment of ROOT
  • TGeoManager Class Reference
• ALICE data flow
• Performance of the ALICE Experiment
• ALICE Technical Design Report of the Time Projection Chamber
• The ALICE TPC