Seeming preference for values of some operators

Created by: rodrigoaraizabravo

Hello, I've been playing with the NetKet code for some time now. In particular, we've seen a particularly interesting behavior when it comes down to measuring one-site observables of the Ising 1D model in the ferromagnetic regime. Let us say we run the code as pointed in the Ising1d tutorial for different values of the transverse field h \in [0J,2J]. We can also measure some in-site observables such as the in-site magnetization by specifying:

def sigmaz():  #Defines the third Pauli matrix
    return np.array([[1,0], [0, -1]])

def get_loc_obs_dict(i, O, name=''):  #Defines the information to be passed to the pars['Observables']
    sites =[[i]]
    ops = [O.tolist()]
    return dict(ActingOn=sites,Operators=ops,Name=name+str(i))

#Defines observables to measure during the learning procedure
    pars['Observables'] = []
    for i in range(L):
        pars['Observables'].append(get_loc_obs_dict(i, sigmaz(), `name='z'))```

I've also written a python script that runs a simulation on an L=12 chain for 40 equally spaced values of h in the interval specified. The energy has no trouble converging, and in fact observables such as <Z_iZ_{i+1}> also converge to the right values, but our in-site magnetization doesn't (see figures in the attachments). Sampling though different values for the hidden nodes did not help, as can be seen in the image I provide. The issue is prominent when the energy gap is small.

The issue is not that the theoretical and learnt in-site magnetization seem to disagree with the small h values, but that NetKet seems to converge to ground states which prefer a negative in-site magnetization. I've been looking through the documentation and I cannot seem to spot the issue.

I was wondering if I could be given some guidance on how to approach this issue. I've look through the seed in Utils/random_utils.hpp and the initialization ansatz in Machines/rbm_spin.hpp but haven't seen any issues. I even wrote an initialization scheme that approximates a GHZ state from the get-go, but the in-site magnetization is still negative. I'd be happy to give more details if needed.

added physics question label

Created by: gcarleo

What sampler are you using? Try MetropolisLocalPt with Nreplicas=32 and let me know

Created by: rodrigoaraizabravo

I tried MetropolisLocalPt on an L=4 chain with RBMSpinSymm just to make it run faster. The disagreement prevails. I should explain the graphs better. For the observables' graphs, the crosses 'x' represent the average of the last 10 values for the expectation values of each observable found in the output.log file. The 'op from wf' lines correspond to the expectation values calculated from recovering the wave function from the 'output.wf' file, which we can do without a lot of trouble for small systems (for comparison purposes). The curves in the energy graph correspond to the exact and NetKet's ground energy. We also show the first excited state so we can visualize the energy gap.

Created by: gcarleo

I have the impression that with the PT sampler the magnetisation is a little closer to zero for small h. Is that correct? For example here I see -0.75 at h=0, and not -1 as before?

The point is that then h->0 you recover the classical limit, in that case it is well known that your magnetisation can stay finite in MCMC simulations, because of non-ergodicity of the sampling. In turn, if at each step of the optimisation you stay in a certain magnetisation sector, then also the wave-function parameters will follow that sector and leave you with a finite magnetisation at the end of the optimisation. This is not a bug in the code, I would say it is a feature of the Ising model!

If magnetisation per site is an important quantity for you (it shouldn't be, since the relevant quantities here are two-body quantities such as the correlations ZZ) PT is a way to improve on that, but you have to make sure that the number of replicas is large enough to do so. The number I suggested might not be good, I didn't try it. The other thing you can try is to remove the visible bias from the wave-function. Usea=False should be the relevant option, please check. This should maybe improve a little bit, since it will not tend to break the symmetry explicitly with the visible field.

Created by: rodrigoaraizabravo

Thank you for the help. The -0.75 in the graph differs from the previous graph because of the smaller system size. However, as I step through the number of replicas though Nreplicas=64, 80, 100 I found no improvement. I will continue through the other suggestions you gave in the upcoming days.

Created by: gcarleo

I did a couple of tests, indeed what you see is related to the bias term in the RBM. With these parameters I find magnetizations reasonably close to zero for small value of the transverse field:

pars['Machine']={
    'Name'           : 'RbmSpin',
    'Alpha'          : 1.0,
    'UseVisibleBias' : False,
    'UseHiddenBias' : False,
}

#defining the sampler
#here we use Metropolis sampling with single spin flips
pars['Sampler']={
    'Name'           : 'MetropolisLocalPt',
    'Nreplicas' : 64,
}

Created by: gcarleo

By the way, I like the way you coded the observable input in python! We should wrap up a nicer python interface for NetKet, see also issue #8 (closed)

closed

Created by: rodrigoaraizabravo

Thank you! This solved the problem we had. Will take a look at the other issue.