You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In probing some unexpected behavior with using the recipe change functionality in the cycamore reactor, I have found the following:
This line needs to be updated to if (t < change_t) { so that newly deployed reactors "see" the recipe change.
This functionality only works successfully when a singular source with no specific recipe is used to supply the commodity that undergoes a recipe change. If two recipe-specific sources are used to supply the same commodity, the second facility to bid will always win no matter which recipe it has.
Perhaps the above bullet point is OK, but this limitation needs to be noted in the documentation if so.
This also causes an interesting problem. If the reactor sends off spent fuel in a timestep after the recipe change but before the refuel, the NEW spent fuel recipe is used even though it does not follow from the new input fuel recipe
PR #533 addresses the first bullet point for the preference change functionality in the reactor, but since the recipe change functionality needs more work the update is not included in that PR.
The text was updated successfully, but these errors were encountered:
In probing some unexpected behavior with using the recipe change functionality in the cycamore reactor, I have found the following:
if (t < change_t) {
so that newly deployed reactors "see" the recipe change.PR #533 addresses the first bullet point for the preference change functionality in the reactor, but since the recipe change functionality needs more work the update is not included in that PR.
The text was updated successfully, but these errors were encountered: