You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
PyARPES seems to be unmaintained: chstan/arpes#23
But has a maintained fork! chstan/arpes#23 (comment)
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:
The text was updated successfully, but these errors were encountered: