You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is my proposal about the merger of QobjEvo and cQobjEvo which was discussed in a meeting about Integrator class last month. Instead of just dropping a PR out of nowhere like usual I am starting a discussion here first using the proposal template Nathan introduced yesterday.
Abstract
Merging of QobjEvo, cQobjEvo and QobjEvoFunc into one cython class.
Little new feature, mostly cleaner code.
Motivation and Scope
To manage time-dependent systems, we have QobjEvo a python interface of the system and cQobjEvo a cython interface. There is also the QobjEvoFunc class (from v5) object which allow time-dependent system defined as a function f(t, args) -> Qobj to be managed like QobjEvo. These object allows the solver to focus on the physic of the problem.
But 3 classes are not needed. QobjEvo handled compilation of string coefficient, this being a slow process resulted into a separation of the python and cython interfaces. Now that the compilation of strings is handled by coefficient.py, there is no need the separation. QobjEvoFunc is about using function as QobjEvo, so they have, per design, the same use and interface. Merging them is would allow to have a single entry for all Qutip accepted time-dependent systems.
Usage and Impact
Remove any branching in solver for function system.
Remove the need for 2 variables for each of QobjEvo and cQobjEvo.
Some part of qip are accessing internal of QobjEvo directly (cte, tlist, ops) should be changed to use only the interface.
Backward compatibility
Little effect for the users, QobjEvo internal for the solver in v4.
Detailed description
Minimum features of the merged class:
Can be constructed from any valid time-dependent system specification accepted in Qutip: Qobj, nested list of Qobj and Coefficient and functions with the signature f(t: float, args: dict) -> Qobj.
Support operation needed to make it into the desired operator used by the solver (-i*H, liouvillian, etc.) with minimum code that look into the QobjEvo. (__mul__, __matmul__, __add__, __sub__, dag, and super transformation: spre, spost).
Fast cython operation for operation used in solver: matmul with a state, expect (used by mcsolve and stochastic) and getting the Qobj at a time (brmesolve).
a shift method qevo_shifted(t) == qevo(t + dt), (used in correlation).
To future proof:
Some simplification/cleaning routine (to merge pulse entered as [[Qobj1, pulse1], [Qobj1, pulse2]])
Access to specialized matmul with a state from function QobjEvo (for brmesolve).
Other changes:
expect, mul, and mul_vec presently accept, np.array, Qobj and Data. Will only accept Qobj (python method), with mul_data for Data (cpdef).
Implementation
The main structure of keeping a list of pair of Qobj and coefficient will be kept., but upgraded to a private class.
This class called with (t) will return a pair of [Data, coeff(t)]. This allows for list part to return a constant Data but varying coefficient value and function system to return [func(t), 1]. Thus merging QobjEvoFunc at that level.
Operations on QobjEvoFunc must be done to by remembering the operations.
All operation that we support can be made by composing linear_map of the parts and __matmul__ between the part.
So all transformation function stacked in QobjEvoFunc will be reduced to those 2 operations removing the need for the _Block_transform.
Lastly, transformation such as the liouvillian -i(spre(H) - spost(H) needed to be applied differently for QobjEvo and QobjEvoFunc: while it could be computed directly for QobjEvo it would result in 2 calls of the function for QobjEvoFunc thus had to be apply as 1 mapping function. To clean that up, the new QobjEvo will keep a set of all system function and call the function only once even if used in multiple parts.
The resulting call function is:
cpdef Data _call(QobjEvo self, double t):
cdef dict funcQevos = {func: func(t, self.args)
for func in self.funcQEvo}
cdef Data out
cdef _BaseElement part = self.ops[0]
part.call(t, funcQevos)
out = _data.mul(part.data, part.coeff)
for op in self.ops[1:]:
part = <_BaseElement> op
part.call(t, funcQevos)
out = _data.add(out, part.data, part.coeff)
return out
I would prefer part.call to return the pair part.data, part.coeff, but this needs the creation of a python object being seen in timing.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
This is my proposal about the merger of
QobjEvo
andcQobjEvo
which was discussed in a meeting about Integrator class last month. Instead of just dropping a PR out of nowhere like usual I am starting a discussion here first using the proposal template Nathan introduced yesterday.Abstract
Merging of
QobjEvo
,cQobjEvo
andQobjEvoFunc
into one cython class.Little new feature, mostly cleaner code.
Motivation and Scope
To manage time-dependent systems, we have
QobjEvo
a python interface of the system andcQobjEvo
a cython interface. There is also theQobjEvoFunc
class (from v5) object which allow time-dependent system defined as a functionf(t, args) -> Qobj
to be managed likeQobjEvo
. These object allows the solver to focus on the physic of the problem.But 3 classes are not needed.
QobjEvo
handled compilation of string coefficient, this being a slow process resulted into a separation of the python and cython interfaces. Now that the compilation of strings is handled by coefficient.py, there is no need the separation.QobjEvoFunc
is about using function asQobjEvo
, so they have, per design, the same use and interface. Merging them is would allow to have a single entry for all Qutip accepted time-dependent systems.Usage and Impact
Remove any branching in solver for function system.
Remove the need for 2 variables for each of
QobjEvo
andcQobjEvo
.Some part of qip are accessing internal of QobjEvo directly (
cte
,tlist
,ops
) should be changed to use only the interface.Backward compatibility
Little effect for the users, QobjEvo internal for the solver in v4.
Detailed description
Minimum features of the merged class:
Qobj
, nested list ofQobj
andCoefficient
and functions with the signaturef(t: float, args: dict) -> Qobj
.QobjEvo
. (__mul__
,__matmul__
,__add__
,__sub__
,dag
, and super transformation:spre
,spost
).matmul
with a state,expect
(used bymcsolve
andstochastic
) and getting theQobj
at a time (brmesolve
).shift
methodqevo_shifted(t) == qevo(t + dt)
, (used in correlation).To future proof:
matmul with a state
from functionQobjEvo
(forbrmesolve
).Other changes:
expect
,mul
, andmul_vec
presently accept,np.array
,Qobj
andData
. Will only acceptQobj
(python method), withmul_data
forData
(cpdef).Implementation
The main structure of keeping a list of pair of Qobj and coefficient will be kept., but upgraded to a private class.
This class called with (t) will return a pair of
[Data, coeff(t)]
. This allows for list part to return a constant Data but varying coefficient value and function system to return[func(t), 1]
. Thus mergingQobjEvoFunc
at that level.Operations on
QobjEvoFunc
must be done to by remembering the operations.All operation that we support can be made by composing
linear_map
of the parts and__matmul__
between the part.So all transformation function stacked in
QobjEvoFunc
will be reduced to those 2 operations removing the need for the_Block_transform
.Lastly, transformation such as the liouvillian
-i(spre(H) - spost(H)
needed to be applied differently forQobjEvo
andQobjEvoFunc
: while it could be computed directly forQobjEvo
it would result in 2 calls of the function forQobjEvoFunc
thus had to be apply as 1 mapping function. To clean that up, the newQobjEvo
will keep a set of all system function and call the function only once even if used in multiple parts.The resulting call function is:
part.call
to return the pairpart.data, part.coeff
, but this needs the creation of a python object being seen in timing.Beta Was this translation helpful? Give feedback.
All reactions