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

Should all properties be equal? #15

Open
mbercx opened this issue Apr 19, 2024 · 3 comments
Open

Should all properties be equal? #15

mbercx opened this issue Apr 19, 2024 · 3 comments

Comments

@mbercx
Copy link
Member

mbercx commented Apr 19, 2024

Currently, the StructureData is completely defined as a list of properties (as explained here):

  • global:
    • cell
    • periodic boundary conditions (PBC)
  • site:
    • positions
    • symbols
    • masses
    • charge
    • magnetization - Coming soon!
    • Hubbard U parameters - Coming soon!
  • inter-site:
    • Hubbard V parameters - Coming soon!

I understand the appeal of this, and maybe it's the way to go. Part of me is still wondering if all properties should be equal, i.e. if some properties should receive special treatment (cell, pbc, positions, ...). Thinking of @mikibonacci's question here, I'd prefer to still be able to access the cell as structure.cell, not as:

structure.properties.cell

which then outputs a Cell object:

Cell(parent=<StructureData: uuid: 2f9fc6f5-e3a6-4811-89d6-41015b5f50b4 (unstored)>, domain='global', value=[[3.5, 0.0, 0.0], [0.0, 3.5, 0.0], [0.0, 0.0, 3.5]])

If I want to look at the cell, I'd just want to have structure.cell return a list of list or numpy array. I don't want to have to deal with the Cell object and then figure out how to get the cell vectors from this.

That said, other tools like pymatgen and ASE also have their own "cell" variants (Structure -> Lattice; Atoms -> Cell). And I can see how Cell.value lets you get what you desire. So maybe I'm just ranting for no reason here. Will think about it some more as I'm dogfooding.

EDIT: I think I may have managed to derail the conversation from my original point immediately in the same post. I insta-"Mr. Scope creeped" myself. 😅

@superstar54
Copy link
Member

I also vote to have structure.cell. And it would be good just to print out some thing similar to:

[[3.5, 0.0, 0.0], [0.0, 3.5, 0.0], [0.0, 0.0, 3.5]]

Same for other well-known global properties: positions, pbc, symbols.

@mbercx
Copy link
Member Author

mbercx commented Apr 19, 2024

An elegant solution may be to have structure.properties.cell to return the full Cell object (with all its features), and structure.cell to return just value, i.e. just be a shorthand for structure.properties.cell.value. Maybe this could even be applied generally to properties?

@mikibonacci
Copy link
Collaborator

From here, the only advantage of having a properties namespace is that we can collect there the properties which are defined and access them easily (e.g. properties.+tab completion). However, apart this, I do not see any other advantage.

And I agree that we should have direct access to the properties, i.e. structure.cell instead of only have the structure.properties.cell.value.

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

3 participants