(dot-eigenvectors ...) changes eigenvectors when mu_inv != null about mpb HOT 7 CLOSED

I've had a chance to look at this some more.

It appears that Hblock points to H, or at least that assigning to Hblock.data effects the same change to H.data. This was somewhat surprising to me. Is this intended?
This behavior means that calls to e.g. maxwell_compute_H_from_B(mdata, H, Hblock, ...) will change H (this is the reason for the issue above). Thus, trying to evaluate anything which depends on H after such a call will give inconsistent results.

Working with the W[0] work matrix instead of Hblock in dot_eigenvectors(...) sidesteps this issue, in principle - but that then ignores the comments in the code about W[0] then not necessarily having sufficient space.

from mpb.

If you have ≤ 11 bands (the eigensolver block size), then Hblock == H. See these lines.

W[0] should have the same size as Hblock, so it is the right thing. The comment you are referring to says that you can't dot all of the bands at once, you have to do them in blocks. W[0] has enough space for these blocks, though.

from mpb.

I don't know why I used Hblock there and not W[0] … it would be great if you submitted a pull request to change this to W[0].

from mpb.

Thanks for explaining that. I checked for >11 bands, and the problem indeed goes away.

I'd be happy to submit a pull request. Before doing so, I was hoping to quickly clarify one thing:
... to avoid trouble in the case that I'm requesting a large number of bands simultaneously be converted from B to H --- would an "ugly" splitting condition, based on the number of bands requested, be acceptable? (i.e. use W[0] if num-bands ≤ 11 and Hblock otherwise?)

from mpb.

(or, I guess, more generally, if num_bands ≤ block_size)

from mpb.

No, just use W[0] in all cases. It is the same size as Hblock.

from mpb.

Ah, I see. Okay, thanks.

from mpb.