openmc-dev
Weight windows max_split vs max_splits
Description
The weight window feature added to OpenMC is very useful. However, we found it was not as effective in OpenMC as MCNP when used on large scale models (such as a full fusion tokamak model). This has been tracked down to our understanding of the keywords that control the variance reduction games in OpenMC and feel that this could be improved from a user’s understanding.
There are currently two very similarly named variables, max_split and max_splits. Max_split is a member of the weight window object and limits the number of splits during a single check against the weight window. Max_splits is a member of the settings object and limits the number of times a history can be split (note: it has a default of 1000). From our experience changing the max_split variable does very little to change the results or increase/decrease the effectiveness of the weight window. However, increasing max_splits increases the effectiveness of the weight window as it allows the particles to be pushed out further into the model (we were finding that 1000 splits is not enough when you have many orders of magnitude decrease in your flux across your model).
It is confusing for users to have two very similar named variables and leads to significant confusion when weight windows are applied. I am not entirely sure why you need to limit the maximum number of splits that a history undergoes and the max_splits variable could be removed. There already appears to be a 'long history' avoidance section of the code which increases the weight window for that history if the particles weight is significantly above the weight window.
Alternatives
A couple of other options could be:
- Rename the variables to make it less confusing for the user (maybe max_splits -> max_history_splits).
- Set the default value of max_splits to be 1e7 or something very large so the user doesn't have to change this value. 3 or do both.
Hi @teade. Good points! Thanks for raising this. This is pretty confusing and the default value we settled on for the max number of history splits is rather low. I like option 3 -- both and will plan to implement that change soon.
