JDFTx IO module

[benrich37]

Summary

Major changes:

• Robust out file parsing for JDFTx
• In file parsing, managing and writing for JDFTx
• Testing (coverage at 97%)

Changes to existing code:
core.periodic_table

• For both ElementBase and Species class, the code within the "valence" property was copy-pasted into a new "valences" property, with the error raised for ambiguous valence (more than one valence subshell) removed
  (if len(valence) > 1: raise ValueError(f"{self} has ambiguous valence"))
  and return signature changed from tuple[int | np.nan, int] to list[tuple[int | np.nan, int]] (return valence instead of return valence[0])
• For both ElementBase and Species class, the "valence" property was re-written to reduce redundancy to raise the ambiguous valence ValueError if len(self.valences) > 1, and otherwise return self.valences[0]

(I have an idea of how to remove the redundancy between Species and ElementBase for valence, but I will hold off on this until the next PR)

Todos

• Move out file parsing class to be held by a broader output manager capable of parsing other dumped files by JDFTx

[mkhorton]

@benrich37 thanks for this PR and for your patience! Is the current branch up-to-date, and are there are specific areas of concern?

[benrich37]

@benrich37 thanks for this PR and for your patience! Is the current branch up-to-date, and are there are specific areas of concern?

Hey! Thank you for your comments! Sorry I hadn't checked this PR in a few days. My main concern for this PR is its readability - I wrote the JDFTx output's data structure to be object oriented to help develop faster, but I can understand how the hierarchy of objects can make it difficult to understand what's going on. I feel confident with functionality itself though (aside from edge cases for JDFTx outputs that keep popping up)

[computron]

From my side, can you explain the changes to periodic_table.py? Since it's a core class the changes should ideally be separated out from new functionality.

[shyuep]

There is a failing test that I am pretty sure is related to the changes to periodic table.

[benrich37]

There is a failing test that I am pretty sure is related to the changes to periodic table.

Hi @shyuep ! Sorry yes - I thought it would be cleaner to have the Species valence(s) property defer to the Element valence(s) property, but I'm seeing now these need to be defined separately so that Species can incorporate oxidation state. Fixing right now.

Also @computron - that makes to me, I wasn't sure if it would be better to have internal redundancy to the periodic_table module in this PR or to update alongside this IO module. @mkhorton - would it be okay to go back to using the ad-hoc method in the io.jdftx.data module for the time being?

Edit: @computron sorry misread your comment - part of the JDFTx output parsing requires a method which can fetch the number of valence electrons for each element in a Structure. The original method that did this was redundant to data that could be fetched by periodic_table, but the valence property needed to do this would throw errors for mixed valence species. I'm okay with either a) Species and Element updated to include a valences property, or b) have my own method (for now) to get the number of valence electrons that works for mixed valence species. As long as there is consensus, I can roll back changes to periodic_table and re-introduce them in a new PR after this one is accepted.

[benrich37]

Quick update: some of the dataclasses are having issues calling attributes that used to work. Should be fixed soon.

Edit: Fixed now.

[mkhorton]

I wasn't sure if it would be better to have internal redundancy to the periodic_table module in this PR or to update alongside this IO module.

Definitely let's try to minimize internal redundancy. That kind of thing can get out of control quickly and lead us towards a messy codebase.

I'll take another look at this soon, but if you want to arrange a quick call (~1hr) to review this PR I'm also open to that. I do not expect big issues but it might make it easier/quicker for us to get through it together.