Access QSpace Data

The information of QSpace objects can be accessed in a similar way as for struct variables. The quantum numbers of F are accessed by:

F.Q % cell array of quantum numbers

ans = 1x3 cell

	1	2	3
1	[-1,0;0,1]	[0,1;1,0]	[-1,1;-1...]

F.Q{1} % first leg

ans = 2x2
     -1     0
      0     1

F.Q{2} % second leg

ans = 2x2
     0     1
     1     0

F.Q{3} % third leg

ans = 2x2
     -1     1
     -1     1

A m-th row of F.Q{n} indicates the quantum number of the m-th symmetry sector for the n-th leg space.

The reduced matrix elements are accessed by:

F.data % cell array of reduced matrix element data

ans = 2x1 cell

	1
1	-1.4142
2	-1.4142

celldisp(F.data) % display the contents of a cell array

Of course, we can change the values of the data sector. For example,

F2 = F;
F2.data{1} = 10;
F2

F2 =
    Q: 2x [2 2 2] having 'A,SU2',   operator   { , * , * }
 data: 3-D double (224 bytes)    2 x 2 x 1 => 3 x 3 x 2

    1. 1x1x1        | 1x2x2        [ -1 0 ; 0 1; -1 1 ]             10.
    2. 1x1x1        | 2x1x2        [ 0 1 ; 1 0; -1 1 ]              -1.414

Also we can set and edit the itags (index tags). The itags are saved as the cell array .info.itags. Each cell element is a char array, which should be consistent with the direction of each leg. When the itag of a leg ends with , it means that the leg is outward. Otherwise, the leg is inward. Since the original direction was in-out-out, the first itag should not include and the second and third itags should end with *.

F2.info.itags = {'s00','s00*','op*'}

F2 =
    Q: 2x [2 2 2] having 'A,SU2',   operator   { s00, s00* , op* }
 data: 3-D double (224 bytes)    2 x 2 x 1 => 3 x 3 x 2

    1. 1x1x1        | 1x2x2        [ -1 0 ; 0 1; -1 1 ]             10.
    2. 1x1x1        | 2x1x2        [ 0 1 ; 1 0; -1 1 ]              -1.414

Here the name of the space, s00, for the first and second legs means that the legs act on the space of the local site s00. And the name op for the third leg means that it indicates the nature of the operator, not acting on the physical space.

One can try to set the itags to be inconsistent with the original itags. Then the QSpace library detects the inconsistency in the data and gives error message.

try
    F2.info.itags = = {'s00','s00'','op*'};
    F2
catch e
    getReport(e);
end

F2 =
    Q: 2x [2 2 2]   having 'A,SU2',   operator   { s00, s00 , op* }
./clebsch.cc:3605   15:29:54 ERR init() got CGR QSet mismatch ./clebsch.cc:3605  15:29:54 ERR U(1) (-1,0,-1) <> U(1)

The itags are really useful when we treat many tensors at the same time. For example, when many tensors are contracted sequentially (as in TN/Tensor/updateLeft), tracking down the leg order at each contraction step is quite tedious job, and is often the source of bug, if one makes a mistake in counting the leg order. By using itags, however, the QSpace library performs the sanity check for the compatibility of legs, and enables the contraction multiple tensors/legs with simple syntax!

We emphasize that one can directly edit only the reduced matrix elements (.data) and itags (.info.itags) of QSpace objects. Tinkering any other part of QSpace object may break the consistency of data; and the QSpace library detects such consistency, as you see from the above example of wrong itags.