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

Compatibility/interoperability with AtomsBase #142

Open
brainandforce opened this issue Feb 6, 2023 · 7 comments
Open

Compatibility/interoperability with AtomsBase #142

brainandforce opened this issue Feb 6, 2023 · 7 comments

Comments

@brainandforce
Copy link
Owner

I didn't know about it when I started writing this package, but the AtomsBase package is designed to facilitate interoperability between a variety of Julia packages that work with atom data. To make this package more accessible I'd like to allow for the packages to interface with one another.

Here I'll also draw the distinction between AtomsBase and Electrum: I intend for Electrum to be less flexible but more performant and lightweight, and suitable for building a simulation package around. If you want to work with a wide variety of atomic properties (say, for instance, charges, thermal ellipsoids, etc.) Electrum might be able to do it, but that's not what it's intended for. However, if you want to have compact, fast representations of atoms and the ability to perform complex mathematical operations on datagrids, I want Electrum to be a top choice of package to base that around. Electrum could also do more niche/complex tasks, such as working with data in lower or higher dimensions.

@mfherbst
Copy link

mfherbst commented Feb 6, 2023

Great to see you consider an AtomsBase integration. Let me know if I can be of help.

We should also consider getting Electron.jl integrated into AtomsIO.jl, especially for replacing some of the reading / writing for which right now we need to have python.

@brainandforce
Copy link
Owner Author

Just to be clear, when you're referring to AtomsIO.jl integration, do you mean that you want to pull methods from this package to read and write data? One of the goals of Electrum.jl is to write everything in pure Julia to avoid language interoperability issues (and to keep dependencies light in general), so I'd like to avoid depending on any package that needs PythonCall.jl - but I'm very interested in replacing functionality that doesn't currently have a pure Julia implementation.

@mfherbst
Copy link

mfherbst commented Feb 6, 2023

Just to be clear, when you're referring to AtomsIO.jl integration, do you mean that you want to pull methods from this package to read and write data?

100% I'd like to reduce the number of python dependencies as much as possible as well.

@brainandforce
Copy link
Owner Author

Updating this issue to note that Electrum.jl is now available in the Julia package registry! Feel free to use it for the file reading/writing methods.

@brainandforce
Copy link
Owner Author

Some updates: I've been able to get the package in a state that's been useful for the development of some new theory tools, and the AtomsBase integration is back at the top of my list to implement. My main question for @mfherbst is what criteria a package needs to meet to be considered integrated into AtomsBase.

My first instinct is to add AtomsBase as an optional dependency and define Base.convert() methods to convert Electrum geometry information to AtomsBase objects, as that would not require any breaking changes. However, if the integration requires AtomsBase as a hard dependency (which I'm not opposed to doing) I'd like to hold off until the 0.2 release so that I can re-engineer the package to fully integrate it.

@brainandforce
Copy link
Owner Author

@mfherbst it's been a hot minute but I'm planning on making a breaking release of Electrum.jl in the near future, so I wanted to bring this to your attention again.

@mfherbst
Copy link

My first instinct is to add AtomsBase as an optional dependency and define Base.convert() methods to convert Electrum geometry information to AtomsBase objects, as that would not require any breaking changes

This is the "easy" way to do this. In Chemfiles.jl I have followed this approach.

However, if the integration requires AtomsBase as a hard dependency

That would be even better. The idea there is that you identify a key structure inside Electrum that represents atomic data and make it be an AbstractSystem. Basically we have a test suite, AtomsbaseTesting that checks the object behaves the way it should. This is the approach followed in ExtXYZ, ASEconvert and AtomsBase.FlexibleSystem. In these packages you can find some examples. The https://juliamolsim.github.io/AtomsBase.jl/stable/tutorial and https://juliamolsim.github.io/AtomsBase.jl/stable/overview/ aslo has some details.

Let me know if you have any concrete questions

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

No branches or pull requests

2 participants