Get t-J operators from Hubbard #30
Conversation
Codecov Report❌ Patch coverage is
🚀 New features to boost your workflow:
|
|
Apologies for taking some time to get to this, I have to admit that it slightly slipped my attention. Do you mind if I add some changes here? Some general comments: While I agree that having to maintain less code is nice, I'm less happy with the definitions of [EDIT] ignore most of what I just said, I see you already did this, I'm apparently not very awake |
|
|
|
I've updated the approach a bit, in an attempt to simplify. The biggest change is that I've removed the Keep in mind that this is just a suggestion, so feel free to give your opinions on the changes I made, we can definitely revert/alter some things if you disagree! |
| @eval begin | ||
| hub_doc = (@doc HubbardOperators.$opname).text[1] | ||
| tJ_doc = replace(hub_doc, "[spin_symmetry::Type{<:Sector}])" => "[spin_symmetry::Type{<:Sector}]; slave_fermion::Bool = false)") * "Use `slave_fermion = true` to switch to the slave-fermion basis.\n" | ||
| @doc (tJ_doc) $opname | ||
| end |
There was a problem hiding this comment.
I tried to restore the slave_fermion keyword, which need me to replace and add some text to the corresponding Hubbard docstring.
Yue-Zhengyuan
force-pushed
the
zy-tJ-overhaul
branch
from
ecd04f6 to
21a2b01
Compare
|
Hahah I was hoping to avoid the keyword argument since I don't like it too much, and it does complicate the docstrings etc a bit, but I guess this also works. I'll try and go over it tomorrow so we can finalize |
src/tjoperators.jl
Outdated
| | |0⟩ | h⁺|0⟩ | | ||
| | u⁺|0⟩ | bꜛ⁺|0⟩ | | ||
| | d⁺|0⟩ | bꜜ⁺|0⟩ | |
There was a problem hiding this comment.
I don't think it's a great idea to call both vacua |0⟩ here. I added the prime to distinguish them (unless I'm mistaken they really are different?) because from this table, it looks like h⁺ = I etc. If you have a better notation for the different vacuum that obviously also ok, but I wouldn't use the same notation for both.
There was a problem hiding this comment.
My point is that in the slave-fermion representation, the basis state with FermionParity(1) is indeed h⁺|0⟩, where |0⟩ is the true vacuum (the FermionParity(0) state in the usual representation). So it shouldn't be written as h⁺|0'⟩, suggesting |0'⟩ is different from |0⟩.
Similarly, the usual u⁺|0⟩ is mapped to u⁺h⁺|0⟩ = (h bꜛ⁺)h⁺ |0⟩ = bꜛ⁺ |0⟩ in the slave fermion basis.
There was a problem hiding this comment.
I might really just be confused though, apologies since this is not necessarily a model I usually interact with.
Did I manage to just confuse myself by putting it in a table and somehow trying to relate the different states in the same row? I like the visual of the table, but maybe this was just not necessarily the right approach
There was a problem hiding this comment.
| tJ basis | slave-fermion |
| -------- | ------------- |
| |0⟩ | h⁺|0⟩ |
| u⁺|0⟩ | bꜛ⁺|0⟩ |
| d⁺|0⟩ | bꜜ⁺|0⟩ |
The states in the same row are indeed related. Just interpret it as "states in the left column are mapped to the right column by the basis transformation".
|
Can't merge because of low patch coverage. But the missing lines are mostly about raising errors and operator functions with omitted arguments. |
This PR greatly simplifies the
TJOperatorsmodule by creating the t-J operators from projecting the corresponding Hubbard operators, as discussed in #20. The tests on t-J model are unmodified.I finally decide to keep the
slave_fermionoption for convenience... But this requires me to copy some utility function from MPSKit and PEPSKit in order to add the fermion-Z2 charge.TODO:
@eval, the docstrings are missing and need to be added back.