@evaleev I believe this is ready for review now. Note that this PR has a cross-relation to #180 in that if either of these PRs is merged, the other needs to be updated.

/CC @ak-ustutt

Rebased against current master and thereby resolved the cross-dependence on the hash PR

Merged with master (no rebase due to too many conflicts with #184 - didn't feel like doing a rebase with those)

@Krzmbrzl thanks, this is quite a chunk of work!!! I just had a look at this ... do you recall what the issue is with the Wick engine not meshing with the new network graph? At least, what the symptoms were?

do you recall what the issue is with the Wick engine not meshing with the new network graph? At least, what the symptoms were?

@evaleev At first I ran into various asserts within the Wick impl due to not having resolved an implicit assumption about the graph representation. Those were about e.g. tensor core vertex ID's being usable as indices into the tensor vector of the network.
Once I fixed the code triggering the assertion I still had the issue of producing wrong results. Iirc for test cases I mostly saw failures where my patched code produced one or two additional terms.
Finally, running the srcc example, the performance was observed to be terribly degraded compared to the unpatched version. Furthermore, during the derivation of the doubles or triples residual (I think it was the doubles), RAM consumption simply kept increasing until my system ran out of RAM (32 GB). I believe that I somehow created an infinite loop in the recursive wick impl call tree.

Note that I did find some bugs in my new canonicalization routine after having re-introduced the old graph for the Wick program so perhaps (part of) the issue in the end was a buggy graph representation after all.

My biggest problem in all of this was that the wick implementation and the graph representation are tightly coupled, but only implicitly. That means that the wick implementation access what should probably be an implementation detail of the tensor network implementation (the exact graph representation).
If this dependence would instead be through a level of indirection (e.g. member function of a graph object (e.g. vertex_id_to_tensor_index)), refactoring would probably be a lot easier as then the parts of the code that need to be adapted is strictly limited to the implementation of these indirection functions.

@evaleev the new SRCC tests for CSVs are failing. One of them fails due to an unmet assertion that detected external indices are unique, but this unique-ness is based on Index::LabelCompare - this was overtaken from the old implementation. However, in the SRCC example 5 I now get two external indices {a_2^{{i_1}}} and {a_2^{{i_2}}} that only differ in their proto index label.
I would tend to replace the LabelCompare with a FullLabelCompare, but I'm not sure what the expected behavior is in this case as I have never worked with CSVs. Any insights from your end?