Product state PEPS with noise

[pbrehmer]

Here we just add a function for creating product state PEPS with noise. This probably is a better initial state than just a completely random PEPS in many cases.

I excluded symmetric PEPS from the function since I wasn't sure if it is possible to generically construct a product state for any type of symmetric tensor.

[codecov]

Codecov Report

Attention: Patch coverage is 87.50000% with 2 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/algorithms/toolbox.jl	92.85%	1 Missing ⚠️
src/states/infinitepeps.jl	50.00%	1 Missing ⚠️

Files with missing lines	Coverage Δ
src/PEPSKit.jl	100.00% <ø> (ø)
src/algorithms/toolbox.jl	98.30% <92.85%> (ø)
src/states/infinitepeps.jl	70.37% <50.00%> (ø)

[lkdvos]

I definitely like this a lot, here's a few comments/questions:

Do we really want to normalize the peps? I think this requires a full ctmrg run, for which you cannot control the settings. Additionally, you would probably then want to reuse the environments for that in the next step, so that might not be ideal. I think it might be beneficial to keep it unnormalized, and leave that manual, or at least give the option?

I like that there is the option to select the basis for the product state, but it might be more physically relevant if we just allow a single-site-state vector, something like [sin(X), cos(X)] seems a little more intuitive to supply than a function handle that accepts the dimensions. It should be possible to then just embed that vector in the pepstensor I think.

[lkdvos]

Suggested change

	product_peps(peps_args...; unitcell=(1, 1), noise_amp=1e-2, basis_fun=ran, element_fun=randn)
	product_peps(peps_args...; unitcell=(1, 1), noise_amp=1e-2, basis_fun=rand, element_fun=randn)

[pbrehmer]

Do we really want to normalize the peps?

I just meant normalize as dividing by the array norm, not the physical norm, just to keep the numerical values in a reasonable range. I would also be against physically normalizing the PEPS, that would indeed be annoying to handle, so I would just leave as it is right now.

I like that there is the option to select the basis for the product state, but it might be more physically relevant if we just allow a single-site-state vector, something like [sin(X), cos(X)]

That would be nice indeed, but only [1, 0] or [0, 1] would actually lead to a product state, right? Of course we could just generalize the function to also include more general states, not just strictly product states. So perhaps something like

pt[:, 1, 1, 1, 1] = single_site_vector

is what you mean?

[lkdvos]

Any input vector would lead to a product state though, it's not the amount of nonzero values that determines that, it's the bonddim, which is 1: a vector really is just 2x1x1x1x1.

(You can think about it as there being a local basis change to the [1 0] state, so for example the plus state ++++ is still a product state)

I didn't know that norm(psi) gives the tensor norm, not the state norm. I am not sure I like that, but I guess it's necessary for the optimization routine?

[pbrehmer]

Sorry, got a bit confused about the product state thing but of course you're right. Now it should be implemented such that one can generate a single site vector from a kwarg function.

I didn't know that norm(psi) gives the tensor norm, not the state norm. I am not sure I like that, but I guess it's necessary for the optimization routine?

Well, for the state norm you also need the CTM environment, that's why norm(psi, env) gives the state norm. I don't think norm(psi) is needed for the optimization (just some inner is needed) but norm(psi) is rather used to normalize the PEPS tensors during CTMRG so that the tensor elements do not diverge.

[Jutho]

I am finally starting to look at Pepskit. It’s about time ;-). For generating a random initial PEPS, you might consider an isometric PEPS. Then the state (and tensor) norms are fixed to 1.

[lkdvos]

I guess for now it doesn't really matter too much, as we will "normalize" anyways during the optimization, so it does not make too much sense to invest in that.

[lkdvos]

Do we really want to keep it as a function handle now? I think supplying a vector is probably the easiest?

(I know the default argument then becomes a little more annoying because you need to know the size at that point, but maybe you could use nothing as the default and then check ?)

[pbrehmer]

I don't mind either way - now I implemented it such that you can supply a vector directly and it defaults to nothing where random Gaussian coefficients are used. I'd be fine with merging it like that :-)

Maybe as a side note: In many cases a product PEPS will not lead to better/faster CTMRG convergence because somehow CTMRG likes entangled states? Just from trying around, random PEPS often seem to be better initial guesses. Still, this might be a useful function.

[lkdvos]

Just as a small aside, this will work, but I think you might be misinterpreting this:
block will return a Matrix, which is the reshaped view of the tensor, the matrix representation of the linear map. Then, this is using the fact that julia is capable of indexing with trailing ones:

julia> A = zeros(3)
3-element Vector{Float64}:
 0.0
 0.0
 0.0

julia> A[1,1,1,1,1]
0.0

so this is completely equivalent to ptdata[:, 1] .= v, because of Julia magic.

If you want to access the "tensor data", i.e. as a N-dimensional array, for trivial tensors this can be achieved as pt[], which gives a 5d array (view) into the tensor data. pt[][:, 1, 1, 1, 1] .= v would then be more or less what I think you wanted to do.

Again, because of the specifics of this case, here it boils down to the same thing.

[pbrehmer]

Thanks for the tip, I wasn't aware. Then I would prefer using pt[] to make the indexing a bit more explicit in this case.