haeffnerlab / ionsim.jl Goto Github PK

That way people know what's on the roadmap, and what could be implemented in the framework.

this will fix the tests

I recommend removing any tool you are not really supporting. If you are going to hang out on Gitter, I recommend keeping it. Otherwise, I would use an email address or a GitHub issue so you will actually see the request.

Example:
Dict("D5/2" => PhysicalConstant(4.1115503183857306e14, "Hz"))
Returns the error "TypeError: in new, expected PhysicalConstant, got Float64". This seems to be caused by the Base.convert for PhysicalConstants added in constants.jl. I suspect there's something not quite right with this usage of convert, as defining this method alone breaks all instantiation of PhysicalConstants (even outside of Dicts); the Base.Fix2 method seems to patch this up, but does not fix the problem when the instantiation takes place inside a Dict. I do see that some sort of Base.convert method is necessary, as it allows mathematical operations with regular numbers, but not sure how it would need to be fixed.

It would be nice to be able to do this so that in species files e.g. /src/species/ca40.jl we can directly define energies and transition matrix elements as PhysicalConstants within dictionaries.

The hamiltonian construction currently assumes how the state is constructed.

e.g. to create a full state of the electronic & motional degree of motion you'd start by defining the states separately:
ψi_ion = dm(C["S-1/2"])
ψi_axial = thermalstate(axial,1)

and then do the tensor product to build the full hilbert space.

The hamiltonian function expects that you built the state with:
ψi = ψi_ion ⊗ ψi_axial;

but it's also valid to say:
ψi = ψi_axial ⊗ ψi_ion;

(but in that case the hamiltonian would be constructed differently).

There are two options:
(1) state this explicitly in the documentation (also have to have a explicit ordering of motional modes).

(2) modify the hamiltonian function to take a set of individual states, each with some information of what kind of state it is, and then the hamiltonian function makes both ψi and the hamiltonian.

Example:
# Define the initial density matrix
ρ_axial = thermalstate(axial_mode,6)
ρ_radial = thermalstate(radial_mode,6)
ρ_ions = dm(Ca["D-1/2"] ⊗ Ca["S-1/2"])
ρ_initial = ρ_ions ⊗ ρ_axial ⊗ ρ_radial
returns IonSim: Incompatible basis without further information

Temporary solution is to reorder the vibrational modes density matrix:
ρ_initial = ρ_ions ⊗ ρ_radial ⊗ ρ_axial # Corrects Incompatible basis

IonSim should be able to check for this issue and properly correct for it if the ordering doesn't matter

https://github.com/JuliaRegistries/General

New packages and new versions of packages are added the General registry by pull requests against this GitHub repository. It is highly recommended that you use Registrator.jl to automate this process. Registrator can either be used as a GitHub App or through a web interface, as decribed in the Registrator README.

When Registrator is triggered a pull request is opened against this repository. Pull requests that meet certain guidelines is merged automatically, see Automatic merging of pull requests. Other pull requests need to be manually reviewed and merged by a human.

It is highly recommended to also use TagBot, which automatically tags a release in your repository after the new release of your package is merged into the registry.

Registered packages must have an Open Source Initiative approved license, clearly marked via a LICENSE.md, LICENSE, COPYING or similarly named file in the package repository. Packages that wrap proprietary libraries are acceptable if the licenses of those libraries permit open source distribution of the Julia wrapper code.

https://github.com/JuliaRegistries/Registrator.jl/#registrator

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

When setting thermalmode(n,mode), the Hilbert space of the mode is usually truncated when it no longer meaningfully contributes.

However, since the function is defined to have tr(thermalmode(mode,\bar{n})) = 1 for any Hilbert space dimension, rounding error that runs against machine precision begins to occur for large N Hilbert space. There should be a built-in mechanism that catches this and removes rounding error and sets higher mode number to zero.

The following plot represents the RMSE of the solution to timeevolution.schrodinger_dynamic between iterations for a density matrix with thermal mode n = 0.5 and increasing Hilbert space dimension.

for some reason, it's much slower. For now, we make non-adaptive timestepping the default.

this needs to happen after #25

Especially clarify the architecture -- are "laser", "ion", and "ionpattern" the right objects?

especially look at Hamiltonians.jl

for example, do we want underscores? What casing?

Noise examples...

would be nice to add a jupyter notebook.

Split species examples with barium..

It should be possible to construct a trap without specifying motional modes, for example if one only cares about the behavior of an ion's qubit levels.

Example code:
chain = linearchain(ions=[c], com_frequencies=(x=2e6, y=2e6, z=1e6), selected_modes=(x=[], y=[], z=[]))

Error message:
MethodError: Cannot 'convert' an object of type
NLevelBasis{Int64} to an object of type
CompositeBasis
Closest candidates are:
convert(::Type{T}, !Matched::T) where T at essentials.jl:171
CompositeBasis(::Basis...) at ~/.julia/packages/QuantumOpticsBase/8LqzY/src/bases.jl:80

