by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Aug 10 00:20
    gharib85 commented #270
  • Aug 07 07:35

    david-pl on test-1.5

    Fix tests on Julia v1.5 (compare)

  • Aug 04 13:43

    david-pl on tests-1.5

    Fix equality test on 1.5 (compare)

  • Jul 07 14:32
    PhilipVinc commented #273
  • Jul 01 13:44
    david-pl commented #273
  • Jun 29 13:41

    david-pl on master

    Remove equations for proper ren… (compare)

  • Jun 29 13:14

    david-pl on master

    Fix rendering of matrix when bu… (compare)

  • Jun 26 09:22
    PhilipVinc edited #273
  • Jun 26 09:21
    PhilipVinc opened #273
  • Jun 19 07:29
    PhilipVinc opened #272
  • Jun 15 13:00
    david-pl closed #24
  • Jun 15 13:00

    david-pl on master

    Heat-pumped three-level maser (… (compare)

  • Jun 15 12:20
    wolfgang-n synchronize #24
  • Jun 15 11:02

    github-actions[bot] on v0.8.1

    (compare)

  • Jun 15 10:14
    JuliaRegistrator commented on 6a90f3a
  • Jun 15 10:14
    david-pl commented on 6a90f3a
  • Jun 15 07:55

    david-pl on master

    Update Project.toml (compare)

  • Jun 15 07:53

    david-pl on master

    Relax some Constraints.. (#271) (compare)

  • Jun 15 07:53
    david-pl closed #271
  • Jun 11 17:08
    codecov[bot] commented #271
BridgingBot
@GitterIRCbot
[slack] <PhilipVinc> There are lazy versions of operators, though. it doesn't use lazyarrays?
David Plankensteiner
@david-pl
No, lazy implementations are custom implementations in QOBase. And yes, I have thought about switching to LazyArrays - and this would be the plan at some point.
Most of it would be straightforward, but the tricky bit is the FFTOperator which is essentially a LinearMap. Since in most application the goal would be to combine this with other operators, we need a nice (and fast) way to combine LazyArrays with LinearMaps. Didn't have the time to look into that in detail yet..
David Plankensteiner
@david-pl
@jrmbr In your function ham, both the call to dagger and the multiplication of operators allocates, which is quite inefficient. You could optimize this by e.g. pre-allocating the transitions, but I doubt you'll beat the second version. If this function is time-critical I would definitely go with the second version. You can actually optimize a bit further by changing the H.data directly instead of allocating another array, like so:
function ham2(N::Int,coefs,b)
    H = DenseOperator(b)
    for i=2:N
        for j=2:N
            H.data[i,j] += coefs[i-1,j-1]
        end
    end
    H
end
BridgingBot
@GitterIRCbot

[slack] <PhilipVinc> Is there an easy-to-use way to do gutzwiller-style decoupling with quantum trajectories/ME?

AKA: If I have two coupled bosonic modes, for example, I consider the wavefunction to be factorised (so the total size is local_cutoff_1 + local_cutoff_2 instead of the product) and the ME/Traj are evolved self consistely?

[slack] <PhilipVinc> a bit like semiclassical, but where the additional field is a quantum field
BridgingBot
@GitterIRCbot
[slack] <david.plankensteiner> @PhilipVinc There is currently no implementation on that. It might be possible to write this down with the recently added directsum. For example, if you have two fully uncoupled systems, you could write the Hamiltonian as directsum(H1,H2) and the state in a similar way. This will create an operator/state of the size you mention (sum of dimensions). I'm not sure how you would write down the coupling though. It would have to go in off-diagonal blocks (see setblock!). Not sure if it's really suitable for your case though.
David Plankensteiner
@david-pl
@lclcml There is no jupyter version of the tutorial, but here's the markdown file: https://github.com/qojulia/QuantumOptics.jl-documentation/blob/master/src/tutorial.md
BridgingBot
@GitterIRCbot
[slack] <PhilipVinc> ❤
[slack] <PhilipVinc> Yes, that's exactly what I need.
[slack] <PhilipVinc> The couplings are self consistent so a coupling like
H = a_1 * a_2 ^\dag
becomes
[slack] <PhilipVinc> H = a_1 * conj(<a_2>)
[slack] <PhilipVinc> and you update the expectation value at every iteration
[slack] <david.plankensteiner> Cool, glad that works for you!
[slack] <david.plankensteiner> Oh yes, that makes sense. That's actually really cool ^^
[slack] <PhilipVinc> though, it's a shame embed does not work with SumBasis
BridgingBot
@GitterIRCbot
[slack] <david.plankensteiner> Agreed. Could you open an issue on that?
BridgingBot
@GitterIRCbot
[slack] <david.plankensteiner> @PhilipVinc Thanks!
[slack] <PhilipVinc> I might implement it myself now or later today
[slack] <PhilipVinc> Is there a non-lazy implementation of operators on sumbasis?
[slack] <david.plankensteiner> The default should be non-lazy
[slack] <david.plankensteiner> the lazy version should only be returned if you use things like FFTOperator (or you specify it explicitly)
BridgingBot
@GitterIRCbot
[slack] <PhilipVinc> So, if I create the basis
h12 = FockBasis(N)⊕FockBasis(N)
the size of h12 is 2*(N+1)
and you store the operator as a matrix with that size...
[slack] <PhilipVinc> that's interesting.
I would have stored it as a last of many smaller matrices,
[slack] <PhilipVinc> But that's what you call a LazyOperator I guess
[slack] <david.plankensteiner> Yep I would call that the lazy version. Probably because I initially implemented it for examples like this one https://github.com/qojulia/QuantumOptics.jl-examples/blob/master/notebooks/spin-orbit-coupled-BEC1D.ipynb
[slack] <david.plankensteiner> There you assign off-diagonal blocks, so you have to store the full matrix anyway
BridgingBot
@GitterIRCbot
[slack] <PhilipVinc> BTW, unrelated but might interest you, I don't know if you are in the channel #quantum-computing , but there where talks of building a common foundation for hilbert spaces, lattices and hamiltonians.
[slack] <PhilipVinc> Also building upon QO.jl
[slack] <PhilipVinc> Some proposed discussing this during julia-con.
BridgingBot
@GitterIRCbot
[slack] <david.plankensteiner> Cool thanks for pointing me there!
SergeyHazanov
@SergeyHazanov
This message was deleted

Hi, I'm new to Julia and I'm trying to run QuantumOptics.jl in Atom (juno). I'm getting this strange error whenever I try to call FockBasis:

using QuantumOptics
bc = FockBasis(40) 
ba = SpinBasis(1//2)

The error I receive for the 2nd line is: "TypeError: in Array, in element type, expected Type, got Symbol".

lclcml
@lclcml
image.png
Hi @SergeyHazanov . You probably need to make sure you're running the latest greatest version of Julia or at least 1.3.1 or hiher. I just ran the same code above without issue:
SergeyHazanov
@SergeyHazanov
@lclcml , sorry, I forgot to mention, this is indeed an issue in Atom and not in Julia REPL (where it works for me as well)
lclcml
@lclcml
image.png
@SergeyHazanov - no issues in Atom either:
SergeyHazanov
@SergeyHazanov
@lclcml , great thanks! then the problem must be with my configurations, I'll try to reinstall
BridgingBot
@GitterIRCbot
[slack] <gszep> Hi there! Does anyone know if QuantumOptics.jl is compatible with Zygote.jl ?
[slack] <gszep> or can point me to current developments in parameter inference of qbit systems
BridgingBot
@GitterIRCbot
[slack] <david.plankensteiner> Hi! I'm not really familiar with Zygote.jl so I'm not sure. I doubt it will work with QuantumOptics.jl though. Maybe the people behind Yao.jl can be of more help, so you could try in #quantum-computing
BridgingBot
@GitterIRCbot
[slack] <PhilipVinc> Though it wouldn't be excruciatingly hard to make the two work together.
One of the main issues is QO.jl having too restrictive signatures/type parameter contraints a bit everywhere, and it's re-implementation of matmul.
[slack] <PhilipVinc> I have some code lying around that gets halfway there
[slack] <PhilipVinc> never got the time to make a pr
Christopher Rackauckas
@ChrisRackauckas
Zygote doesn't need to change types
BridgingBot
@GitterIRCbot
[slack] <Devon> is the documentation for embed correct? https://docs.qojulia.org/api/#QuantumOpticsBase.embed
[slack] <Devon> looks like the same method signature shows up twice and has two different descriptions
BridgingBot
@GitterIRCbot
[slack] <david.plankensteiner> No you're right, that's a mistake in the docstring. The actual methods are for operators::Vector and operator::AbstractOperator