Handling of labels in AtomicCell #7

JosePizarro3 · 2024-02-19T12:45:59Z

@JFRudzinski @ndaelman-hu please, review when you can this merge request.

I worked out a bit further on the labels, atomic_numbers and Method.AtomParameters ideas and came with the following schema. Just a few points to consider:

Now there is further abstraction by having a class Cell. This can be used to inherit other system cells, e.g., CoarseGrainedCell or LatticeModelCell, without the need of pasing real chemical elements information and normalization.
The concepts of labels and atomic_numbers have been moved under a new base class named AtomsState. This base class is a combination of these concepts together with the old schema for AtomParameters. Everything in this context appears then under ModelSystem from now on.
This new base class also contains: information about the orbital state, information about the atom charge (as a positive or negative integer, tho I am happy to hear feedback here in case this might be a float), information about CoreHole and HubbardInteractions.
The design idea is that OrbitalsState has the information of the relevant orbitals for each atom. This means that not all orbitals for an atom (i.e., 1s, 2px, 2py, etc.) need to be necessarily parsed, but rather the ones relevant for the use-case being treated. The example of use-cases could be CoreHole and HubbardInteractions.
For HubbardInteractions, now there is a list of orbitals_ref which then points to the specific orbitals used for the interactions. This means that HubbardInteractions.umn shape is defined by the length of these refs.
For CoreHole, I also added orbital_ref. It is now then a game of adding n_excited_electrons and checking the orbital_ref.degeneracy to resolve the occupation. Prior to this, CoreHole inherited from the state, but I think this is much more clean, as now CoreHole only contains info relevant for when creating a hole in a core orbital state.
I added RussellSaundersState under utils.py. I am still trying to debug and wrap my head around what are these methods using, but it shouldn't be too complicated. I would be ok too to move it to its own module, like you prefer.
I will deprecate the old method MoleculeParameters, but we can think if there are some use-cases how to implement it. It shouldn't be too complicated.
I am considering the old method Pseudopotentials to probably live under a ModelMethod.BasisSet class. But we (@ndaelman-hu and I) can discuss this a bit later. I am happy to hear more feedback tho.

I hope you like this. With this, I think ModelSystem is fully flexible, normalizations are properly ran, and I will continue working on the #3 ModelMethod schema.

Edit:
The corresponding branch in Gitlab, electronic-parsers, and some La2CuO4_test_basesections_Wannier90.zip.

Commented out Pseudopotentials

Improved ModelSystem description

JosePizarro3 · 2024-02-19T13:30:09Z

Btw, @ndaelman-hu, from where did you defined the orbital map? The dictionary that defines l: ml. I am curious to check the reference.

JFRudzinski

This looks great @JosePizarro3 , it appears to me to be more or less what we discussed in your office, and I think it makes a lot of sense to me.

Just a small comment about the use of time_step.

simulationdataschema/model_system.py

ndaelman-hu

All minor stuff. Just take a look, no need for additional review.

One question: what if we have basic building blocks larger than atoms, i.e. molecules or coarse-grained? They'll need their own State, similar to AtomState, I reckon...
Maybe add a generic base class too.

ndaelman-hu · 2024-02-19T14:03:47Z

simulationdataschema/atoms_state.py

+    umn = Quantity(
+        type=np.float64,
+        shape=["*", "*"],
+        unit="joule",
+        description="""
+        Value of the local Hubbard interaction matrix. The order of the rows and columns coincide
+        with the elements in `orbital_ref`.
+        """,
+    )


I know that this is just a code migration, but I don't remember reviewing these extensions to the Hubbard parameters.

My only remark is about the naming. I really had no idea what umn was supposed to represent, until I read the description. Maybe you can make it clearer?
Moreover, are there any limitations on the matrix dimensions? Maybe the no. rows = l-degeneracy (at least in most DFT codes)?

I'll rename it u_matrix. I will also rename other quantities like u_interaction, j_hunds_coupling, u_interorbital_interaction, j_local_exchange_interaction. I think u_effective can remain as it is.

Yes, the shape of this matrix coincides with the length of orbitals_ref.

Yes, the shape of this matrix coincides with the length of orbitals_ref.

Maybe we should consider adding the shapes again? Let's at least keep it in the description for now.

Ok, I add them back. The checks are not being performed, but this is something we should discuss further.

simulationdataschema/atoms_state.py

ndaelman-hu · 2024-02-19T14:06:20Z

simulationdataschema/atoms_state.py

