1. Fuel Cycle Simulators and Data Treatment
March 15-17, 2011
Systems Analysis Working Group Meeting

2. Fuel Cycle Research and Development Vision and Objectives for the Advanced Fuel Cycle Simulator (FCS) Project
Brent Dixon Idaho National Laboratory
Fuel Cycle Simulator Workshop
San Francisco, April 6, 2011

3. Current Fuel Cycle Simulators
There are currently multiple fuel cycle simulators in use domestically and globally
Government labs with simulators include the U.S., France, U.K, Japan, Russia, and others
Most are mature and many have been benchmarked against each other
Primary focus is on material flows, but some also support limited extensions based on sponsor interests
Many universities with nuclear engineering programs also have simulators
Maturity levels vary, generally less mature than lab tools
Industry has multiple tools for assessing fuel loads in reactors, but generally do not model the full fuel cycle
Exceptions include companies with operations in multiple parts of the fuel cycle, or developing advanced technologies

4. Fuel Cycle Simulator Workshop – San Francisco
FCS Vision
The vision for the FCS is a joint effort by DOE laboratories, universities, industry and potentially international partners to combine intellectual resources into a single, next generation software tool that can meet the needs of all users
Use the best features and lessons learned from current generation tools, their developers, and their users (and potential new user classes) to develop the functional requirements
Apply advanced software development and visualization methods and advanced hardware architectures to achieve a maintainable and extendable tool that satisfies those requirements
April 6-7, 2011
Fuel Cycle Simulator Workshop – San Francisco 4

5. Role of the Fuel Cycle Simulator
The Fuel Cycle Simulator (FCS) is the next generation FCR&D systems analysis tool. As such, it needs to:
“Support integrating analyses of fuel cycle systems”
Evaluate potential system architectures that can meet program objectives
Help identify critical elements of the system where additional development will provide the greatest impact
Use quality controlled fuel cycle data
“Inform fuel cycle R&D, programmatic decisions, strategy formulation, and policy development.”
Assess system architectures per program metrics and technical requirements
Provide sensitivity and uncertainty analysis to help identify high value R&D
Communicate system projected performance and related uncertainty to inform decision making
Other potential users will have additional needs
April 6-7, 2011
Fuel Cycle Simulator Workshop – San Francisco 5

6. Assessment Needs Vary with Design Maturity
The FCT Program has identified over 850 potential fuel cycles
For the least defined options there is insufficient data to perform any quantitative analysis
For lesser defined defined options, static systems can be modeled to gauge performance potential
For moderately defined options, dynamic analyses can assess transition strategies, general system behavior
For well defined systems, assessments can include reliability analysis, infrastructure sequencing, incentives leveraging, etc.
For deployed systems, analyses can assess current operational risks and mitigation options
April 6-7, 2011
Fuel Cycle Simulator Workshop – San Francisco 6

7. Fuel Cycle Analysis Factors
Physics –
Each isotope behaves differently inside a reactor based on the spectrum of operation, physical geometry, etc.
Each unstable isotope decays at a different rate
Thousand of isotopes may be analyzed
Problem timeframe and system inertia –
Timeframe for events of interest range from less than a second to thousands of years
Key infrastructure may last 60+ years, so change is slow
Large uncertainties
Assumptions on future growth rates, costs, etc. drive analyses
Availability and performance of new technologies not fully known
April 6-7, 2011
Fuel Cycle Simulator Workshop – San Francisco

8. Fuel Cycle Analysis Factors
Many interacting parameters
Each change ripples out and feeds back
Multiple competing performance areas
Waste Management
Resource utilization
Proliferation risk
Safety
Security
Economics
Environmental Impacts
Technical Risk
April 6-7, 2011
Fuel Cycle Simulator Workshop – San Francisco 8

9. Fuel Cycle Simulator Workshop – San Francisco
Inertia Example
These sensitivity analysis show the impact of growth rate (left) and used fuel cooling time (right) on total infrastructure development
Finding the drivers behind each line “wiggle” provides knowledge of system behavior
April 6-7, 2011
Fuel Cycle Simulator Workshop – San Francisco 9

10. Fuel Cycle Simulator Workshop – San Francisco
Uncertainty Example
An uncertainty analysis of electricity costs (left) shows considerable overlap, but does not show why
Isolation of individual contributors (right) shows which are common to all cases, which drive the differences
April 6-7, 2011
Fuel Cycle Simulator Workshop – San Francisco 10

11. Example of Variation Driver
Different fuel types include wide variation in non-fuel components
Activation of these non-fuel components add to waste streams
April 6-7, 2011
Fuel Cycle Simulator Workshop – San Francisco 11

12. Example of Variation Driver
In this benchmark comparison, one code is calculating individual fuel loads
This extra information clutters results on the left, but provides insights on the right
The ability to turn on and off these additional features “on the fly” would help with understanding
April 6-7, 2011
Fuel Cycle Simulator Workshop – San Francisco 12

13. FCS Functions
A fuel cycle simulator is more than a model of fuel cycle facilities
Must consider the range of analyses to be supported
Must consider development and maintenance of a large software enterprise
Support range of users
Chart and manage development approach
Maintain and enhance data libraries

14. Interface Needs - Input
A layered approach may assist in building scenarios
Regular users could build up models using predefined facilities and strategies
Expert users would need access to more detail, overriding default values
Model developers would need access to all parameters to define new instances
Data libraries will support all users
April 6-7, 2011
Fuel Cycle Simulator Workshop – San Francisco

