Observation speed up - #34
Merged
Merged
Conversation
… ~85 seconds per radDist
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Several things:
Program calculates etendue's for each chord for each radDist if they user requests radiance or brightness for their units. This takes ~1 second per chord and is a significant time sink when the user creates many radDists. Solution: Add the pre-calculated ETENDUE values to the bolometer configuration file.
Fixed a bug regarding the assignment and calling of the helical field lines. Now each instance calls the same function (Util.fieldline_key).
Updated DIII-D's bolometer configuration files to include pre-calculated ETENDUE's.
Added a phase_timer function within Util. Use that to measure the timing of things. Call example:
with phase_timer("calc_radiated_power"):
self.calc_radiated_power()
make_radDist now creates a master arglist which is then fed to the ProcessingPool. Previously, the program would loop over several parameters, creating a small number of items to run in parallel.
Removed the functionality to call multiple processors when observing in cherab. This lead to over-prescribing processors since make_radDists.py already calls many processors to work. NOTE: Each channel takes on the order of 0.3 seconds to run for 1000 pixelSamples. This is already pretty fast, but can be sped up if the pixelSamples number is reduced or we could map the radiation function to a grid.
Updated the example radDist configuration file since the number of processors when observing with cherab was removed.