Stacktrace:
[1] trap(; label::String, configuration::linearchain, B::Float64, Bhat::NamedTuple{(:x, :y, :z),Tuple{Int64,Int64,Int64}}, ∇B::Int64, δB::Int64, lasers::Array{laser,1}) at ~/.julia/dev/IonSim/src/traps.jl:123
[2] top-level scope at In[23]:2

• examples can be removed from docs
• or move examples onto docs

Document how to work on and test the package.
How do you set the URL to use local instead of Julia registry?

Issue #23 solved by removing warning altogether. Warning should be placed in a more convenient location.

Also for reference, suggestion from @kdbarajas #23:

Perhaps we should move to a parameter Laser.polarization with const Laser.p = Laser.polarization. Then consider using the format (k = \hat x, \epsilon = \hat z) where the backend takes care of the unit vectors.

This should resolve the QOL issue when running a loop where I build up a Trap with different frequency values on the Laser and receive a long warning list of non-orthogonal vectors upon completion.

In the move to split-species, I removed the PhysicalConstant nature of constants which are properties of a species (eg ion mass, level energies, etc), since I was having trouble getting PhysicalConstants to work in this context (#8). We could fix this by changing the struct so that it works in this context; is it worth it? In general, I don't really see value the PhysicalConstant struct adds if it doesn't do things like understand SI prefixes or multiply two constants give give a new one with new units, but even if it could, would this be very useful?

The main problem I want to point out is that the usage of it is currently inconsistent due to the above-mentioned issue #8 (used for constants like alpha and hbar, but now not for things like the mass of Ca40).

It will be hard to define a reference.
Compare against quantumoptics.jl

this should follow quantumoptics...

What does a "finished" docs look like?
@kdbarajas @jbroz11

Everybody divvy up the files -- look through the functions themselves and see if they do what we expect ('as if' it's a new PR)

neil -- (DONE) examples and (DONE) webpage update with split species code
joe (tentative) --- outline of what the paper is about
kunal -- (DONE) fix links on website, (WONTDO) embed examples in docs, (DONE) remove other examples from docs
kristian -- unit testing noise code, update with julia styling

Docs

• instruction manual

Consider: tutorial

• atoms/ions (how to specify, what's available, etc)
• vibrational modes (this is a chain, etc etc)
• lasers
• traps where we put them all together
• that's how we construct the system
• set up a calcium 40
• do MS calculation (shared vibrational mode)

Examples

• more pedagogical, code to re-use
• joe likes the jupyter book.

Getting started

• it's a good starting point already
• The Hamiltonian -- constructing it is the whole point
• Defining all the different objects -- some map of system parameters...

Goal for getting started: You can glance at it and it does something non-trivial!

Rabi flopping -- show that it matches quantum optics(?) (this could come first, then we go to MS)

Discussion: do we start with something "solvable" or something "nontrivial"?
Two different goals;

• Figure out how to use it as quickly as possible...
• Convince people that it's useful... (Joe prefers this)

another use case -- things that show off ionsim)

• section: what does a trapped ion experimentalist do?
• doppler cooling -->
• optical pumping
• ... (standard procedure for preparing, then basic operations)
• five example notebooks could explain all of this
  Learn: A pedagogical introduction to the core concepts in Trapped ions (state preparation, single-ion operations, entanglement-operations).

• #25 (Neil) (first)
• #35 (after multi-ion species)
• #26 (Joe, Kristian, Kunal?) (any time)
• #56
• #20 (?)
• #46
• #41 (flaky tests)
• #50
• #15

optional:

• #32
• #33
• #31 (after multi-ion species)
• #49
• #34

qojulia/QuantumOptics.jl-website#6

Wanted IonSim to have a simple Rabi flopping.

We already have Hamiltonian with a cutoff with RWA

It was easier if RWA=none, then it uses the other code that's time independent.

Might want to have a generic RWA builder.

they use the term solve and so on

On ionsim.org

Ex:
println(Laser())
>> Laser(IonSim.var"#Et#24"{Int64}(0), 4.6290987907722285e6, (x = 1, y = 0, z = 0), (x = 0, y = 0, z = 1), IonSim.var"#ϕt#25"{Int64}(0), 7.29147e-7, [(1, 1.0), (2, 1.0)])

Then find the Electric Field needed to achieve Rabi Frequency:
Efield_from_rabi_frequency!(Ω, T, 1, 1, ("S-1/2", "D-1/2"))

println(Laser())
>> Laser(IonSim.var"#83#84"{Float64}(34784.12980493003), 4.6290987907722285e6, (x = 1, y = 0, z = 0), (x = 0, y = 0, z = 1), IonSim.var"#ϕt#25"{Int64}(0), 7.29147e-7, [(1, 1.0), (2, 1.0)])

Notice that the variable #Et has changed. This did not appear to affect my code, but it is a curious artifact and it would be good to figure out if this is a meaningful change.

cc @neil-glikin @neilglikin

note: quantum optics doesn't solve at discrete time steps ... it solves it using non-discrete time steps, then interpolates the values using a DiffEq solver. So if we input a "noise vector of values" we'd have to interpolate to those values.

test: input sine function, and see if interpolation is good (vs stopping at each timestep).

There is an issue with one of the tests @jbroz11
constants -- other constants | 7 7 0.1s

operators -- VibrationalMode operators: Test Failed at /home/runner/work/IonSim.jl/IonSim.jl/test/test_operators.jl:34

Expression: ≈((displace(modes[1], α, method = "analytic")).data[i, j], (qo.displace(fb2, α)).data[i, j], rtol = 0.001)

Evaluated: 1.028639165911405e-15 - 1.0043267489904697e-15im ≈ 1.0933935056671732e-15 - 9.23343098384506e-16im (rtol=0.001)

It might be nice to add a code linter, and enforce a consistent style.

The general hope here is to make sure that use of IonSim is easy and intuitive for a user, basically matching up with intuitive expectation as best as possible. This is a list of some of my thoughts of items to consider for this. Many of them are questions about how we should handle stuff.

Julian/coding style

• Is it bad form to have different methods defined in different files? (e.g. transitionfrequency, some in ions.jl and some in traps.jl)
• Consistency of argument variable names (I vs ion)
• Ordering of arguments (ion first/last, trap first/last?)
• Use of "set" in functions that end in !
• Function naming: eg stark_shift vs starkshift
• Using functions to modify structs vs directly accessing them
• Outputs for print/show
• When/how errors are thrown/what type of errors vs warnings in various situations
  • Start error messages with capital or lowercase letters?
• Defining a module: within the file or around the include statements for the file?
• Import or export statements first?

Specific to IonSim

• Is Efield_from_pi_time a good name
• Default value of "timescale" should be 1, not 1e-6
• How to make sure that making new ion species is "easy" based off of some template
• Names of things
  • In particular "trap"
• Enforcing m to be rational (where?)
• Should we do intensity instead of E field
• Some functions allow sublevels to be ID'd by an index (Int), but most don't. Should they? Which ones should?
• Functions that involve a transition accepting a tuple as argument vs two different arguments
• Use of ionposition vs position
• Setting of parameters when constructing stuff
  • Be able to set mode Fock state size when creating rather than having to reference and then set mode.N =
• Be able to set constant parameters in a nice way (e.g. L.E returns a number not a function)
• "stark shift" should be named something different so that it's not confusing
• Ability to construct from top down: set up an empty Chamber first, then fill it in

how to submit: https://joss.readthedocs.io/en/latest/submitting.html
submission requirements: https://joss.readthedocs.io/en/latest/submitting.html#submission-requirements
example paper and bib: https://joss.readthedocs.io/en/latest/submitting.html#example-paper-and-bibliography
paper preview (testing) service: https://whedon.theoj.org/
what the paper should contain: https://joss.readthedocs.io/en/latest/submitting.html#what-should-my-paper-contain

when ready to submit:
https://joss.theoj.org/papers/new

Ex Laser.k = $\hat x$ produces warning for non-orthogonality before Laser.\epsilon can be set.

Perhaps we should move to a parameter Laser.polarization with const Laser.p = Laser.polarization. Then consider using the format (k = \hat x, \epsilon = \hat z) where the backend takes care of the unit vectors.

This should resolve the QOL issue when running a loop where I build up a Trap with different frequency values on the Laser and receive a long warning list of non-orthogonal vectors upon completion.

• make ion species configurable
• implement common ion species

A pedagogical introduction to the core concepts in trapped ions (state preparation, single-ion operations, entanglement-operations).

We could have a section on "what does a trapped ion experimentalist do?"

• doppler cooling
• optical pumping
• ... (standard procedure for preparing, then basic operations)
• five example notebooks could explain all of this

This would go into a "Learn" section of examples.ionsim.org.

It would show that the Ion can be configured.

From Joe:

It would also be nice to have an example of something that involves continuously driving a short-lived state, like optical pumping or Doppler cooling. I think we'd have to use the QuantumOptics semiclassical solver in order to for this to be efficient, but I'm not sure -- never tried it before. Here's a related QuantumOptics example: https://docs.qojulia.org/examples/lasing-and-cooling/

so its more similar to quantum optics

This can be done at any time.

cc @jbroz11 @kdbarajas
This would be a convenience function

Some examples:

• 2D coulomb crystal
• Ring trap

from Neil:

The OU noise portion of "getting started" doesn't seem to work. I don't know why but I noticed it was already the case so it's not related to the new ion syntax, and everything in the notebook before and after it still works.