Open danielwe opened 6 years ago
hbar=1 is should be fine in my opinion since we are setting units. The way to relax this would be to go to SI, then the ZPM and stuff will be as set in https://en.wikipedia.org/wiki/Quantum_harmonic_oscillator
(Very very annoying…)
The idea was not to assume a particular numerical value.
One possibility is to include a symbolic factor of sympy.symbols('hbar', positive=True)
where appropriate (e.g., in symbolic_heisenberg_eom
), and let the user substitute this with 1 or a numerical value in output expressions if desired (although if the same symbolic factor is included when defining Hamiltonians, this factor should already have canceled in most expressions).
Perhaps one can also make this a global setting such that by default, qnet.hbar = 1
, but if desired the user may execute qnet.hbar = sympy.symbols('hbar', positive=True)
or something else at the beginning of a session.
Not a big deal, just wondering whether facilitating hbar != 1
might be a good idea and can be implemented cleanly.
I'm not sure I understand the point about the harmonic oscillator. Is ZPM referring to the zero point energy? I think that would be at the level of the user, when they define the Hamiltonian they can use SI or natural units (QNET only provides the building blocks). In particular, QNET does not provide the X and P operators for the Harmonic oscillator.
I think there's only very few places where hbar could show up explicitly. Basically, symbolic_heisenberg_eom
, symbolic_master_equation
, liouvillian
, and indirectly get_ABCD
, as far as I can tell. If that's it, I would propose adding a keyword argument hbar
to those routines that defaults to 1. If it's more routines, and/or it turns out to be too cumbersome in practice to use the keyword argument, I think Daniel's suggestion of defining a constant qnet.hbar
would be good. In any case, if possible, I wouldn't limit QNET to hbar=1
only. Basically, one should be able to write a notebook with a symbolic calculation that could directly be converted into a paper, and in a paper, you'd at least sometimes write out hbar. So we should support it.
Also, we should improve the documentation: Routines like symbolic_master_equation
say that they return "the RHS of the master equation", but this might be confusing because what the LHS is isn't entirely canonical (some people write $\dot\rho = ...$, some people $-i hbar \dot rho = ...$, etc). The full equation should be written out in the docstring. Also get_ABCD
is severely underdocumented (I'm not really sure what it does, exactly; it need a bit of context about what the linearization of an SLH model is). It also needs a test.
Now that I think about it, I think I agree with you Michael.
If someone wants to go SI, I guess its their choice. I was just making a remark that using SI will make the expression for even things like the position operator very involved. (X = x_{zero point motion} \hat x) is the mapping to move between the two.
But yeah, this should be an option for the user as you said.
Currently, hbar = 1 is implicitly assumed. Should we relax this? If so, what's the preferable way?