Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
#83 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Tranquilo

Línea de trabajo

Comienza en el punto de entrada de filewriter y compara su salida actual con el grupo NXevent_data en raw_data_1/detector_1_events. Lee el comportamiento de event_aggregator y resuelve las preguntas sobre event_time_bins, el orden de los tiempos de referencia, el orden de los eventos y las flags de veto. Se considera terminado cuando el formato de archivo de eventos en streaming requerido y las reglas de procesamiento estén acordados e implementados.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Sin datos de lenguaje
Estrellas
0
Forks
0
Métricas de merge de PR
Sin PR fusionados en 30 d

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ISISComputingGroup/DataStreaming

Todos los issues de ISISComputingGroup/DataStreaming

Issues similares

Más issues de Data Engineering

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.