Uma idéia para o Trigger 0 e um
Redutor dinâmico de Dados
Luis Fernando Gomez Gonzalez
IFGW – Unicamp
Uma idéia para um Trigger 0
Trigger 0
O primeiro passo para determinar a nossa taxa de eventos será fazer medidas locais.
Após isso, teremos que definir um critério de Trigger, que por menos restritivo que seja, deve excluir a radiação local e evitar ruído escuro das PMTs.
Excluindo o background de origem cósmico, baseando-se nos estudos de Double Chooz nossa principal fonte de ruído será provavelmente proveniente dos elementos:
- Tálio (Tl) => Beta de 764 keV
- Potássio (K) => Beta de 1,311 MeV ou Beta + de 1,505 MeV
Além disso, teremos que lidar com a captura de nêutrons pelo hidrogênio, que gera um gama característico de 2,23 MeV, o que pode resultar em um elétron de retroespalhamento de aproximadamente 2 MeV.
Outro ponto que deve ser estimado é o tempo morto induzido por múons, ou seja, o
tempo que nosso detector se torna insensível após o depósito de uma grande quantidade de energia neste. Isso ocorre pelas sucessivas reflexões da grande quantidade de luz dentro
Uma idéia para um Trigger 0
Trigger 0
Uma primeira proposta para trigger seria reduzir drasticamente a radiação local usando um limiar por volta de 3 MeV de energia visível, o que equivale na simulação Toy Model algo em torno de 35 fotoelétrons.
Uma idéia para um Trigger 0
Trigger 0
Um corte em torno de 3 MeV tem um impacto direto no número de neutrinos detectados, cortando cerca de 15 %.
Uma idéia para um Redutor Dinâmico de Dados
O que temos atualmente:
Supondo o pior dos casos: 1kHz de eventos.
Nesse caso teríamos, para 40 PMTs em modo waveform um rate de ~10MB/s.
Partindo do princípio que o sistema de aquisição de dados seja capaz de lidar com essa taxa de eventos, teremos um outro problema: como guardar e transferir esse montante de dados, aproximadamente 864 GB/dia. Mesmo com um alto fator de compactação, ainda teríamos da ordem de dezenas a centenas de GB de dados por dia.
Por que gravar a Waveform?
Gravar todos os dados possíveis sobre os eventos é interessante pois nosso backgroud é várias ordens de grandeza superior ao sinal. Como a emissão de luz Cherenkov é muito bem conhecida, podemos tentar usar fatores como tempo de emissão, carga distribuída
entre outros. Desse modo, ter acesso aos dados na forma “bruta” pode ser muito importante na discriminação desse sinal.
Uma idéia para um Redutor Dinâmico de Dados
Proposta para um redutor de dados:
Embora seja muito bom ter os dados de neutrinos com toda a precisão possível, isso não é tão relevante para múons. Como os múons correspondem a mais de 99% dos eventos, gravar apenas o valor integral de carga por PMT ao invés da Waveform tem um impacto gigante no arquivo final de dados.
Supondo um sistema relativamente simples, que apenas integre a carga e, acima de um limiar nos diga que esse evento é um múon. Por exemplo, segundo meu trabalho de mestrado, um corte em 100 fotoelétrons reduziria 96% dos múons, deixando intacto os
eventos de neutrino. Como essa conta foi feita usando outra proposta geométrica, teria que ser refeita, de forma a encontrar o limiar para o atual detector.
Usando esse valor como referência e o Raw Data Format proposto, teríamos por dia aproximadamente: (5%*10MB + 95% * 0.36MB)/s ~ 72,75 GB/dia.
Esse é um valor ainda alto, mas que com a compactação do formato Root pode diminuir para um valor inferior a 10 GB/dia.
Desse modo, ainda podemos fazer física com os múons e teremos um conjunto de dados mais compacto.
Uma idéia para um Redutor Dinâmico de Dados
Proposta para um redutor de dados:
Como a taxa de dados adquiridas é muito alta, minha proposta é não fazer essa redução no Single Board Computer (SBC), para não enfrentar eventuais gargalos no processamento. Em princípio podemos fazer isso de uma forma pseudo-online em um computador com maior capacidade de processamento que o SBC localizado dentro do container.
Uma proposta seria fazermos runs pequenos, por exemplo de uma hora de duração, gravar esses dados na forma binária com os formatos de onda e esse PC remoto passar os dados para o formato Root já reduzindo os dados de múons. Os runs poderiam ser automatizados de forma que no término de um já fosse lançado o próximo. Além disso os arquivos já
poderiam ser gravados diretamente no PC externo usando um disco montado por NFS ou SSHFS.
SBC Gigabit
Ethernet
PC com discos compartilhados
Redução dinâmica dos dados
ROOTficação dos Dados
Uma idéia para um Redutor Dinâmico de Dados
Proposta para um redutor de dados:
Outra possibilidade para um sistema assim seria o monitoramento remoto do experimento. Poderíamos por exemplo rodar um servidor Web nesse PC que atualizasse em uma página HTML dados como: Número do Run atual, taxa de eventos do último Run, Percentual de Múons. E até mesmo valores como: Alta tensão e temperatura.
SBC Gigabit
Ethernet
PC com discos compartilhados
Redução dinâmica dos dados
ROOTficação dos Dados
Internet
Servidor Web de monitoramento
Uma idéia para um Redutor Dinâmico de Dados
Proposta para a página Web:
Número do último Run processado: Data e hora:
Taxa de eventos do último Run:
Taxa estimada de múons do último Run: Status da alta tensão:
Tensões:
Temperatura:
Uma idéia para um Redutor Dinâmico de Dados
Proposta inicial para um formato de Dados Root:
Os dados do Root poderiam ser escritos representando perfeitamente o que nós lemos da DAQ. Assim, para facilitar, poderíamos dividir em 3 árvores: “Informação do Run”,
“Informação do evento” e “Waveform”
A “Informação do Run” seria a árvore mais simples, com apenas as informações pertinentes ao Run inteiro, por exemplo: “Tipo de trigger”, “Horário e data de início”... Algumas poucas variáveis e todas elas sendo folhas diretamente, sem herdeiros.
A “Informação do evento” reuniria os dados Reconstruídos pelo PC de rootificação, como a carga total para cada PMT. Nós poderíamos criar para cada evento um vetor com o valor de carga reconstruída para cada PMT, outro com o tempo vindo do TDC para cada PMT. Sendo que nesse caso, cada PMT estaria numa posição do vetor. Note que essa árvore conterá informação sobre todas as PMTs em todos os eventos.
Por último, a TTree “Waveform” teria os valores das Waveforms para os eventos que passassem pelo filtro inicial de múons. Aqui nós teremos um vetor de vetores contendo os valores medidos pelo fADC. Para cada evento, temos um vetor de PMTs e para cada PMT, um vetor de valores para do fADC. Para manter o mesmo número de evento usado na TTree
Uma idéia para um Redutor Dinâmico de Dados
InfoRun
Data/Hora
Tipo de Run
Comentários
Proposta inicial para um formato de Dados Root:
“Informação do Run” 0 = Física 1 = Debug 2 = Calibração 3 = Monte Carlo Legenda Tree Inteiro String Double
Uma idéia para um Redutor Dinâmico de Dados
Proposta inicial para um formato de Dados Root:
“Informação do evento” InfoEvento 01 02 03 04 Número do Evento Carga Integrada Erro na Carga Tempo PMT1 PMT2 PMT3 Carga Total Erro Carga Total
Tipo do evento 0 = Evento físico 1 = MC múon 2 = MC nêutron C 3 = MC pósitron nu 4 = MC nêutron nu 5 = MC Gama Delta T CH1 Veto
Uma idéia para um Redutor Dinâmico de Dados
Proposta inicial para um formato de Dados Root:
“Waveform” Waveform 01 02 03 04 Número do Evento PMT1 PMT2 PMT3 PMT4 fADC Data (t=0) fADC Data (t=1) fADC Data (t=2) fADC Data (t=3) fADC Data (t=4)
