Closed cjosey closed 7 years ago
I've confirmed that this fixes the errors I observed with my depletion benchmarks.
Sorry for merging it early. I misinterpreted the "approved" for it having been tested.
Oh not a problem at all! Btw I realized that the SMR model in my mit-crpg/ecp-benchmarks repo still fails with the same error trace:
Traceback (most recent call last):
File "build-depleted.py", line 150, in <module>
opendeplete.integrate(op, opendeplete.ce_cm_c1)
File "/home/boydwill/miniconda3/lib/python3.5/site-packages/opendeplete-0.1-p\
y3.5.egg/opendeplete/integrator.py", line 91, in integrate
File "/home/boydwill/miniconda3/lib/python3.5/site-packages/opendeplete-0.1-p\
y3.5.egg/opendeplete/function.py", line 116, in eval
File "/home/boydwill/miniconda3/lib/python3.5/site-packages/opendeplete-0.1-p\
y3.5.egg/opendeplete/openmc_wrapper.py", line 290, in function_evaluation
File "/home/boydwill/miniconda3/lib/python3.5/site-packages/opendeplete-0.1-p\
y3.5.egg/opendeplete/openmc_wrapper.py", line 665, in unpack_tallies_and_normal\
ize
File "/home/boydwill/miniconda3/lib/python3.5/site-packages/opendeplete-0.1-p\
y3.5.egg/opendeplete/reaction_rates.py", line 98, in __setitem__
IndexError: index 58611 is out of bounds for axis 0 with size 58611
The single assembly and 2x2 assembly benchmarks all work now though.
I'll see what I can do, but I forsee two problems. One, I cannot run the SMR problem for the following reason.
Traceback (most recent call last):
File "build-depleted.py", line 49, in <module>
distribcell_filter = openmc.DistribcellFilter([cell.id])
AttributeError: 'list' object has no attribute 'id'
Two, I suspect I may not have enough RAM to run the problem.
Oops, I hadn't yet pushed the fix for that bug to ecp-benchmarks. You can pull it now from:
https://github.com/mit-crpg/ecp-benchmarks/pull/4/commits/db5501265aa034e33577c750a43b76bf0ba4895d
As for RAM, I've been running on INL's Falcon machine which has 132 GB per node. Do you have access? Or what about the supercomputers that you mentioned running on?
Oh, I have access to Falcon. I just rather not debug on a supercomputer unless it's MPI or something.
I have been able to track down where the majority of the RAM goes. total_number
and number_density
, being nested dictionaries are absolutely massive for a complicated problem. For 2x2 Assembly, I'm seeing 600MB each, whereas reaction_rates, which should store almost as many values, is a mere 22MB. However, I have yet to track down why generate_matrix_list
uses another GB when the f
variable in the integrator (where generate_matrix_list
outputs to) is a mere dozen MB.
Yeah, I always just reserve an interactive mode on Falcon for debugging. It's not much I different than debugging on my a machine, unless you like using a graphical debugger through an IDE (which would probably choke for these memory-intensive problems anyway).
This ensures that the results index map makes (more) sense.
This PR closes #23.