You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello, I am a beginner in Block Sparse (BS) tensors, so I don’t fully understand the entire concept of their codes.
Currently, I need to contract BS tensors belonging to some edge that have different charges.
For example, in the case of DMRG algorithms for spin-1/2 systems, we need to have spin operators such as Sz, S+ (S-) renormalized by MPS tensors at each bond. When initializing MPS tensors with physical bonds having U1Charge([0, 1]), they can be contracted with Sz operators without any issues. However, S+ operators cannot be contracted at the same time.
I agree with that an operator like (Sz + Sp) is not a well-defined BS tensor. However, contractions between these edges could still be performed based on the charge numbers themselves. To avoid this issue, we could split the MPS tensors into two parts for each operator, but I wonder if this is not efficient in terms of memory resources.
Best regards
The text was updated successfully, but these errors were encountered:
@mganahl
Hello, I am a beginner in Block Sparse (BS) tensors, so I don’t fully understand the entire concept of their codes.
Currently, I need to contract BS tensors belonging to some edge that have different charges.
For example, in the case of DMRG algorithms for spin-1/2 systems, we need to have spin operators such as Sz, S+ (S-) renormalized by MPS tensors at each bond. When initializing MPS tensors with physical bonds having U1Charge([0, 1]), they can be contracted with Sz operators without any issues. However, S+ operators cannot be contracted at the same time.
I agree with that an operator like (Sz + Sp) is not a well-defined BS tensor. However, contractions between these edges could still be performed based on the charge numbers themselves. To avoid this issue, we could split the MPS tensors into two parts for each operator, but I wonder if this is not efficient in terms of memory resources.
Best regards
The text was updated successfully, but these errors were encountered: