Losing QN information when reading from HDF5

[Thomas-Kiely]

I find that, when reading a QN Index object from an HDF5 file, the block structure is retained but I don't recover the quantum numbers associated with each block. For example,

auto io = Index(QN({"Sz",0}),1,QN({"Sz",-1}),1,QN({"Sz",+1}),1,Out,"index");
auto fo = h5_open("test.h5",'w');
h5_write(fo,"index",io);
close(fo);

auto fi = h5_open("test.h5",'r');
auto ii = h5_read<Index>(fi,"index");

println(ii == io);
println(ii);
println(io);

produces

1
(dim=3|id=34|"index") <Out>
  1: 1 QN()
  2: 1 QN()
  3: 1 QN()
(dim=3|id=34|"index") <Out>
  1: 1 QN({"Sz",0})
  2: 1 QN({"Sz",-1})
  3: 1 QN({"Sz",1})

I can read the same HDF5 file in Julia, however, where I recover the quantum numbers for each block. So this seems to be a problem with the C++ read function.

[ShimpeiGoto]

I still encounter this issue and investigate what makes the issue.

The problem is QN::addNum used during the reading. QN has four slots for quantum numbers, and QN::addNum sorts the four quantum numbers in lexical order defined in C++. In the lexical order defined in C++, an empty string comes first. Consequently, the slots of QN after reading becomes (empty, empty, empty, Sz). In printing QN, the printFull function is used, and the printing process stops when an empty slot is found. As a result, QN information seems to be lost even though the block information can be recovered.

Since the QN information is read correctly, the issue might be harmless. However, the order of the slots would not be the supposed one, as inferred from the design of the printFull function. It would be better to modify QN::addNum so that inactive slots come later. A simple solution is returning from QN::addNum immediately when an inactive Qnum is input. PR #424 contains this modification.