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

DFTK.Model <: AtomsBase.AbstractSystem #1011

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

rkurchin
Copy link

Resolves #1007

Just wanted to start this here so you could give any feedback early on, also because I've been having trouble getting TestItemRunner working locally and so I'm not currently sure exactly which tests I've broken 🤪, but I'll get that sorted out eventually

The barebones implementation of the interface is here, I have not yet added any additional tests or anything, hence this is still definitely a draft.

…omsBase versions so those tests are likely broken

Signed-off-by: Rachel Kurchin <[email protected]>
@antoine-levitt
Copy link
Member

I really don't like the length and getindex overloads, as having them error is very useful for debugging. Looking into this more it really looks like we should have had a geometry field of Model, that would more closely match AtomsBase's System, but model really has more going on than just a geometry, so having model be a subtype of system feels a bit misleading... (that fits with the general "encapsulation over inheritance" stuff)

@mfherbst
Copy link
Member

mfherbst commented Oct 24, 2024

Looking into this more it really looks like we should have had a geometry field of Model, that would more closely match AtomsBase's System

We could just store a system in the Model ? Or simply make a geometry structure right now and use it consistently ?

I think there are also a few subtle details missed in this implementation. E.g. we represent 2D structures by keeping the 3x3 latttice matrix, but conventionally having a tailling zero row and column. In principle this would need to be taken care of as well and respectively the result of n_dimensions etc. adapted.

@antoine-levitt
Copy link
Member

We could just store a system in the Model ? Or simply make a geometry structure right now and use it consistently ?

We could and probably should have originally, but now it would be a mess of renaming model.lattice to model.geometry.lattice etc everywhere, for not that much of a benefit...

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

Successfully merging this pull request may close these issues.

Should Model directly subtype AbstractSystem?
3 participants