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

`filewriter`: copy information from `instrument_components.nxs`

Aberta
  • Algo errado?
#106 1 comentário 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
32/100
Tipo de issue
Funcionalidade
Clareza
Precisa de esclarecimento
Status de atividade
Ativa
Domínio
data

Direção de pesquisa

Comece examinando o arquivo-fonte do MARI instrument_components.nxs e o pull request 39 do ISISICP vinculado; em seguida, compare os conjuntos de dados do MARI listados com o layout nexus existente no estilo do ESS-filewriter. Este issue estará concluído quando os requisitos e um layout flexível acordado para as informações de abertura, Fermi, moderador, fonte e geometria estiverem documentados; a implementação fica explicitamente adiada.

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

Descrição

filewriter

MARI nexus files contain a different set of datasets than other neutron instruments.

These 'special' nexus files are not needed for HRPD-X or SANDALS-2, but I'd like to take these requirements into account when designing the filewriter to ease future implementation when we need to move MARI to datastreaming at some point in the future.

This mechanism appears to correspond to https://github.com/ISISNeutronMuon/ISISICP/pull/39 so @mducle may be able to comment on the underlying need. The nexus file this information is copied from is \\ndxmari\c$\Data\instrument_components.nxs.

On MARI specifically, this causes various information to get added to the generated .nxs for each run:

  • instrument/aperture
  • instrument/fermi exists and contains metadata from the fermi chopper including rotation speed, slit parameters, etc.
  • instrument/moderator contains more information than other beamlines: it contains a pulse shape distribution, moderator type, temperature, transforms.
  • instrument/source contains different information compared to a regular nexus file, including frequency and target_material but excluding probe
  • Various geometry information is added, in a similar way to what was previously possible with detector.dat. My understanding is that MARI do actually use this geometry information in preference to the Mantid IDF.

Questions

  • Would an ESS-filewriter style 'nexus layout' structure be sufficiently flexible to cater for this need - I think it should be? But it might tie us into a more complicated architecture than we might otherwise need...

Note that MARI is not on any near-term datastreaming list that I've seen, so we can indefinitely defer actually implementing this functionality. This issue exists primarily for requirements-gathering.

Linguagem predominante
Sem dados de linguagem
Estrelas
0
Forks
0
Nenhum PR com merge em 30d

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

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.