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

Epole matrix element #19

Open
pathfinder49 opened this issue May 13, 2020 · 8 comments
Open

Epole matrix element #19

pathfinder49 opened this issue May 13, 2020 · 8 comments

Comments

@pathfinder49
Copy link
Member

In calc_Epole() it states the following:
https://github.com/OxfordIonTrapGroup/ion_phys/blob/da3c5ef9fe868aa297426506801e9f02a77c2f67/ion_phys/common.py#L353-L362

I could work this through, but it seems prudent to verify the matrix element definition used. Happy to update this once I understand the conventions.

@RHanley1
Copy link
Member

My pull request #10 aims to define the conventions etc used. I would suggest reading this, as I believe it to be consistent with the code.

@pathfinder49
Copy link
Member Author

In your document, you define the matrix element as:
image
This relates to the spontaneous transition rates via:
image
This does not seem to match the ePole definition in the code. Instead the ePole contributions for a transition are calculated as np.sqrt(A*(2*Ju+1)) * <sum of transition wigber3js> .

Without checking the wigner3j maths, the usage looks like the ePole elements are defined such that:

abs(ePole)^2 = A_ji

This leaves the phase definition of the epole elements unclear.

@pathfinder49
Copy link
Member Author

ePole is implemented as dtype=np.float64. (Entries are both +ve and -ve. )

  • This is fine for coherent simulations. (Rabi fequencies between bound states are real).
  • The sign of the ePole elements has no physical significance?

@RHanley1
Copy link
Member

This relates to the spontaneous transition rates via:
image
This does not seem to match the ePole definition in the code. Instead the ePole contributions for a transition are calculated as np.sqrt(A*(2*Ju+1)) * <sum of transition wigber3js> .

The definition you quote is correct for a single two-level transition. As discussed in section 1.2.1, one typically has access to the manifold decay rate, which is related to the individual transitions by
image
. Now, this is only true for angular momentum eigenstates J. When the states is a superposition of J eigenstates, one must sum over the the superposition, as discussed in 1.4.1. In this case, the phase factor is relevant, and I believe the definition in the code to be correct. .

@pathfinder49
Copy link
Member Author

pathfinder49 commented May 15, 2020

Thank you for pointing out the relation to the fine structure decay rates. Though I'm more interested in the numerical definition of the Ion.ePole matrix elements and how they relate to more standard properties of the corresponding transition between hyperfine eigenstates. The relation to A_ij is useful for constructing the density matrix evolution.

I was working under the assumption that the of the code is correct for it's current purposes.

@pathfinder49
Copy link
Member Author

The signs of Ion.ePole elements are subject to change, see #11

@hartytp
Copy link
Contributor

hartytp commented May 19, 2020

This leaves the phase definition of the epole elements unclear.

It doesn't leave the phase definition totally unclear because at non-zero B-field you get state mixing so if you don't get the phases right you don't calculate the correct decay rates. However, this doesn't fix the phases for states in different levels (e.g. for processes involving multiple fine structure levels).

@pathfinder49
Copy link
Member Author

pathfinder49 commented May 19, 2020

What I mean is: I'm unclear on the definition of Ion.ePole phase within the ion_phys package.

Regarding the state mixing, Isn't this already accounted for by the conversion from Ion.ePole_hf to Ion.ePole?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants