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
Just a quick issue to document attempts to try and speed up python (partly driven by the rad hydro models).
KSL has run regression tests, showing that a very significant amount of time is spent in radiation, (and a surprising amount in the subroutine den_config)
There is apparently not much fat in the routine - this is evidenced by the amount of time spent in den_config which literally just indexes things. Trying to time the routine reveals that a matter of microseconds is spent in each call - however many millions of calls can be made.
The main loop is to calculate the bound free opacity - which means for every photon, loops are made over all ions/cross sections, which can be hundreds.
Initial thinking by NSH (and agreed by KSL) was that we could limit the number of cross sections being calculated by simply not computing cross sections for any ion which has been set to the floor. MIN_DENSITY.
However, NSH has been poking around and realises that there is a very nice array already calculated - kbf_need which attempts to limit the number of cross sections to be used in calulate_ds by looking at the peak opacity in each cell for each cross section. If the opacity is less than some value then that cross section is not used in the calculate_ds routine.
This is why calculate ds is fast and resonate is slow despite them doing much the same as each other! One could argue that we should not be including cross sections in the radiation bit of the code that arent included in the calculate_ds - os the obvious idea is to use kbf_use in radiation too....
The text was updated successfully, but these errors were encountered:
Hmmmmm, initial test simply using kbf_need for the loop in radiation gives very different results for regression tests - much faster tho.
This is a little worrying - after all if the list of BF cross sections in kbf_need is insufficient to get the important heating rates correct, then surely the opacity in calc_ds is likely to be underestimated. Hmmmm.
I have done some work on this - and TBH, the only real game in town was to reduce the BF list used in the loop in radiation. My investigations using the regression test showed that if I reduced the list (by whatever method) to significantly speed up the code - I got very different regression results. And in this case, I still only got about 20% speedup - in the ionization cycles.
So, I propose closing this issue - its not possible to get a quick win here...
Just a quick issue to document attempts to try and speed up python (partly driven by the rad hydro models).
KSL has run regression tests, showing that a very significant amount of time is spent in radiation, (and a surprising amount in the subroutine den_config)
There is apparently not much fat in the routine - this is evidenced by the amount of time spent in den_config which literally just indexes things. Trying to time the routine reveals that a matter of microseconds is spent in each call - however many millions of calls can be made.
The main loop is to calculate the bound free opacity - which means for every photon, loops are made over all ions/cross sections, which can be hundreds.
Initial thinking by NSH (and agreed by KSL) was that we could limit the number of cross sections being calculated by simply not computing cross sections for any ion which has been set to the floor. MIN_DENSITY.
However, NSH has been poking around and realises that there is a very nice array already calculated - kbf_need which attempts to limit the number of cross sections to be used in calulate_ds by looking at the peak opacity in each cell for each cross section. If the opacity is less than some value then that cross section is not used in the calculate_ds routine.
This is why calculate ds is fast and resonate is slow despite them doing much the same as each other! One could argue that we should not be including cross sections in the radiation bit of the code that arent included in the calculate_ds - os the obvious idea is to use kbf_use in radiation too....
The text was updated successfully, but these errors were encountered: