Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Save results into nexus format. #16

Closed
11 tasks done
YooSunYoung opened this issue Dec 22, 2023 · 2 comments · Fixed by #21
Closed
11 tasks done

Save results into nexus format. #16

YooSunYoung opened this issue Dec 22, 2023 · 2 comments · Fixed by #21
Assignees

Comments

@YooSunYoung
Copy link
Member

YooSunYoung commented Dec 22, 2023

The result of first data reduction step should be saved into nexus format to be fed to the next process.

It can be implemented once #15 is finished.

Required Fields

  • Sample name
  • Distance from source to sample
  • Other source information
  • Detector origen(?)
  • Fast axes (in beamline frame(?))
  • Slow axes (in beamline frame(?))
  • Proton charge (?)
  • Detector counts (grouped weights/counts, gzip compressed)
  • Time bins (in [ms])
  • Pixel IDs
  • Crystal Rotation

Questions

  • Is there anything can be already done in the first reduction step instead...?
  • Many fields used to be hard-coded and not straightforward where to retrieve them from the McStas file.
    Should users be able to update them manually some how...?
@YooSunYoung YooSunYoung self-assigned this Dec 22, 2023
@YooSunYoung
Copy link
Member Author

Here are more detailed explanations of each field.

  • Other source information
    Mostly hardcoded/manually input except for the number of detectors.
    All other information related to each detector should be in a combined list, sorted by the detector ID.)
  • Detector origen(?)
    3d vector position of the first pixel from the sample
  • Fast axes
    The axis along which pixel IDs grows by the number of pixels in one row (1280)
  • Slow axes
    The axis along which pixel IDs grows by 1
  • Proton charge
    Number of protons hitting the target within the measurement time frames
    It is proportional to the normalization factor. Normalization is done on the integrated events.
    For simulation data, it doesn't have to be precise, and can be arbitrarily derived by the number of events.
    (Since McStas simulation starts from neutron, not proton.)
  • Time bins (in [ms])
    Edges of time binned data.

@YooSunYoung
Copy link
Member Author

The exporting method should work regardless of the data. (whether simulation or measurement.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

1 participant