Skip to content

Draft: datasets without x_{i} and y_{i} naming convention

Victor Negîrneac requested to merge dataset_design_2nd_try into dataset_design

Explanation of changes

After long discussion in !208 (closed) I have the dataset in this MR to put in practice @slavoutich suggestion on dropping the x_{i} and y_{i} naming convention.

IMPORTANT NOTE

  • I did not change any text at this point, i do not have bandwidth and we are having a hard time converging.
  • See the diff of the .rst.py for insight on what i changed.
  • See the docs after they build and download the notebook and run it yourself (otherwise some things are a bit miss-formatted in the RTD)

IMPORTANT NOTES ABOUT THE DESIGN

  • There are no constraints on the xarray variables/coordinates names.

    • some variables/coordinates have "_shots" or "_cal" suffixes because I felt like it, not intended to be part of a specification.

  • The important conventions would be:

    • the main dimension is named dim_0.
    • calibration points for the dim_0 lie on dim_0_cal.
    • things that do not fit on dim_0 or do not fit on dim_0 only, must lie on dimensions named as dim_{i}.
    • the repetitions dimension for dim_0 is named repetition_dim_0 (maybe for some wierd/advanced case we can have later a repetition_dim_{i}).
    • special attributes on the datasets are used for:
      • keeping track of which are the experimental coordinates/variables
      • keeping track of what are the calibration points meant for

Merge checklist

See also merge request guidelines

  • Merge request has been reviewed and approved by a project maintainer.
  • Merge request contains a clear description of the proposed changes and the issue it addresses.
  • Merge request made onto appropriate branch (develop for most MRs).
  • New code is fully tested.
  • New code is documented and docstrings use numpydoc format.
  • Changelog has been updated (when applicable).
  • CI pipelines pass
    • black code-formatting passes (gitlab-ci),
    • test suite passes (gitlab-ci),
    • no degradation in code-coverage (codacy),
    • no (serious) new pylint code quality issues introduced (codacy),
    • documentation builds successfully (CI and readthedocs),
    • windows tests pass (manually triggered by maintainers before merging).

For reference, the issues workflow is described in the contribution guidelines.

Edited by Victor Negîrneac

Merge request reports