+    def resolve_u_interactions(self, logger: BoundLogger) -> Optional[tuple]:
+        """
+        Resolves the Hubbard interactions (u, up, jh) from the Slater integrals (F0, F2, F4).
+
+        Args:
+            logger (BoundLogger): The logger to log messages.
+
+        Returns:
+            (Optional[tuple]): The Hubbard interactions (u, up, jh).
+        """
+        if self.slater_integrals is None or len(self.slater_integrals) == 3:
+            logger.warning(
+                "Could not find `slater_integrals` or the length is not three."
+            )
+            return None
+        f0 = self.slater_integrals[0]
+        f2 = self.slater_integrals[1]
+        f4 = self.slater_integrals[2]
+        u_interaction = (
+            ((2.0 / 7.0) ** 2)
+            * (f0 + 5.0 * f2 + 9.0 * f4)
+            / (4.0 * np.pi)
+            * ureg("joule")
+        )
+        up_interaction = (
+            ((2.0 / 7.0) ** 2)
+            * (f0 - 5.0 * f2 + 3.0 * f4 / 2.0)
+            / (4.0 * np.pi)
+            * ureg("joule")
+        )
+        jh_interaction = (
+            ((2.0 / 7.0) ** 2)
+            * (5.0 * f2 + 15.0 * f4 / 4.0)
+            / (4.0 * np.pi)
+            * ureg("joule")
+        )
+        return u_interaction, up_interaction, jh_interaction
+
+    def resolve_u_effective(self, logger: BoundLogger) -> Optional[np.float64]:
+        """
+        Resolves the effective U parameter (u - j).
+
+        Args:
+            logger (BoundLogger): The logger to log messages.
+
+        Returns:
+            (Optional[np.float64]): The effective U parameter.
+        """
+        if self.u is None or self.j is None:
+            logger.warning(
+                "Could not find `HubbardInteractions.u` or `HubbardInteractions.j`."
+            )
+            return None
+        return self.u - self.j
+


Nice! Do we have unit tests for these?

Not yet, maybe we can tackle testing soon in another branch. For now I am testing directly on a parser and checking that everything goes well.

Do you mind opening this as an issue? Maybe you can also share your ideas of what you are expecting for testing and we discuss there.

I can also take it after you merge this and add you as a reviewer?
I'll open the issue this evening. Just remind me if I forget.

simulationdataschema/atoms_state.py

simulationdataschema/model_system.py

simulationdataschema/utils/utils.py

JosePizarro3 added 10 commits February 15, 2024 11:37

Defining is_representative in parser

94644dc

Adding AtomicState and all the other sub-sections

22c93e0

Improved descriptions and typing

b1b285f

Defined AtomState, Orbitals, CoreHole and HubbardInteractions

a95be16

Commented out Pseudopotentials

Changed atom_state for atoms_state

cd7af35

Updated for Orbitals schema

aa5205e

Improved schema, normalization, and descriptions of atoms_state.py

0718d55

Improved typos and fix descriptions

44fc5ba

Added plural to OrbitalState

1962372

Improved ModelSystem description

Added condition for umn and orbitals_ref in HubbardInteractions

d2a30e8

JosePizarro3 added the new feature New feature or request label Feb 19, 2024

JosePizarro3 requested review from JFRudzinski and ndaelman-hu February 19, 2024 12:45

JosePizarro3 self-assigned this Feb 19, 2024

JosePizarro3 linked an issue Feb 19, 2024 that may be closed by this pull request

Handling of labels in AtomicCell #5

Closed

Fixed OrbitalsState normalization

b774630

JFRudzinski approved these changes Feb 19, 2024

View reviewed changes

simulationdataschema/model_system.py Outdated Show resolved Hide resolved

ndaelman-hu reviewed Feb 19, 2024

View reviewed changes

JosePizarro3 added 4 commits February 19, 2024 16:36

Added feedback byt @ndaelman-hu

fd6599f

Fixed pipeline

d51986a

Added back n_ quantities for shapes

bca7411

Deleted unused comment

c61d13a

JosePizarro3 merged commit a22e918 into develop Feb 20, 2024
2 checks passed

JosePizarro3 deleted the 5-handling-of-labels-in-atomiccell branch February 20, 2024 08:39

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Handling of labels in AtomicCell #7

Handling of labels in AtomicCell #7

JosePizarro3 commented Feb 19, 2024 •

edited

Loading

JosePizarro3 commented Feb 19, 2024

JFRudzinski left a comment

ndaelman-hu left a comment

ndaelman-hu Feb 19, 2024 •

edited

Loading

JosePizarro3 Feb 19, 2024 •

edited

Loading

ndaelman-hu Feb 19, 2024

JosePizarro3 Feb 19, 2024

ndaelman-hu Feb 19, 2024

JosePizarro3 Feb 19, 2024

JosePizarro3 Feb 19, 2024

ndaelman-hu Feb 19, 2024

Handling of labels in AtomicCell #7

Handling of labels in AtomicCell #7

Conversation

JosePizarro3 commented Feb 19, 2024 • edited Loading

JosePizarro3 commented Feb 19, 2024

JFRudzinski left a comment

Choose a reason for hiding this comment

ndaelman-hu left a comment

Choose a reason for hiding this comment

ndaelman-hu Feb 19, 2024 • edited Loading

Choose a reason for hiding this comment

JosePizarro3 Feb 19, 2024 • edited Loading

Choose a reason for hiding this comment

ndaelman-hu Feb 19, 2024

Choose a reason for hiding this comment

JosePizarro3 Feb 19, 2024

Choose a reason for hiding this comment

ndaelman-hu Feb 19, 2024

Choose a reason for hiding this comment

JosePizarro3 Feb 19, 2024

Choose a reason for hiding this comment

JosePizarro3 Feb 19, 2024

Choose a reason for hiding this comment

ndaelman-hu Feb 19, 2024

Choose a reason for hiding this comment

JosePizarro3 commented Feb 19, 2024 •

edited

Loading

ndaelman-hu Feb 19, 2024 •

edited

Loading

JosePizarro3 Feb 19, 2024 •

edited

Loading