Eventos observados pelo detector CMS são gravados de maneira permanente quando o conjunto dos trigger classifica o evento como interessante. Além de eventos originários das colisões próton-próton que ocorrem no centro do detector, o trigger pode ser ativado por fenômenos de outras natureza, tais como:
• passagem de um raio cósmico pelo detector [109,110];
• interações espúrias do feixe do LHC, dando origem a partículas que não vem da região nominal de interação [111];
• sinais espúrios devidos a mau funcionamento do hardware.
Eventos originários desses tipos de fenômeno são o primeiro fundo a ser eliminado da análise. O objetivo é filtrar a partir da amostra de eventos gravados apenas aqueles com alta probabilidade de serem originários de uma colisão dura próton-próton. Com esse fim, requisitamos que ao menos um bom vértice primário tenha sido reconstruído. Vértices primários são objetos reconstruídos a partir da coleção de traços que representam a posição estimada, juntamente com o erro, de uma determinada colisão próton-próton. Na Colaboração CMS, utilizamos um algoritmo adaptativo [112] para a reconstrução dos vértices. Para garantir que um evento seja de fato proveniente de uma colisão próton-próton, fazemos a exigência de que ele contenha pelo menos um bom vértice primário.
O padrão atual da Colaboração CMS para um bom vértice primário é [113]: • Vértice verdadeiro, isto é, propriamente obtido de um conjunto de traços.
Eventos onde não foi possível reconstruir um vértice verdadeiro em geral apresentam um chamado “vértice falso”, correspondente ao centroide da região de interação medida para aquela série de colisões.
• Número de graus de liberdade maior do que 4. O número de graus de liberdade de um vértice é dado por ndof = 2 ∑nTracksi=1 wi−3, onde wi é o
peso do i-ésimo traço. Traços bem reconstruídos tem peso aproximadamente igual a 1, então este requerimento é aproximadamente equivalente a exigir a presença de um número entre três e quatro traços bem reconstruídos.
• Distância longitudinal do vértice reconstruído ao centro geométrico do de- tector seja menor que 24 cm.
• Distância transversal do vértice reconstruído ao centro geométrico do detec- tor seja menor que 2 cm. Este requisito, em conjunto com o anterior, garante que o vértice reconstruído seja de fato proveniente do cruzamento do grupos de prótons considerado.
Outro procedimento de limpeza utilizado na análise é a mitigação do ruído calorimétrico anômalo [114] através do uso do filtro HBHENoiseFilter. Este ruído é devido a problemas na instrumentação dos fotodiodos híbridos (HPDs) e das caixas de leitura (RBXs). Em geral, a presença de ruído anômalo é indicada através da presença de uma RBX com uma das seguintes características:
• Pulso eletrônico mal formado. A energia total medida nos três time slices (25 ns) que mais contribuem para a energia depositada é comparada com a energia medida nos três time slices imediatamente seguintes. Valores muito altos (>0.96) ou muito baixos (<0.70) dessa razão indicam a ocorrência de
ruído.
• Alta multiplicidade de hits (nhits >16).
• Alta multiplicidade de contagens nulas do ADC em uma RBX (nzeros >9).
• Falta de sincronia entre o pico do pulso reconstruído e a cronometragem do trigger (∆t>5 ns).
Uma outra fonte de ruído é a presença de partículas devidas ao chamado halo do feixe. Algumas dessas partículas são provenientes de chuveiros iniciados por colisões do feixe com gás residual dentro do sistema de vácuo e/ou interação do halo do feixe com aberturas limitantes. Outras são partículas do feixe em si, defletidas de maneira errônea pelos campos magnéticos do sistema de ótica do feixe. Para evitar a contaminação de eventos devido ao halo do feixe, nós utilizamos o filtro CSCHaloFilter na sua configuração mais restritiva [115]. Além disso, certos processos com presença de halo de feixe apresentam uma série de traços paralelos à linha do feixe (“eventos de raspagem”). Para evitar essa classe de eventos requisitamos que, em eventos com mais de 10 traços reconstruídos, ao menos 25% deles sejam traços de alta pureza [113].
Mesmo com toda a limpeza descrita acima, algum ruído residual do calorímetro pode ainda dar origem a jatos não-físicos (falsos). Para lidar com esse fenômeno, impusemos sobre todos os jatos do evento os assim chamados requerimentos de identificação de jatos de Particle Flow[116] que incluem,
• fração de energia hadrônica neutra do jato menor que 0,99; • fração de energia eletromagnética neutra do jato menor que 0,99; • numero de constituintes do jato maior que 1;
• fração de energia hadrônica carregada do jato maior que 0;
• fração de energia eletromagnética carregada do jato menor que 0,99; • multiplicidade carregada do jato maior que 0;
Jatos que atendem esses requisitos de identificação são considerados jatos reais, e são aqueles utilizados nas etapas posteriores da análise. Relembramos que consideramos como jatos apenas aqueles com pT >30 GeV,|η| <2, 4.
Finalmente, para selecionar uma região bem definida do espaço de fase, nós requisitamos que o jato principal tenha pT maior que 110 GeV e |η|menor que
2,4. O objetivo deste requerimento é garantir que o evento tenha uma razoável possibilidade de se revelar um evento de jato único.
Para resumir nosso critérios de pré-seleção:
• Seleção do trigger: requisitamos a aceitação do trigger como descrito na Tabela6.2.
• Vértice e raspagem: o evento deve apresentar ao menos um vértice primá- rio bem reconstruído, e deve ser aceito pelo filtro de raspagem.
• Presença do jato: ao menos um jato hadrônico real deve estar presente no evento, de acordo com os os critérios de identificação.
• Cinemática do jato: o jato principal do evento deve ter pT > 110 GeV e
|η| <2, 4, i.e., ser um jato central de alta energia.
• Filtragem de ruído: o evento deve passar pelos filtros de ruído calorimé- trico anômalo HBHENoiseFilter e de halo de feixe CSCHaloFilter. Eventos que atendem a todos os critérios de limpeza e pré-seleção são gravados para posterior análise e seleção.
Em termos operacionais, este procedimento foi dividido em duas etapas. Em primeiro lugar, foi criada uma tarefa do CRAB que aplicou o requisito do trigger a todos os eventos dos conjuntos de dados descritos nas Tabelas 5.2, 5.3 e 6.1. O CRAB CMS Remote Analysis Builder é a plataforma de acesso aos recursos de Grid utilizada pelos membros do CMS. O CRAB permite o acesso de recursos computacionais e conjuntos de dados remotos, permitindo a transferência dos resultados obtidos para um dispositivo de armazenamento local. Todos os eventos aceitos pelo trigger foram salvos no espaço de armazenamento doSPRACE, ainda
consolidação dos produtos reconstruídos em objetos físicos de alto nível: elétrons, múons, taus, jatos hadrônicos e energia transversal faltante, sendo estes dois últimos totalmente corrigidos. Foi feita então uma mudança de formato para um formato mais simples: a chamada TTree da plataformaROOT, que são uma classe
otimizada para armazenamento e acesso rápido de dados. É sobre eventos salvos neste formato que a segunda parte da análise é executada. A vantagem principal de se adotar esta estratégia hierárquica é que isolamos a parte dispendiosa em termos computacionais da análise: o acesso aos dados espalhados pela estrutura de computação do CMS ao redor do mundo e a calibração e consolidação dos objetos físicos são feitos apenas algumas vezes. A parte mais leve da análise – limiares cinemáticos, histogramas – pode então ser feita separadamente, o que torna menor o tempo entre uma mudança na análise e a obtenção de novos resultados.