15. Interface Needs - Operation
Current codes mostly have a start button
Would like to:
Stop, resume, back-up, branch, change parameters in mid-stream, etc.
What other functionality have you seen with other codes?
April 6-7, 2011
Fuel Cycle Simulator Workshop – San Francisco 15

16. Interface Needs - Output
What to do on the output side is an open issue
Simple graphs to animation
Comparing different cases
Zooming in on specific result features, such as transition points, to understand the underlying drivers
Interactive with simulation versus using saved results
April 6-7, 2011
Fuel Cycle Simulator Workshop – San Francisco 16

17. Interface Technologies
What technologies are needed to support the desired input, operations and output functionality.
How can FCS be delivered on a tablet computer?
How can FCS support wide range of users?
Federal employees
Students
Lab and Industry fuel cycle analysts
Other stakeholders
April 6-7, 2011
Fuel Cycle Simulator Workshop – San Francisco 17

18. Backbone Architecture
What software approaches will best meet the needs for FCS?
Needed functionality
Needed extensibility
Needed development environment
Needed hardware support
April 6-7, 2011
Fuel Cycle Simulator Workshop – San Francisco 18

19. Object-Based Approach?
Most current fuel cycle simulators use a systems dynamics approach
Most facilities, inventories, and other properties are modeled in the aggregate
Limits the number of distinct groups (e.g. reactor types)
An object-based architecture would support discrete modeling of physical items and concepts
Facilities, policies, etc.
Potentially much easier to extend model size
Potentially easier to expand module capabilities
Are there other architectures we should consider?
April 6-7, 2011
Fuel Cycle Simulator Workshop – San Francisco 19

20. “Modified” Open Source
Many features of open source systems seem compatible with the FCS
Code access supports multiple, distributed developers
Transparency of code supports multiple user communities
Encourages collaboration
Some constraints must be accommodated
Some data and specialized code may be proprietary or have export control restrictions
May need to have an independent operations mode to support sensitive analyses (proliferation risk and physical protection, etc.)
April 6-7, 2011
Fuel Cycle Simulator Workshop – San Francisco 20

21. Fuel Cycle Simulator Workshop – San Francisco
Linkage to Other Codes
Other code examples:
Reactor physics codes
Detailed simulations of separations processes
Repository performance models
Market economic models
What is the best approach for each interface?
Library of preexisting results
Interpolation algorithms to cover library gaps
Simplified version of other code embedded in FCS
Link to other code with active calls
Can the approach be adapted “on the fly” to provide desired accuracy?
April 6-7, 2011
Fuel Cycle Simulator Workshop – San Francisco 21

22. General Issue – How Much Automation to Include?
Several levels of automation possible
Automated checking of physical constraints prevents negative masses, other errors
Mandatory to support non-expert users
Automated application of simple strategies
Example - building enough reactors to support an energy generation growth curve
Automated “optimization” of specific parameters
Example – cost optimization of enrichment tails assay
Etc.
The more automation . . .
Easier for non-experts to use
Harder to develop
Sometimes harder to control – gets in the way
May result in calculations that are unnecessary for some analyses
April 6-7, 2011
Fuel Cycle Simulator Workshop – San Francisco 22

23. General Issue - How much detail to model?
Discrete vs continuous system
Tracking levels
Individual facilities
Individual fuel loads
Individual fuel assemblies
What is too much detail?
Detailed modules
Example – Detailed market model of primary and secondary uranium sources – useful for some analyses but not needed for others
Can a system be designed to use more detail only where needed for accuracy?
Can some parts of the system use detailed modules while other parts do not?
April 6-7, 2011
Fuel Cycle Simulator Workshop – San Francisco 23

24. Final Issue – How to Manage Development
There is a significant danger of biting off too much
All things to all users
Ideas to manage development
Be clear on what is needed for initial deployment, what can wait
Prioritize all needs, both for initial system and enhancements
Prototype capabilities before inclusion
Harvesting from current generation simulators
Separate initial models for new capabilities
Implement basic functionality first, then expand when ready for more
Example: cost calculations versus economic system with feedback
Other ideas?
April 6-7, 2011
Fuel Cycle Simulator Workshop – San Francisco 24

25. Systems Analysis Working Group Meeting
The Fuel Cycle Analysis Toolbox
– Brent Dixon, Idaho National Laboratory, USA
Modeling fuel cycle events and advancing time in SITON v2.0
– Aron Brolly, Centre for Energy Research, Hungary
Improvements of Nuclear Fuel Cycle Simulation System (NFCSS) at IAEA
– Ki Seab Sim, International Atomic Energy Agency
Development of an Advanced Nuclear Fuel Cycle Simulator (FANCSEE) with Graphical User Interface
– Waclaw Gudowski, Royal Institute of Technology, Sweden
Using Supply and Demand Curves to Determine Facility Deployment
– Robert Flanagan, University of South Carolina, USA
Regulus: Visual Analysis Exploration of High Dimensional Nuclear Fuel Cycle Simulations Data
– Yarden Livnat, University of Utah, USA
Implementation of a Modernized Transmutation Library Database
– Nicholas Brown, Pennsylvania State University, USA
March 15-17, 2011
Systems Analysis Working Group Meeting