Reviewer 1: Comment 2: Judgmental language

[katyhuff]

The paper uses sometimes judgemental language without detailing the motivations/reasons, e.g. in abstract and 1st § Introduction "To date, however, current tools are often rigid rather than flexible, fleet-based rather than discrete, or privately distributed rather than open source". Specifically the "fleet-based rather than discrete" would welcome some additional explanation what is truly meant by the authors. There are codes that do not treat reactors or fuel cycle facilities as discrete events though most well-developed codes do.

• [ ] Reduce judgemental-ness of the language
• Probably the best way to do this is to flip the sentences towards positivity. Aim for "Cyclus has attractive new features" rather than "There is a gap which Cyclus fills."
• A second thing to do that will fix this is to both explain and cite each of these comments better. Consider citing "Next Generation Functions and Requirements" document? It's still in "draft" form as far as I can tell, unfortunately.
• [ ] Clairfy fleet-based rather than discrete
• (robert c) VISION models all reactors of a single type (e.g. sodium cooled fast reactors) as a single, aggregate unit with the average behavior of some number of reactors. For example, modeling 2 SFRs in VISION would result in one entity that discharges “(length of cycle in time steps) * (single reactor batch size) * (number of reactors) / (# time steps per cycle)” every time step. If there is a fuel shortage, output power from the fleet drops proportional to the missing fuel quantity. In Cyclus using individual facilities, power output would drop discretely according to the number of reactors that didn’t have full cores - which could vary for the same quantity shortage of fuel depending on the distribution of the shortage across facilities. It is even possible to model fleet based facilities in Cyclus.
• (robert c) COSI has some support for modeling reactors individually, but according to OECD benchmark DOC(2012)16 it models many reactors operating in sync - that is their cycles are synced resulting in all discharging and refuelling at the same time among other things. Cyclus easily enables operating from this extreme to the fleet-based, aggregate extreme, and everything in between.
• (robert c) While many of these codes do some tracking of material in chunks, they do not necessarily track and preserve chunk identity as the materials move around the fuel cycle. When coupled with Cyclus’ individual facility modeling, this becomes rather distinct from what other fuel cycle modeling tools do. So while FAMILY21 and COSI might know whether a batch being discharged from a reactor came from MOX fabrication vs fresh UOX fabrication, they may not necessarily know/track which of the fresh batches received over the preceding several time steps was the batch being discharged. They certainly can’t tell which individual facility they received the batch from. Some of these simulators (e.g. VISION) also munge materials received before being discharged - i.e. reactors may receive material in chunks that are then mixed into a single holding buffer - losing identity - before being reconstituted and discharged as some chunk of material that may or may not even be the same size as the material chunks being received. And FWIW - GENIUS 1, GENIUS 2, and NFCSim developers are helping develop Cyclus.

[gidden]

While in general I think we should try to be positive of us rather than critical of others, this really is an opportunity for us to call out the community where appropriate. The community has been lax on describing the detail of simulators in peer-reviewed publication. Our criticisms are fair as long as they are cited and can not be refuted by a more recent citation. We just need to be confident both of those criteria are covered.