Compare commits

...

3 commits

Author SHA1 Message Date
73d7687359
update TODO and README 2025-11-20 17:08:03 +01:00
085256857d
add test notebook to ignore 2025-11-20 17:07:16 +01:00
Justus Kuhlmann
5e87f569e2 update TODO 2025-11-07 09:43:58 +00:00
3 changed files with 27 additions and 10 deletions

3
.gitignore vendored
View file

@ -1,3 +1,4 @@
pyerrors_corrlib.egg-info
__pycache__
*.egg-info
*.egg-info
test.ipynb

View file

@ -5,3 +5,12 @@ This is done in a reproducible way using `datalad`.
In principle, a dataset is created, that is automatically administered by the backlogger, in which data from differnt projects are held together.
Everything is catalogued by a searchable SQL database, which holds the paths to the respective measurements.
The original projects can be linked to the dataset and the data may be imported using wrapper functions around the read methonds of pyerrors.
We work with the following nomenclature in this project:
- Measurement
A setis of Observables, including the appropriate metadata.
- Project
A series of measurements that was done by one person as part of their research.
- Record
An entry of a single Correlator in the database of the backlogger.
-

25
TODO.md
View file

@ -1,14 +1,21 @@
# TODO
## Features
- implement import of non-datalad projects
- implement a way to use another backlog repo as a project
- find a way to convey the mathematical structure of what EXACTLY is the form of the correlator in a specific project
- this could e.g. be done along the lines of mandatory documentation
- keep better track of the versions of the code, that was used for a specific measurement.
- maybe let this be an input in the project file?
- git repo and commit hash/version tag
- [ ] implement import of non-datalad projects
- [ ] implement a way to use another backlog repo as a project
- [ ] make cache deadlock resistent (no read while writing)
- [ ] find a way to convey the mathematical structure of what EXACTLY is the form of the correlator in a specific project
- [ ] this could e.g. be done along the lines of mandatory documentation
- [ ] keep better track of the versions of the code, that was used for a specific measurement.
- [ ] maybe let this be an input in the project file?
- [ ] git repo and commit hash/version tag
- [ ] implement a code table?
- [ ] parallel processing of measurements
- [ ] extra SQL table for ensembles with UUID and aliases
## Bugfixes
- [ ] revisit the reimport function for single files
- [ ] drop record needs to look if no records are left in a json file.
## Rough Ideas
- [ ] multitable could provide a high speed implementation of an HDF5 based format
- [ ] implement also a way to include compiled binaries in the archives.