Clarify confusion between kraus operators and collapse operators #616

a-corni · 2023-11-23T15:12:28Z

Given that qutip.mesolve uses collapse operators and not kraus operators, I propose to delete the trace of kraus operators in our code and documentation.

Modify the name of the variable kraus_ops to local_collapse_ops in set_config.
Delete the L_0 operators from both notebook and code. Delete condition that first effective operator should be an identity and that sum of probability*operators is equal to identity (that's a condition on kraus operators, not on lindblad operators).
Replace the link to Preskill's notes to Nielsen and Chuang's "Quantum Computation and Quantum Information" to justify $L_i = p/4 \sigma_i$ in depolarizing noise.
Replace probabilities by rates in notebook and replace p(1-p)^(n-1) by gamma. Hopefully, the results (in the notebook at least) are not changed significantly.
Rename variables refering to probabilities to rates. Could we keep probabilities and define the rate as gamma = proba / (duration of the sequence) @dehond ?

Closes #608

review-notebook-app · 2023-11-23T15:12:33Z

Check out this pull request on

See visual diffs & provide feedback on Jupyter Notebooks.

Powered by ReviewNB

dehond · 2023-11-23T15:21:49Z

* [ ]  Rename variables refering to probabilities to rates. Could we keep probabilities and define the rate as gamma = proba / (duration of the sequence) @dehond ?

I'd suggest that ideally everything is relabeled as a rate so that nothing depends on the sequence length. If the decay rate of some excited state is 0.1/μs, the probability of decay during 1 μs is (approximately) 0.1, but how do we define the probability of decay during a 10 μs sequence, or longer?

If you'd like to turn it around we face similar issues: we know that the probability of decay during a 10 μs sequence is $1-e^{-1} = 0.63$, but it's not accurate to say that this means that the probability of decay during a 1 μs sequence is $0.63/10 = 0.063$.

a-corni · 2023-11-24T08:03:11Z

* [ ]  Rename variables refering to probabilities to rates. Could we keep probabilities and define the rate as gamma = proba / (duration of the sequence) @dehond ?
I'd suggest that ideally everything is relabeled as a rate so that nothing depends on the sequence length. If the decay rate of some excited state is 0.1/μs, the probability of decay during 1 μs is (approximately) 0.1, but how do we define the probability of decay during a 10 μs sequence, or longer?

If you'd like to turn it around we face similar issues: we know that the probability of decay during a 10 μs sequence is 1−e−1=0.63, but it's not accurate to say that this means that the probability of decay during a 1 μs sequence is 0.63/10=0.063.

Thanks Julius, I was also puzzled by these issues. I will implement the replacement of variables with _proba into _rate. I will put a DeprecationWarning signaling their deprecation.

pulser-core/pulser/backend/noise_model.py

HGSilveri · 2023-12-08T11:48:40Z

pulser-core/pulser/backend/noise_model.py

+                warnings.warn(
+                    f"{prob_name} is deprecated. Use {rate_name} instead.",
+                    DeprecationWarning,
+                )


Remember that these deprecation warnings won't show up during normal operation. Perhaps that's the way we want things to work, but I figured it was worth noting

What do you mean by "normal" operation ? In a notebook ?

For example, can be a script too. In general, whenever users are using the code directly I think deprecation warnings don't show by default. I've had this happen before, at least.

HGSilveri · 2023-12-08T12:00:25Z

pulser-simulation/pulser_simulation/hamiltonian.py

-                raise NotImplementedError(
-                    "Cannot include general "
-                    + "noise in digital- or all-basis."
+            basis_check("general")


So we are renaming "effective" to "general"?

Yeah that's what we were doing... It would make more sense to display it at "effective" instead.

I don't know about "general", "arbitrary" or "custom" would make more sense to me. In any case, we are not doing the renaming here so we could defer the decision to a future PR. I'm just afraid that if you change to "general" here and then we decide to go with something else, this might be forgotten.

So we were already going for "General" in several places, but I find it does not make much sense... This is why I decided to go with "effective" instead