No doTask specified for AutoMPO creating QMixed storage

Question

I have been using AutoMPO to create MPO's with both onsite and nearest-neighbor terms, but after a recent update, this no longer seems to work as before:

const int N = 4;
SpinHalf hs(N);

AutoMPO ampo(hs),bmpo(hs);
for(int i = 1 ; i <= N ; ++i) {
    if(i != N) {
        ampo += -1.0,"Sz",i,"Sz",i+1;
        bmpo += -1.0,"Sz",i,"Sz",i+1;
        }
    bmpo += -1.0,"Sx",i;
    }
auto A = MPO(ampo);
println("checkpoint 1");
auto B = MPO(bmpo);
println("checkpoint 2");

For me, MPO A (with pair terms only) correctly generates, but the second call to the MPO constructor causes the program to crash with the following ITError:

doTask not defined for task CalcDiv and storage type QMixed<Real>

Which I suppose comes from the storage type changing between the two cases. I am up-to-date with the git branch master.

Answer 1

Edit: fixed on Sep 28
https://github.com/ITensor/ITensor/commit/f426166

Hi Brendan,
Unfortunately this is just a straight up bug / missing feature in version 2 right now.

The longish explanation is that in order not to have to write the AutoMPO logic out twice, I wrote it for IQTensors/IQMPOs and then use this to handle the ITensor/MPO case as well. In version 1, IQTensors were a lot less "picky" about whether they were well-defined or not. But in version 2, they are a lot more strict which makes them much more efficient but also means you can't get away with some tricks I was using before.

So what I need to do is to rewrite AutoMPO to handle the case of operators which don't conserve quantum numbers such as Sx. This is on my short list of things to do, but will take a week at least.

Please email me in a week or two if you haven't heard back and I can let you know where I'm at with it.

Miles

Comments

Hi Miles,

I see now, I originally guessed that QMixed was just some sort of compression format and this was a simple matter of implementing a method. Appreciate the commitment to a relatively major overhaul. (Also non-QN conserving operators seem to work fine in the v2.0.10 branch, so it's not like I have to roll it way back.)

Brenden

---

Hi Brenden,
Turns out it wasn't such a big fix after all (as you noticed it still worked as recently as v2.0.10). So I was able to fix it much more quickly than expected.

Please try the latest tip of the master branch and let me know if it still doesn't work for you.

Miles