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
Currently, if a Solver is instantiated with Lindblad data, calling Solver.solve with y0 being a SuperOp will only work if evaluation_mode is set to a vectorized option, and otherwise it will raise an error explaining this.
The internal behaviour of Solver.solve should be updated so that the simulation is still carried forward even if evaluation_mode is not vectorized by:
Converting the SuperOp to a 3d array representing a list of input matrices to the un-vectorized Lindblad equation.
Passing this as the initial state to the call to solve_lmde
Converting the output back to a SuperOp by inverting the first transformation.
Notes
The second bullet point above should work due to the LindbladModel.evaluate_rhs being "vectorized" in the array-programming sense: evaluating it on a 3d array is functionally equivalent to looping over the first index and applying the RHS function to each entry.
Part of this PR will involve more carefully testing/verifying the components that go into this. There don't seem to be any tests for this in test_lindblad_model.py, but the test test_multiple_density_matrix_evaluation in test.dynamics.models.test_operator_collections.TestDenseLindbladCollection tests this at the operator collection level. The LindbladModel array-vectorized rhs operation should therefore work assuming that the RotatingFrame operator frame transformation functions are also vectorized (which I think they are).
Additionally, once working, it would be good to test out some examples comparing vectorized evaluation_mode v.s. non-vectorized, to get a sense of the performance difference (though this isn't technically required for this).
The text was updated successfully, but these errors were encountered:
The array-vectorized solving for a 3d array representing a list of density matrices works if both Hamiltonian operators and Lindblad operators only contain a single entry, but fails with multiple entries, so where this is failing will need to be identified.
In the case that it is working, the vectorized version actually appears to be faster, though this is using numpy so the comparison should be done with JAX.
This makes me wonder if we should automatically vectorize in Solver.solve to do a SuperOp simulation?
What is the expected behavior?
Currently, if a
Solver
is instantiated with Lindblad data, callingSolver.solve
withy0
being aSuperOp
will only work ifevaluation_mode
is set to a vectorized option, and otherwise it will raise an error explaining this.The internal behaviour of
Solver.solve
should be updated so that the simulation is still carried forward even ifevaluation_mode
is not vectorized by:SuperOp
to a 3d array representing a list of input matrices to the un-vectorized Lindblad equation.solve_lmde
SuperOp
by inverting the first transformation.Notes
The second bullet point above should work due to the
LindbladModel.evaluate_rhs
being "vectorized" in the array-programming sense: evaluating it on a 3d array is functionally equivalent to looping over the first index and applying the RHS function to each entry.test_lindblad_model.py
, but the testtest_multiple_density_matrix_evaluation
intest.dynamics.models.test_operator_collections.TestDenseLindbladCollection
tests this at the operator collection level. TheLindbladModel
array-vectorized rhs operation should therefore work assuming that theRotatingFrame
operator frame transformation functions are also vectorized (which I think they are).Additionally, once working, it would be good to test out some examples comparing vectorized
evaluation_mode
v.s. non-vectorized, to get a sense of the performance difference (though this isn't technically required for this).The text was updated successfully, but these errors were encountered: