kmnhan / kmnhan/erlabpy

Consider re-integrating PyARPES

Open
#21 0 comments 1 reaction 1 assignee Claimed by @kmnhan View on GitHub
enhancement
Dominant language
Python
Stars
19
Forks
8
Avg merge
6h 39m
Merged PRs (30d)
44

Description

PyARPES seems to be unmaintained: https://github.com/chstan/arpes/issues/23
But has a maintained fork! https://github.com/chstan/arpes/issues/23#issuecomment-2056771585

Although we moved away from PyARPES functionality and are happy, maybe we could consider re-adding compatibility layers since they have many more data plugins...

Options:
- Discard our data model, roll back to PyARPES conventions
* Pros: we get access to data loaded by PyARPES data loaders!
* Cons: I personally dislike a lot of things about their data convention like angle notation and attribute mangling, our momentum conversion will need major fixes
- Write a conversion function that transforms PyARPES data format to match ours
* This should be easy since PyARPES format is very constrained
* However the other way around will be quite hard
* And duplicated loader functionality is chaos
- Write a compatibility layer that subclasses a PyARPES loader and BaseLoader (multiple inheritance)
* Use PyARPES loaders with our syntax!
* Is this even possible?
- Ignore PyARPES and move on
* The easiest way
* However majority of attempts to analyze ARPES data with python are concentrated in PyARPES, could it become standard in the future?
* We have to implement more data loaders for this to not be a problem

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.