Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What to do about hbar? #59

Open
danielwe opened this issue Nov 25, 2017 · 4 comments
Open

What to do about hbar? #59

danielwe opened this issue Nov 25, 2017 · 4 comments
Labels
enhancement new or improved features

Comments

@danielwe
Copy link
Contributor

Currently, hbar = 1 is implicitly assumed. Should we relax this? If so, what's the preferable way?

@onoderat
Copy link

onoderat commented Nov 25, 2017 via email

@danielwe
Copy link
Contributor Author

danielwe commented Nov 25, 2017

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.

@goerz
Copy link
Member

goerz commented Nov 25, 2017

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.

@onoderat
Copy link

onoderat commented Nov 25, 2017 via email

@goerz goerz added the enhancement new or improved features label May 22, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement new or improved features
Projects
None yet
Development

No branches or pull requests

3 participants