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
#92 is an attempt at this, but I'm not sure it's been fully tested and also would need to be updated to work with the parallel implementation.
However, the current way we calculate line opacities is by looping through frequencies and seeing if there are lines close that contribute to opacity in that bin.
We could do far fewer calculations by looping through lines and calculating the frequency bins they contribute opacity to. It would also be straightforward at that point to do an additional calculation when considering the line to decide how broad to consider it. This variable broadening range scaling is used by other codes and the cost of doing an additional per line calculation should still be fast compared to the way we do things now where we probably consider many more unnecessary lines at each frequency.
The text was updated successfully, but these errors were encountered:
#92 is an attempt at this, but I'm not sure it's been fully tested and also would need to be updated to work with the parallel implementation.
However, the current way we calculate line opacities is by looping through frequencies and seeing if there are lines close that contribute to opacity in that bin.
We could do far fewer calculations by looping through lines and calculating the frequency bins they contribute opacity to. It would also be straightforward at that point to do an additional calculation when considering the line to decide how broad to consider it. This variable broadening range scaling is used by other codes and the cost of doing an additional per line calculation should still be fast compared to the way we do things now where we probably consider many more unnecessary lines at each frequency.
The text was updated successfully, but these errors were encountered: