Introduce QobjEvo and use SciMLOperators for time evolution
#266
Conversation
| struct ProgressBar{CT,T1<:Integer,T2<:Real,T3,T4<:Real,LT} | ||
| mutable struct ProgressBar{CT,T1<:Integer,T2<:Real,T3,T4<:Real,LT} |
There was a problem hiding this comment.
This change should be in another PR.
maybe you need to merge from main branch locally first.
There was a problem hiding this comment.
I have just done "merge from upstream:main", but now it seems a like a change
| if A isa QuantumObjectEvolution || B isa QuantumObjectEvolution | ||
| return QuantumObjectEvolution($(op)(A.data, B.data), A.type, A.dims) | ||
| end | ||
| return QuantumObject($(op)(A.data, B.data), A.type, A.dims) |
There was a problem hiding this comment.
I think we can extend the basic julia function promote_type (maybe put it in the file utilities.jl ?) for this.
something like
promote_type(A::QuantumObjectEvolution, B::QuantumObjectEvolution) = get_typename_wrapper(A)
promote_type(A::QuantumObjectEvolution, B::QuantumObject) = get_typename_wrapper(A)
promote_type(A::QuantumObject, B::QuantumObjectEvolution) = get_typename_wrapper(B)
promote_type(A::QuantumObject, B::QuantumObject) = get_typename_wrapper(A)and therefore, this kind of if-condition block can be simplified as
QType = promote_type(A, B)
QType($(op)(A.data, B.data), A.type, A.dims)This can also be implemented in the other functions.
| Compute the generalized dot product `dot(i, A*j)` between three [`QuantumObject`](@ref): ``\langle i | \hat{A} | j \rangle`` | ||
| Compute the generalized dot product `dot(i, A*j)` between three [`AbstractQuantumObject`](@ref): ``\langle i | \hat{A} | j \rangle`` |
There was a problem hiding this comment.
maybe change this as
Compute the generalized dot product `dot(i, A*j)` between [`AbstractQuantumObject`](@ref) `A` and two [`QuantumObject`](@ref) (`i` and `j`), namely ``\langle i | \hat{A} | j \rangle``
| @@ -6,71 +6,79 @@ export isket, isbra, isoper, isoperbra, isoperket, issuper | |||
| export isunitary | |||
There was a problem hiding this comment.
Should we also add a new function isconstant in the end of first line ?
I saw that QuTiP also got this function.
But this is not necessary at this moment, can be done in future PRs
| if A isa QuantumObjectEvolution || B isa QuantumObjectEvolution | ||
| return QuantumObjectEvolution(kron(A.data, B.data), A.type, vcat(A.dims, B.dims)) | ||
| end | ||
| return QuantumObject(kron(A.data, B.data), A.type, vcat(A.dims, B.dims)) |
There was a problem hiding this comment.
can also use promote_type mentioned above
| _FType(::QuantumObject{<:AbstractArray{T}}) where {T<:Number} = _FType(T) | ||
| _CType(::QuantumObject{<:AbstractArray{T}}) where {T<:Number} = _CType(T) |
There was a problem hiding this comment.
we can change these to
_FType(A::AbstractQuantumObject) = _FType(eltype(A))
_CType(A::AbstractQuantumObject) = _CType(eltype(A))
| @@ -23,6 +23,7 @@ end | |||
| function LindbladJumpAffect!(integrator) | |||
| internal_params = integrator.p | |||
| c_ops = internal_params.c_ops | |||
| c_ops_herm = internal_params.c_ops_herm | |||
There was a problem hiding this comment.
I thought this is done by another PR, maybe you need to merge from main branch locally first.
| alg=Tsit5() | ||
| e_ops = nothing, | ||
| params=NamedTuple(), | ||
| progress_bar=Val(true), |
There was a problem hiding this comment.
Not necessary but I think it would be better to add blanks on both sides of =
| ⎢⠀⠀⠀⠀⠀⠀⠂⡑⢄⠀⎥ | ||
| ⎣⠀⠀⠀⠀⠀⠀⠀⠀⠂⡑⎦ | ||
| """ | ||
| struct QuantumObjectEvolution{DT<:AbstractSciMLOperator,ObjType<:QuantumObjectType,N} <: |
There was a problem hiding this comment.
Do we need to restrict ObjType<:Union{OperatorQuantumObject,SuperOperatorQuantumObject} here ?
Description
With this PR I remove the obsolete operators like
OperatorSumandTimeDependentOperatorSum, by introducing theQobjEvooperator, like in python. Thisstructtakes advantage of the SciMLOperators.jl ecosystem, in order to handle in a lazy way complex operators like sum of them and time-dependent ones.The
ObjEvois andAbstractQuantumObject, with the same fields as theQuantumObject, so they share many of the methods.The introduction of using SciMLOperators.jl would push us towards the support of automatic differentiation of
sesolve,mesolveandmcsolve, allowing the possibility to make quantum optimal control very efficiently.I made this PR to improve the performance of complex
SciMLOperatorslike our sum of time-dependent operators. So, we have to wait for a new release of the package first.Todo list:
QobjEvooperatortlistfrom the parameters, and add it directly as argumentTimeEvolutionSoltype-stablet_lwith a more readabletlistOperatorSumandTimeDependentOperatorSumsesolvewith the support ofQobjEvomesolvewith the support ofQobjEvomcsolvewith the support ofQobjEvo