Add random ray info to statepoint file #3499
Conversation
|
This is great -- thanks so much @spasmann! The only potential change that comes to mind might be to have the python statepoint object variables stored in a If it's a huge pain to change (or you disagree with the dictionary idea in general), let me know! If it's just a matter of free time, let me know and I can give the conversion into a dictionary a go. |
|
I think that's a good idea @jtramm, see if this looks better. |
| static double avg_miss_rate; // Average ray miss rate per | ||
| // iteration for reporting | ||
| static unique_ptr<Source> ray_source_; // Starting source for ray sampling | ||
| static RandomRaySourceShape source_shape_; // Flag for linear source | ||
| static bool mesh_subdivision_enabled_; // Flag for mesh subdivision | ||
| static RandomRaySampleMethod sample_method_; // Flag for sampling method | ||
| static int64_t n_source_regions; // Total number of source regions | ||
| static int64_t | ||
| n_external_source_regions; // Total number of source regions with | ||
| // non-zero external source terms | ||
| static uint64_t total_geometric_intersections; // Tracks the total number of | ||
| // geometric intersections by | ||
| // all rays for reporting | ||
| static int negroups_; // Number of energy groups |
There was a problem hiding this comment.
- The class variables should have a
_at the end to follow the C++ class variable naming convention.
There was a problem hiding this comment.
There's also a "total_geometric_intersections" variable already in the RandomRaySimulation class. Perhaps we should just use that one instead (and make it static), rather than making a duplicate?
| { | ||
| negroups_ = data::mg.num_energy_groups_; |
There was a problem hiding this comment.
As negroups_ is now a shared global variable, all threads will be contending to write and rewrite to this variable in an uncontrolled manner in parallel. Perhaps this one can be left as a local variable? Then, we can just use the data::mg.num_energy_groups_ variable directly when it is needed for writing out to the statepoint, if that's possible. Longer term, it would be nice if all the random ray code just used one negroups variable somewhere, rather than each class having its own copy, but that is beyond the scope of this PR for sure.
There was a problem hiding this comment.
In general, I'm hoping to move away from using the statepoint/summary.h5 files to store information that is already found in the input XML file. That we write out input options to these files is a historical artifact from before we supported reading data out of XML files from the Python API. Ergo, if we are adding additional information in the statepoint file, I think it should be limited to actual results (average miss rate being a good example) rather than just things that were in the Settings object.
|
@paulromano - that is definitely a valid point. In general it is not good to store the same data twice if it can be avoided. There is however the case where you are doing a parameter sweep or collecting data for a number of different setting options. We will naturally be saving the statepoints somewhere after each run so we can analyze them later (e.g., load tallies and see how they changed), but may neglect to save a copy of the input XML to go along with each unique statepoint. In that case, you wouldn't know which statepoint belonged to which input setting choice. The fix of course is to save both the input XML and the output statepoint for each case you're running, but it is sort of nice to have the statepoint be fully self descriptive. Removing input settings from the statepoint seems like it would unavoidably lead to some number of statepoints having to be recomputed as users forgot to also save the XML that corresponded to it. |
|
Another potential issue I suppose is that if users are able to load some settings from the statepoint, they will likely assume that all the settings are in there as well, so may not bother to save the |
Description
This PR adds some of the basic random ray simulation parameters and summary information to the statepoint file. I tried to copy similar additions but please let me know if things could be organized differently/better!
Checklist