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

Make sdiag_inv_sqrt use pseudo-inverse #78

Merged
merged 8 commits into from
Oct 29, 2024
Merged

Conversation

pbrehmer
Copy link
Collaborator

Implements pseudo-inverse for the inverse square root inside of sdiag_inv_sqrt and its reverse-rule.

Closes #73 as suggested by @huangrzh.

Copy link

codecov bot commented Oct 24, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Files with missing lines Coverage Δ
src/utility/util.jl 57.30% <100.00%> (+1.48%) ⬆️

... and 6 files with indirect coverage changes

@pbrehmer
Copy link
Collaborator Author

I'm not super sure about the default inverse cutoff tolerance to choose here; any opinions on this? @lkdvos

@pbrehmer pbrehmer requested a review from lkdvos October 25, 2024 08:00
@lkdvos
Copy link
Member

lkdvos commented Oct 28, 2024

I think TensorKit uses a tol which corresponds to eps(real(float(scalartype(T))))^(3/4) * svals[1] in the tsvd rrule, maybe we could just use the same?

@pbrehmer
Copy link
Collaborator Author

I like that TensorKit way of handling the singular value cutoff tolerance. I have decided to again cut the inv_sqrt_tol field from ProjectorAlg since that is probably anyway a too fine-grained parameter. Also there is not a good consistent way to tweak that same tolerance inside the rrule of tsvd! from within PEPSKit, so I think it's better to just leave that parameter away and define a reasonable default.

lkdvos
lkdvos previously approved these changes Oct 29, 2024
@lkdvos lkdvos dismissed their stale review October 29, 2024 00:21

missed failing tests

@pbrehmer
Copy link
Collaborator Author

Also updated the p-wave tests a bit and again found it weird that apparently the p-wave differentiation in :fixed mode leads to very high gauge-sensitivity. (This is not the case for the :diffgauge mode.) My suspicion is that this is improved with the fix in #72, where the gauge-fixing contractions had daggers in the wrong place and perhaps these daggers matter in the fermionic case. I will investigate further with the Hubbard model...

@pbrehmer pbrehmer requested a review from lkdvos October 29, 2024 12:43
lkdvos
lkdvos previously approved these changes Oct 29, 2024
Copy link
Member

@lkdvos lkdvos left a comment

Choose a reason for hiding this comment

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

Looks good to me. If you checked the gauge sensitivity again after the fixes, Im okay with merging this like this.

@@ -36,8 +31,8 @@ gradmodes = [
LinSolver(; solver=KrylovKit.GMRES(; tol=gradtol), iterscheme=:fixed),
LinSolver(; solver=KrylovKit.GMRES(; tol=gradtol), iterscheme=:diffgauge),
],
[
nothing,
[ # Only use :diffgauge due to high gauge-sensitivity (perhaps due to small χenv?)
Copy link
Member

Choose a reason for hiding this comment

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

did you re check this after the gaugefixing fixes?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Okay I checked again and the gauge-fixing fixes don't make a difference to the high gauge-sensitivity. I will have to investigate and fix that in a different PR. I just haven't played around that much with fermions yet.

I put back in nothing to the test, since I accidentally left that commented out as I was trying around.

Comment on lines +13 to +19
ctm_alg = CTMRG(;
tol=1e-8,
maxiter=150,
verbosity=2,
ctmrgscheme=:simultaneous,
svd_alg=SVDAdjoint(; rrule_alg=Arnoldi(; tol=1e-9, krylovdim=χenv + 30)),
)
Copy link
Member

Choose a reason for hiding this comment

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

at the risk of sounding like a broken record, I really don't like that we have to change the settings of all algorithms on every single update of the package. We really have to get some better defaults in, because this is not really feasible in the long run. (not something that has to be fixed in this pr)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

You definitely have a point in repeating that and I completely agree :-) Actually, for most of the tests we should already be able to replace all settings with the default ones I just haven't gotten around to change them. I just thought that I would wait until we anyway redesign our interface and code up some kind of default parameter selection thing.

Copy link
Member

@lkdvos lkdvos left a comment

Choose a reason for hiding this comment

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

OK if tests turn green.

@pbrehmer pbrehmer merged commit 1b2b22d into master Oct 29, 2024
9 checks passed
@pbrehmer pbrehmer deleted the pb-inv-sqrt-tolerance branch October 29, 2024 16:10
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.

pseudo inverse in sdiag_inv_sqrt?
2 participants