You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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).
The text was updated successfully, but these errors were encountered:
mortenpi
changed the title
Lazy generation of configurations and CSFs
Lazy represenation of lists of CSFs
Aug 18, 2019
mortenpi
changed the title
Lazy represenation of lists of CSFs
Lazy representation of lists of CSFs
Aug 18, 2019
Currently, when you have a list of CSFs (a CSL), we store them as a
Vector
ofCSF
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⁴
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²D
terms. Let's give them additional quantum numbers#1
and#2
. So, for the configuration3s² 3p⁶ 3d⁴ 4s
you 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
Configuration
object).The text was updated successfully, but these errors were encountered: