Uma idéia para o Trigger 0 e um Redutor dinâmico de Dados. Luis Fernando Gomez Gonzalez IFGW Unicamp APC Universidade de Paris 7

Transcrição

1 Uma idéia para o Trigger 0 e um Redutor dinâmico de Dados Luis Fernando Gomez Gonzalez IFGW Unicamp APC Universidade de Paris 7

2 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 dele e possivelmente pelo tempo necessário para o retorno para baseline na eletrônica de Front End.

3 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.

4 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 %.

5 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.

6 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.

7 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. Redução dinâmica dos dados SBC Gigabit Ethernet PC com discos compartilhados Internet ROOTficação dos Dados

8 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. Redução dinâmica dos dados SBC Gigabit Ethernet PC com discos compartilhados ROOTficação dos Dados Internet Servidor Web de monitoramento Online/Pseudo-online Página web

9 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: Taxa de eventos Taxa de múons

10 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 de Eventos, podemos usar -1 para eventos que não possuem dados de Waveform.

11 Proposta inicial para um formato de Dados Root: Informação do Run Data/Hora InfoRun Tipo de Run Comentários 0 = Física 1 = Debug 2 = Calibração 3 = Monte Carlo Legenda Tree Inteiro String Double Boolean

12 Proposta inicial para um formato de Dados Root: Informação do evento Carga Integrada PMT1 PMT2 Número do Evento 01 Erro na Carga Tempo PMT3 Carga Total InfoEvento Erro Carga Total Tipo do evento Delta T 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 Veto CH1 Outer Veto CH2

13 Proposta inicial para um formato de Dados Root: Waveform fadc Data (t=0) Número do Evento PMT1 PMT2 PMT3 fadc Data (t=1) fadc Data (t=2) fadc Data (t=3) fadc Data (t=4) Waveform 03 PMT4 04