Currently, when you have a list of CSFs (a CSL), we store them as a Vector of CSF objects. But there is actually a lot of repeating information there, so I think we could have sort of lazy and/or interned representations of CSLs. Might be handy when working with large CSLs.
-
The principal quantum number does not affect coupling trees (e.g. the coupling trees for 3s² 3p⁶ 3d⁴ and 3s² 4p⁶ 4d⁴ are identical).
-
CSFs with just different seniority numbers can be generated with just combinations:
For example, the d³ orbitals has two different ²D terms. Let's give them additional quantum numbers #1 and #2. So, for the configuration 3s² 3p⁶ 3d⁴ 4s you would have the following configurations with subshell terms:
3s² 3p⁶ 3d⁴[²D; #1] 4s
3s² 3p⁶ 3d³[²D; #2] 4s
The LS coupling tree for both is identical though. So you could store it in memory once and just iterate over the seniority number.
You would save even more if you have more of shells with seniority numbers:
3s² 3p⁶ 3d⁴[²D; #1] 4s² 4p⁶ 4d⁴[²D; #1] 5s
3s² 3p⁶ 3d⁴[²D; #1] 4s² 4p⁶ 4d⁴[²D; #2] 5s
3s² 3p⁶ 3d⁴[²D; #2] 4s² 4p⁶ 4d⁴[²D; #1] 5s
3s² 3p⁶ 3d⁴[²D; #2] 4s² 4p⁶ 4d⁴[²D; #2] 5s
Again, coupling trees are all the same and you can just generate all by looping over all combinations of the seniority numbers.
-
CSFs have many coupling trees per configuration -- no reason to store a separate configuration object for each (although I think we already share the vectors in the Configuration object).
Currently, when you have a list of CSFs (a CSL), we store them as a
VectorofCSFobjects. But there is actually a lot of repeating information there, so I think we could have sort of lazy and/or interned representations of CSLs. Might be handy when working with large CSLs.The principal quantum number does not affect coupling trees (e.g. the coupling trees for
3s² 3p⁶ 3d⁴and3s² 4p⁶ 4d⁴are identical).CSFs with just different seniority numbers can be generated with just combinations:
For example, the
d³orbitals has two different²Dterms. Let's give them additional quantum numbers#1and#2. So, for the configuration3s² 3p⁶ 3d⁴ 4syou would have the following configurations with subshell terms:The LS coupling tree for both is identical though. So you could store it in memory once and just iterate over the seniority number.
You would save even more if you have more of shells with seniority numbers:
Again, coupling trees are all the same and you can just generate all by looping over all combinations of the seniority numbers.
CSFs have many coupling trees per configuration -- no reason to store a separate configuration object for each (although I think we already share the vectors in the
Configurationobject).