Use non-interactive backend in nwl utils to avoid matplotlib cubit conflict #148
Conversation
|
We should perhaps consider including OpenMC v0.15.0 in the environment YAML file |
There was a problem hiding this comment.
This looks good to me. I'll let @Edgar-21 and @connoramoreno make the final call on whether to add the OpenMC version to the environment before merge.
| @@ -5,8 +5,10 @@ | |||
| import pystell.read_vmec as read_vmec | |||
| import matplotlib.pyplot as plt | |||
| import concurrent.futures | |||
| from multiprocessing import cpu_count | |||
There was a problem hiding this comment.
Why are we removing multiprocessing? Wouldn't that remove parallelization from the NWL routine?
There was a problem hiding this comment.
concurrent.futures is what does the multiprocesssing, I originally attempted to make some guess about how many cpus to use based on cpu_count but ended up removing that bit, but this import remained
There was a problem hiding this comment.
Oh I see! We're good then. Let's just figure out whether we want to include OpenMC as a dependency now...
|
I'm in favor of at least including some mention that OpenMC v0.15.0 is needed to use the NWL utility. I'm not opposed to including it as a hard dependency to prevent user error on that front, although I recognize it complicates the environment and may become a problem in the future, like it was in the past. |
|
Looks good, thanks @Edgar-21 |
With the newest version of openmc (0.15.0) the previous conflict with Cubit seems to have been resolved. The remaining conflict with matplotlib can be resolved as in this PR, allowing the full NWL workflow to be performed in one script. In a future PR the nwl_utils example could be updated to be a single script.