I’ve been thinking about how openmc handles the restarting, and I think it limits more than it provides. I’ll try and explain my reasoning here, and hopefully this can be a place for discussion and a springboard for future revisions.
Currently, the most recent reaction rates are stored in the depletion result file. I have voiced other suggestions on writing these to a separate file as GH #1348, and this kind of ties in here. These reaction rates are great if you are picking up exactly where the simulation terminated with no modifications, i.e. running on a scheduled cluster and the allowed run time was exceeded before the job actually finished. The reaction rates mean we can skip this initial transport solution and keep going.
There has been some interest in using the restart capabilities for modeling operational changes GH #1519, and something like this would be very useful for fuel shuffling simulations. In these cases, the reaction rates are not valid because the problem has changed. I proposed a small workaround where people use a very small initial step size, but this is what I would like to work towards removing.
This might be as simple as providing the restart file, but having the Operator load the restarted compositions instead of those provided in the material files. Then, we can set prev_res=None to run the first transport simulation with these new compositions. I think there might be more discussion for properly handling fuel shuffling-like problems, where the location of burnable materials has changed between steps.
I think moving away from the reaction-rate based restarting, or at least not using them at the user’s request, can open the door for more types of simulations down the road. Thoughts?
Drew
P.S. This feels like an immense improvement over the google group