List view
This milestone is related to revision and resubmission based on the reviews from two reviewers. Those comments are listed below. This milestone will be closed when all comments have been addressed sufficiently for resubmission. ## Reviewer 1: - [ ] The paper gives an overall good overview of the motivations for and the development of CYCLUS. - [ ] 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. - [ ] 1st section: Introduction: "However, current fuel cycle ...": important to mention that there are multiple user-categories for such codes with differing expectations. Some codes are more and more proprietary for reasons of validation in industrial context or customised applications. Others may have an educational focus or still others being of approximative nature, i.e. specifically those not using discrete description of mass-flows/inventories/core-management, ... - [ ] IA: would be good to mention that such simulators can be used both for questions addressing operational facets of nuclear energy systems, e.g. interim UNF storage optimisation,as well as 'strategic' questions allowing to address R&D-options assessment. - [ ] IB Motivation, 1st §: please provide scientific grounds for the claims in the first paragraph. Virtually all simulators developed by authoritative labs/companies do have the possibility to compare various nuclear energy system options with varying innovative technologies as part of these systems. The main question is how simulators can address the flurry of questions being addressed by users. The sentence "lower the barrier ... without those innovative concepts" is more 'marketing-talk than truly a scientific analysis as such. None of the simulators today, neither CYCLUS, can address the variety of questions to be addressed by such simulators and especially in industrial context, these simulators need increasingly detailed capabilities and validation to remain thrustworthy in their application. - [ ] IB.iii: The simulation codes with discrete materials tracking are: COSI, FAMILY21, GENIUS 1 and 2, DANESS, NFCSim and ORION. DESAE doesn't !! Not clear about VISION. DYMOND didn't neither. - [ ] Paper would be strengthened by detailing the UOX/MOX-example in more depth showing the results of front-end and back-end mass flows and inventories as well as isotopic evolution and how this impacts the core-management in the mono-recycling scenario. Figure 8 and 9 could be questionnable when the Pu-recycling is taking place in thermal neutron spectrum reactor, i.e. LWR. The repetitive Pu build-up pattern needs to be commented with regard to the recyclability of that Pu in LWR. What are the detailed assumptions for this case? ## Reviewer 2: - [ ] The manuscript has the following title: "Fundamental Concepts in the Cyclus Fuel Cycle Simulator Framework and Modeling Ecosystem". It is not clear to me what "and Modeling Ecosystem" refers to. - [ ] I suggest that the first pages referring to computer software should be simplified. - [ ] I suggest that the pages describing test cases should be extended to more realistic cases in which fuel cycle and reactor core constraints are taken into account. In the infinite-pass recycle, degraded Pu vector will limit recycling in practice. - [ ] page 1: "or privately distributed rather than open source.": With this sentence, the authors recognise that similar tools exist to which they do not have access. - [ ] page 1: "However, current fuel cycle simulators rely on closed platforms and inflexible architectures which exhibit three main failure modes. First, they discourage targeted contribution and collaboration among experts. Next, they hobble efforts to directly compare modeling methodologies. Finally, they over-specialize, rendering most tools applicable to only a subset of desired simulation fidelities, scales, and applications.", these sentences have nothing to do in a technical paper. There are numerous technical aspects in the fuel cycle which deserve attention and it would be nice to have them listed somewhere. - [ ] page 1&2: "To date, current tools are often rigid rather than flexible, fleet-based rather than discrete, or privately distributed rather than open source.": it is always easier to denigrate old tools than illustrate the merits of a new one. This is not really necessary for the understanding of the note. - [ ] page 3 (Background): "With few exceptions, these metrics are derived from mass balances calculated by a fuel cycle simulator. [4]." : It would be nice to illustrate what are the few exceptions. Please read "C. Poinssot, S. Bourg, N. Ouvrier, N. Combernoux, C. Rostaing, M. Vargas-Gonzalez et J. Bruno, Assessment of the environmental footprint of nuclear energy systems. Comparison between closed and open fuel cycles., Energy, n°1In Press, pp. 1-13, 2014. - [ ] page 4: "Using an agent-based framework, the simulator tracks the transformation and trade of resources between autonomous regional and institutional entities with customizable behavior and objectives. This capability is an innovation not pursued by any existing fuel cycle simulator. » : description of these sentences should be better explained in the following. - [ ] page 6: typing errors: ...facilitate... particular agent - [ ] page 9: "Cyclopts [26], a proof of principle design and implementation of a CYCLUS-enabled application on such a large computer system, uses UW-Madison's HTCondor HTC infrastructure to perform sensitivity studies.": please illustrate what kind of sensitivity studies, you are able to perform. - [ ] page 18: "SWUs" please give a complete list of acronyms: here Separate Work Units - [ ] page 20: What is a "BatchReactor" ? ; bad reference for: "Section ?? " - [ ] page 23: "However, such exercises are more likely to bring into relief the differences between the modeling paradigms than supply substantial QA and validation.": Right, the QA and validation should be done prior to that exercise. How? This should be better illustrated. - [ ] page 23: typing error: "…and it cannot…" - [ ] page 23: "Taken together and strictly adhered to, they present a fortress to protect against poorly designed or otherwise undesirable code., it would be nice to know what is sufficient for validating a software. - [ ] page 37 : Simulations relying on arbitrarily complex isotopic compositions are possible in CYCLUS, as are simulations not employing any physics at all. If I understand correctly that sentence, it means that there is no physics in the tool. This is right. - [ ] "The proof of the pudding is the eating", it would be wise for the authors to participate to benchmark studies being conducted at the OECD: "Nuclear science > Working Party on Scientific Issues of the Fuel Cycle (WPFC) > "The Effects of the Uncertainty of Input Parameters on Nuclear Fuel Cycle Scenario Studies ". The benchmark treats realistic Nuclear Fuel Cycle Scenario Studies and codes like COSI, VISION and FAMILY21 (cited in the article) can model systems (stocks, factories, storage facilities, reactors) with different characteristics but also factories at different scales ranging from very macroscopic modeling of a park to a very fine modeling, facility by facility, year by year. The objects modeled in the example (page 33) can be modeled by COSI, VISION and FAMILY21 (cited in the article). - [ ] The article lacks a chapter on the validation of the models used and a validation of the physics is missing, something the authors are recognizing.
Due by June 1, 2015•19/19 issues closedThis will be complete when all the random requirements of submission are complete and the paper has been submitted.
Due by March 12, 2015•4/4 issues closedEach author should read through the paper once (seems crazy? it's not! Do you really want to be an author on a paper with an entire section on how "superman bubblegum sticks to the roof of your mouth"?) Each reviewer might want to at least ask: - Does the introduction draw the reader in? - Are all sentences clear? - Does the conclusion summarize the topic? - Is the outline coherent? - Are there any missing sections or essential topics left unaddressed? - Do any statements require additional citation? - Would additional diagrams or plots clarify any discussion? - Does the paper address the focus areas of the target journal?
Due by November 16, 2014•21/21 issues closedEveryone should run through and edit the rough draft. Cut, move, and add sections. Fill in missing pieces where topics are missing and add parts where you have expertise. Do some spell checking, reduce over-verbose wording, clean up excessively passive voice.
Due by September 7, 2014This will be complete when we have a rough draft. It's okay for it to be very rough. Don't over edit. Just write down everything we need to include. It's okay if there are placeholders instead of figures/citations. Each section should have enough text to feel like we've gotten 'full coverage.'
Due by August 31, 2014•18/18 issues closed