Some problems when trying to run large circuits (maybe just some missing instructions in the docs)

[MatteoRobbiati]

General description

I am trying to simulate quantum circuits using QiboTN and I would like to push the number of qubits to ~100.
As far as I understand, I have to set the approximation parameters via backend's runcard argument, as shown in the README.md.

I tried with qutensornet platform but it crashes:

File [~/Documents/PhD/envs/qibo/lib/python3.10/site-packages/quimb/tensor/tensor_core.py:2208](http://localhost:8888/home/matteo/Documents/PhD/envs/qibo/lib/python3.10/site-packages/quimb/tensor/tensor_core.py#line=2207), in Tensor.split(self, *args, **kwargs)
   2206 @functools.wraps(tensor_split)
   2207 def split(self, *args, **kwargs):
-> 2208     return tensor_split(self, *args, **kwargs)

File [~/anaconda3/envs/eqibo/lib/python3.10/functools.py:878](http://localhost:8888/home/matteo/anaconda3/envs/eqibo/lib/python3.10/functools.py#line=877), in singledispatch.<locals>.wrapper(*args, **kw)
    874 if not args:
    875     raise TypeError(f'{funcname} requires at least '
    876                     '1 positional argument')
--> 878 return dispatch(args[0].__class__)(*args, **kw)

TypeError: tensor_split() got an unexpected keyword argument 'qr_method'

---

Similarly, for the cutensornet crashes.

---

If I try to run the code without settings, it get killed if involving $\geq 28$ qubits (I guess because there is no approximation (?))

---

What is the way to set the approximation level?
And, is there a way to collect metrics quantifying this approximation?

To replicate

from qibo.models import QFT
import qibo

computation_settings = {
    "MPI_enabled": False,
    "MPS_enabled": {
        "qr_method": False,
        "svd_method": {
            "partition": "UV",
            "abs_cutoff": 1e-12,
        },
    },
    "NCCL_enabled": False,
    "expectation_enabled": False,
}

qibo.set_backend("qibotn", platform="qutensornet", runcard=computation_settings)

circ = QFT(nqubits=28)
probs = circ().probabilities()

[liweintu]

Thanks @MatteoRobbiati for reporting this.

From the error messages, it seems that the argument fed into the quimb library function is unexpected, probably due to not being required or format not being compatible. @Vinitha-balachandran and I will take a look.

For the approximation, I remember there are some arguments for that in cutensornet. We haven't explored how to tune the approximation knob yet, so most likely, it's not set. @Tankya2 and I can think about how to expose this knob to users to experiment with the approximation impact.

[alecandido]

Sorry @liweintu, the conversation has been (at least partially) solved in private.

So, the problem reported here is actually that the configurations are not uniform across qutensornet (i.e. Quimb, most likely we should rename it...) and cutensornet backends. And yes, qr_method is not a configuration exposed by the Quimb wrapper, though the entirety of the value associated to the "MPS_enabled" key is passed to a Quimb function.

Moreover, another problem that arose has been that "MPS_enabled" sounds like a flag, and it can be a flag (i.e. True/False), but it can also be a whole dictionary of specs (as in the case reported above), whose structure is specified nowhere in the docs (and the defaults applied are not reported as well), so you need to inspect the code to work them out

qibotn/src/qibotn/backends/quimb.py

Lines 17 to 25 in 4f54772

	mps_enabled_value = runcard.get("MPS_enabled")
	if mps_enabled_value is True:
	self.mps_opts = {"method": "svd", "cutoff": 1e-6, "cutoff_mode": "abs"}
	elif mps_enabled_value is False:
	self.mps_opts = None
	elif isinstance(mps_enabled_value, dict):
	self.mps_opts = mps_enabled_value
	else:
	raise TypeError("MPS_enabled has an unexpected type")

In the end, it's all about documentation.

[MatteoRobbiati]

From the error messages, it seems that the argument fed into the quimb library function is unexpected, probably due to not being required or format not being compatible. @Vinitha-balachandran and I will take a look.

Thanks! As mentioned by @alecandido (and my apologizes, because I discussed with him and then forgot to update the issue), it is now clear the two backends support different arguments when being initialized. My personal opinion is that we should try to standardize the features we can have access to. It doesn't mean we need to standardize the interface, but at least being able to replicate similar scenarios using the various backends.

For the approximation, I remember there are some arguments for that in cutensornet. We haven't explored how to tune the approximation knob yet, so most likely, it's not set. @Tankya2 and I can think about how to expose this knob to users to experiment with the approximation impact.

Ups, I kind of replied above. Indeed, it would be useful to have a documented list of metrics one can access :)

Thanks for your reply!