Fix example caching checksum

[pbrehmer]

Here we fix checksum such that it generates a hex code from a path relative to the PEPSKit project directory.

Previously, checksum would just use @__DIR__ which would be the full absolute path. This had the consequence that different users needed to rerun already cached examples.

[pbrehmer]

I'm also rerunning all the examples to generate a new Cache.toml so I will push that once that is completed.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[pbrehmer]

I'll rerun all the examples again once #226 is merged so the rendered output doesn't show the warnings.

[Yue-Zhengyuan]

Not quite related to this PR, but I notice that the AD part of J1-J2 example examples/j1j2_su/main.jl is having trouble. After 57 steps, it complains

┌ Warning:   Linesearch bisection failure: [a, b] = [1.92e-03, 1.92e-03], b-a = 1.16e-16, dϕᵃ = -6.98e-04, dϕᵇ = -6.98e-04, (ϕᵇ - ϕᵃ)/(b-a) = 7.67e+00
└ @ OptimKit ~/.julia/packages/OptimKit/G6i79/src/linesearches.jl:338
┌ Warning:   Linesearch bracket converged to a point without satisfying Wolfe conditions: [a,b] = [1.92e-03, 1.92e-03], dϕᵃ = -6.98e-04, dϕᵇ = -6.98e-04, ϕᵃ - ϕ₀ = 1.00e-06, ϕᵇ - ϕ₀ = 1.00e-06
└ @ OptimKit ~/.julia/packages/OptimKit/G6i79/src/linesearches.jl:267

Then, at step 97, the imaginary part of the measured energy (cost_function) becomes non-negligible:

┌ Warning: Expectation value is not real: -1.9765438384889413 + 3.192090457085267e-7im.
└ @ PEPSKit ~/repos/PEPSKit.jl/src/algorithms/toolbox.jl:50

Before #219 we don't have these warnings. The initial state produced by SU right now is more C4v symmetric, but the energy is slightly higher than before. @pbrehmer Can you try tweaking the AD parameters (e.g. use gradient_alg=(; iterscheme=:diffgauge) to keep things real) and see if we can improve the result?

[pbrehmer]

Thanks for pointing that out, I'll take a look!

Update: Using iterscheme=:diffgauge does not improve the results and gets stuck at a similar energy. I suspect that its best to limit the number of optimization steps and terminate the optimization early. Probably $\chi=32$ is a bit too small to obtain better energy estimates at $D=4$. Nonetheless, the energy estimates that are now slightly worse than before still improve over the YASTN estimates.

[pbrehmer]

It took some extra effort to get it below the YASTN estimate again - I had to add some noise to the SU PEPS to break some of the C4v symmetry. The optimization will get stuck too at some point (as expected) but it can converge to a lower energy. This would be good to go for me now!