At the moment, the only parallelisation present in the evolution module is any implicit work done by numpy or scipy underneath. This is generally limited to 2 separate threads at the MKL or OpenMP level (depending on the backend used) in various operations.
When running on the cluster, it might be useful to have a simple way to disable this behaviour (although setting the environment MKL_NUM_THREADS or OMP_NUM_THREADS to 1 ought to be enough), especially when additional parallelisation is applied.
In addition, the calculation of a single derivative could be taught to use parallel processes, since each one is completely separable from the others. Obviously we would want some control over how many processes are used to do this.
It might be particularly useful for the detuning error scans in the Molmer--Sorensen gate numerics, since the integral I am performing is easily written in Gauss--Hermite quadrature, and requires very few points to get a very accurate estimation of the total infidelity (maybe as few as 5). Since a node on cx1 has around 32 CPUs, we can happily use 5 * 6 processes to do the calculation, allowing us to reduce the calculation time of one complete infidelity by almost 30 times (since all the heavy lifting can be parallelised).
At the moment, the only parallelisation present in the
evolutionmodule is any implicit work done bynumpyorscipyunderneath. This is generally limited to 2 separate threads at the MKL or OpenMP level (depending on the backend used) in various operations.When running on the cluster, it might be useful to have a simple way to disable this behaviour (although setting the environment
MKL_NUM_THREADSorOMP_NUM_THREADSto 1 ought to be enough), especially when additional parallelisation is applied.In addition, the calculation of a single derivative could be taught to use parallel processes, since each one is completely separable from the others. Obviously we would want some control over how many processes are used to do this.
It might be particularly useful for the detuning error scans in the Molmer--Sorensen gate numerics, since the integral I am performing is easily written in Gauss--Hermite quadrature, and requires very few points to get a very accurate estimation of the total infidelity (maybe as few as 5). Since a node on
cx1has around 32 CPUs, we can happily use5 * 6processes to do the calculation, allowing us to reduce the calculation time of one complete infidelity by almost 30 times (since all the heavy lifting can be parallelised).