Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

`filewriter`: Neutron event data (`raw_data_1/detector_1_events`)

Aberta
#83 2 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
25/100
Tipo de issue
Funcionalidade
Clareza
Precisa de esclarecimento
Status de atividade
Pouca atividade
Domínio
data-engineering

Direção de pesquisa

Comece pelo ponto de entrada de filewriter e compare sua saída existente com o grupo NXevent_data em raw_data_1/detector_1_events. Leia o comportamento de event_aggregator e resolva as questões sobre event_time_bins, a ordenação dos tempos de referência, a ordenação dos eventos e as flags de veto. A tarefa estará concluída quando o formato necessário do arquivo de eventos em streaming e as regras de tratamento estiverem acordados e implementados.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

filewriter

The filewriter must be able to write out event-mode data.

This means the contents of the NXevent_data group in raw_data_1/detector_1_events

Questions

  • What do we want to do with event_time_bins, which aren't meaningful in streaming system?
  • Due to an underlying UDP connection from hardware, the streaming system cannot guarantee that frame N+1 will have a later reference_time than frame N. Do any consumers make assumptions about this?
    • This affects whether we can stream events to file directly, or whether we have to buffer, sort by reference time, and then write to file
  • Does mantid have a dependency on event time-of-flights being ordered within a frame? Currently this sort is (optionally) done at event_aggregator level as multiple consumers benefit from improved performance with sorted events.

Potential differences from existing files

  • We likely no longer need to apply a random event_time_offset_shift, as the new electronics has a much higher time resolution than the old DAE electronics. See https://github.com/ISISComputingGroup/DataStreaming/issues/22 .
  • We want to be able to write the veto flags for each frame alongside the event data, to enable downstream consumers to retroactively enable or disable a veto if it chooses:
    • active_vetos: the veto signals that were actually active for a given frame
    • enabled_vetos: the vetoes that were enabled in IBEX at the time of data acquisition
    • By default downstream consumers will want to mask any events where active_vetos & enabled_vetos != 0.
    • If adding this logic is problematic for Mantid, we could (optionally) drop the frames at filewriter level instead - at the cost of reducing flexibility and reducing diagnostics we have access to.
Linguagem predominante
Sem dados de linguagem
Estrelas
0
Forks
0
Métricas de merge de PRs
Nenhum PR com merge em 30d

Guia de contribuição

Nenhum guia de contribuição indexado para este repositório

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de ISISComputingGroup/DataStreaming

Todas as issues de ISISComputingGroup/DataStreaming

Issues semelhantes

Mais issues de Data Engineering

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.