Comment (by Ian Hinder):

When you say that Multipole is taking 1-2% of the execution time in your BBH simulation, I would say:

1. That’s not very much
2. It is possible that what the timer is measuring is the time spent on one process waiting for the other processes to catch up. If you want to know, you can set Carpet::schedule_barriers = yes and `Carpet::sync_barriers = yes` and then look at the timer output for the barriers.

In general, I would only invest time in optimising if you have profiled first. So if you have measured that the integration loops are taking a significant amount of time, then by all means parallelise them. They don’t scale with the grid resolution (unless you manually scale the angular resolution parameters), and I would expect interpolation to be by far the dominant cost here.

Having said that, since it’s just adding one pragma, maybe it’s not worth investigating too much

‌

--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2626/multipole-is-not-openmp-parallelized