It turns out that solve_ivp itself is multithreaded for implicit solvers and the extra threads created by using prange instead of range for computing the rhs of the equations results in slightly slower rather than faster runs.
Probably because too many threads are fighting for resources.
So the rhs is back to being computed on a single thread.
The single_core_use_of_solve_ivp_without_py-pde_wrapper branch also has some enhancements for computing the gradients; a profiling run showed that a lot of time was spent on set_ghost_cells. This has now been included by using .apply_operator, which performs a number of steps for computing backward and forward derivatives through a single command, hopefully faster.
The rhs can be computed using LMAHeureuxPorosityDiff.fun_numba, that obviously uses Numba, but also through LMAHeureuxPorosityDiff.fun, that uses ScalarField from py-pde. This is a lot slower, but provides a nice way of checking that you get the same results.
It turns out that solve_ivp itself is multithreaded for implicit solvers and the extra threads created by using prange instead of range for computing the rhs of the equations results in slightly slower rather than faster runs. Probably because too many threads are fighting for resources. So the rhs is back to being computed on a single thread.
The
single_core_use_of_solve_ivp_without_py-pde_wrapperbranch also has some enhancements for computing the gradients; a profiling run showed that a lot of time was spent onset_ghost_cells. This has now been included by using.apply_operator, which performs a number of steps for computing backward and forward derivatives through a single command, hopefully faster.The rhs can be computed using
LMAHeureuxPorosityDiff.fun_numba, that obviously uses Numba, but also throughLMAHeureuxPorosityDiff.fun, that usesScalarFieldfrompy-pde. This is a lot slower, but provides a nice way of checking that you get the same results.