New Bilinear Routine

[evanberkowitz]

THIS IS A BREAKING CHANGE

Two changes are breaking.

1. First, i changed the name of the projector argument to transform argument, which I think is a better name and will wind up being made across the observables in time. The reason for the name change is twofold: i think that the transform need not be unitary, in that it could be to a subspace, and also a unitary transformation isn't a projector!

2. The observables that get calculated are different! The correlation functions are Splus_Sminus, Sminus_Splus, np_np, np_nh, nh_np, nh_nh, ++_––, ––_++, S1_S1, S1_S2, rho_rho, rho_n, n_rho, and n_n. n=np+nh, ++ and –– are charge-±2 bilinears

No longer computed is S3_S3. Never computed, before or with this change, is S0_S3, S3_S0, S0_S0. As explained in the updated documentation, these can be constructed from the computed correlators and the one-point functions. I propose adding this construction to archipelago, as it can be done in the analysis step. However, I can add it to this observable, to keep it self-contained, if that's better.

Exact correctness: i believe I have double-checked that everything now matches exact results. I found that running the example (U=2, b=3) in the documentation for the triangular lattice and diagonal discretization really did well, with just dumb reweighting and no fancy analysis (thanks to the 'easy' parameters).

[jl-wynen]

Is it even necessary to compute S1_S1, S1_S2, rho_rho, rho_n, n_rho, n_n in the measurement or can they be constructed afterwards? I think it makes more sense to add this as a separate function along with the other correlators you mentioned so they can be constructed during the analysis.

[evanberkowitz]

It isn't necessary. The only necessary correlators are the directly computed ones; everything else is linear combinations. However, because it's constructed via identity after the more intensive einsum operations are complete, it shouldn't be too bad for performance to keep them. If you're worried about memory / h5 size I understand, however.

How would you add this in a separate function? In the SpinSpinCorrelator object? In archipelago, not in isle at all?

[evanberkowitz]

Sorry, I should also say: it is necessary to do the linear combination combining before bootstrap.

[luutom]

Sorry, Evan, stupid question. So the bugs that you found here (and fixed) were responsible for the strange spin-spin results that Jan-Lukas found?

[evanberkowitz]

I have no idea if the new measurement fixes the weird result @jl-wynen found.

[evanberkowitz]

@jl-wynen Here's my idea. We can accumulate data in a single dictionary.

For example we can do

with h5.File('measurements.h5','r') as f:
    data = {
        **isle.meas.onePointFunctions.read(f["correlation_functions/one_point"]),
        **isle.meas.spinSpinCorrelators.read(f["correlation_functions/spin_spin"]),
        # etc
        }

data = isle.meas.onePointFunctions.complete(data) # computes rho, n, S3 from nh, np
data = isle.meas.spinSpinCorrelators.complete(data) # computes correlators from S+S- etc.

Anway, .read reads in just what was computed in the measurement; .complete does further computation to reconstruct other things via identity.

Maybe this isn't the most archipelago-oriented solution? Anyway, even if it's not global perfection, it's good if we just consider isle.

[jl-wynen]

Reading in the correlators is a bit tricky because of all the metadata. I would prefer not adding this kind of feature to Isle because it depends on the circumstances, what exactly you want to read and how. In any case, making the complete function take only one dictionary as argument sounds good. It can be constructed regardless of how the data was read. I am not very fond of the name though, I would prefer something like derivedCorrelators.

[evanberkowitz]

OK, I can skip the reading part, and just do the dict --> dict part.

I was hoping to make the procedure's name a verb. But I'll find something.

[evanberkowitz]

OK. I need to do a test of the onePoint-reliant reconstructed correlators, but I think they're right.

I changed .complete to .useIdentities.

[evanberkowitz]

What do you think about making computeDerivedCorrelators a @staticmethod or @classmethod? I feel like that makes it more sensible, as that way it's not a stand-alone module function?

[evanberkowitz]

OK, I brought SingleParticleCorrelator in line with the other guys, and added the computation of the opposite-order correlators. I compared with exact correlators both the SingleParticle and SpinSpin guys (though not the 'reconstructed' guys), to my satisfaction.

U=2, beta=3, nt=64, diagonal discretization, 1000 measurements on 10,000 hmc steps.

The "exchange" of np and nh is repaired. All measurements seem to be functioning as expected.

@jl-wynen If you're happy with the single_particle/creation_destruction, single_hole/destruction_creation naming, this branch can be merged as complete.

[luutom]

Nice!

[jl-wynen]

Very good! I'm happy with the names.