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

Support frozen core #44

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Support frozen core #44

wants to merge 4 commits into from

Conversation

haakoek
Copy link
Collaborator

@haakoek haakoek commented May 28, 2020

This pull requests allows for frozen core orbitals. This is implemented by modifying the slice for occupied orbitals:
self.o = slice(0,system.n) -> slice(nfrozen,system.n),
where nfrozen now is an argument to the constructor of the system class. The parameter nfrozen just gives the number of electrons to freeze, so it does not discriminate between restricted or general type systems. This has the potential pitfall that, for example nfrozen=1 effectively freezes the lowest lying doubly occupied orbital for a restricted system, while freezing just 1 spin-orbital for a general system. We have support for going from a restricted to a general system, thus we should make a choice if this automatically should mean that nfrozen is multiplied by 2 (I think this is most sensible, but maybe it is debatable).

Note that system.n, system.l and system.m are unchanged and that the number of virtual orbitals (self.m) is unaffected by the frozen core. However, it should be noted that when the reference energy and the fock matrix is constructed all occupied orbitals have to be used. This is handled explicitly in these methods.

@Schoyen Schoyen self-requested a review May 28, 2020 12:10
@halvarsu
Copy link
Collaborator

n_frozen should transform as n, which is multiplied by 2 if I am not mistaken?

@haakoek haakoek requested a review from tbpedersen June 2, 2020 08:03
Copy link
Collaborator

@Schoyen Schoyen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! I agree with @haakoek and @halvarsu that n_frozen in a GeneralOrbitalSystem should be twice the number of n_frozen in a SpatialOrbitalSystem when transforming from the latter to the former. This reflects the fact that n now acts as the number of occupied orbitals in any system and does not reflect the number of particles.

There are a few things in this pull request that needs to be addressed before it will work as intended (I think).

  1. The proposed changes does not pass on the number of frozen orbitals from a SpatialOrbitalSystem to a GeneralOrbitalSystem. This means that n_frozen is completely ignored in construct_pyscf_system_rhf if add_spin=True. To remedy this you need to pass on n_frozen=self.n_frozen * 2 as the last keyword argument here: https://github.com/Schoyen/quantum-systems/blob/0260d051540b9d1f2b164f50d64bf80c8b42b606/quantum_systems/spatial_orbital_system.py#L81-L85
  2. Add an optional n_frozen=0 argument to construct_pyscf_system_ao as well to make the two PySCF-methods behave in as similar manner as possible.
  3. Add test of the usage of the n_frozen-attribute. This test does not have to anything other than constructing a few different systems (both SpatialOrbitalSystem and GeneralOrbitalSystem), e.g., from PySCF and/or from RandomBasisSet. Make sure that n_frozen is set to the expected number, and check that when transforming from a SpatialOrbitalSystem to a GeneralOrbitalSystem you get a doubling in n_frozen.

Less important feedback:
I propose the convention n_frozen instead of nfrozen to better suit the snake-case naming used elsewhere in the code.

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

Successfully merging this pull request may close these issues.

3 participants