Main Page
From Fusion Project Wiki
[edit] Scheduled Teleconferences
- Tuesday: Math and CS Panel, 05/29/2007, 2:00 - 3:30PM EDT, 301-903-6259
[edit] Comments on FSP Report
[edit] Comments on Chapter 1 Introduction
[edit] Comments on Chapter 2 Scientific Modeling Issues
John Shalf: Here is a first pass through the physics section. My aim is to try to identify missing information relating to the CS/application requirements to meet their scientific modeling goals.
Regarding: Section I: Critical issues for Burning Plasma Experiments Section A: (disruption and mitigation) It says "many codes describing individual disruption processes or partial integration of relevant physics elements are presently in use worldwide" Ultimately it would be useful for each of these subsections to enumerate these codes (names and capabilities). Perhaps this should be an appendix, but we really need to have code names and the associated research groups if we are to track down this information.
It also says "complete nonlinear evolution of the instabilities that play a role in the crash phase is extremely difficult to compute." We really need to have some baseline to establish "how difficult to compute" and how much the current codes fall short of reaching their goals for ITER (how long does it take to model something smaller than ITER and what is a reasonable, but not precisely accurate extrapolation to requirements for ITER. This would be of the form
- Name of code to address this science problem
- current state-of-the-art modeling scenario with this code (some example questions are)
- what device can you currently model and
- what are resource requirements in terms of memory and CPU time on *some* machine
- what concurrency is the code typically run at
- what currently limits performance (scaling efficiency, lack of parallelism, IO, physics?)
- has the code been instrumented (performance counters) or studied in any way to understand the above questions (if so, can you point us to papers or performance data in that regard)
- some reasonable approximate projection of the above requirements to an ITER-scale problem
This section is not as clear as Section B regarding what codes or ab-initio models would need to be coupled to answer the critical scientific questions. part (3) describes what additional features of the plasma need to be modeled, but is not clear to the CS folks which codes (or what kind of codes) would need to be coupled to answer these questions (or whether it is improved physics modules for the MHD codes rather than code coupling). That needs to be clearer
As Pat has pointed out, this information may need to be introduced in our section (guidance on where to put this information would be appreciated), but we need the physics folks to provide us with this information (code names and best guess of resource requirements to solve the target problem) so we can say something sensible.
Section B: Pedestal formation
Unlike the last section, this section actually enumerates some first-principles codes (very useful). It would be good to have some information about which integrated modeling codes are used for the approximate modeling and if the ab-initio models could reasonably be used to enhance the approximate models or if it is expected that the ab-initio models would need to replace the approximate models in the current integrated modeling codes. At the FSP meeting, I got the impression that it was more the former than the latter...
Section C: Tritium Migration and Impurity Transport
subsection (2) indicates that this is modeled primarily using 3D Monte Carlo, but does not enumerate the names of any code examples that implement this algorithm. The same is true for the description of the "binary collision approximation" codes in the following paragraph. We really need to have some code names to work from. We also need to know what the current resource requirements are for a current state-of-the-art simulation, (how well they perform and what range of concurrencies do they work reasonably efficiently for). We also would like to know what the projected resource requirements are to meet their ultimate objectives (rough extrapolation from existing code examples... not for capabilities or algorithms that haven't been written yet).
Section D: Performance Optimization and Scenario Modeling
subsection (2) makes it clear that the current code base needs to be re-engineered to support better modularity, documentation, and reliability. Do we start again with massive parallelism in mind, or are the approximate models sufficiently light that a modest degree of parallelism would suffice (eg. it currently runs for a week on a workstation... is this a petascale problem, or something that should target the midrange?) Will this framework need to couple to some components that model from first-principles, or do some subset of first-principles codes drive optimizations of the approximate models, which can run with lower resource requirements?
I'll send this set of questions out to the group before getting into section II.
_________________________
John Shalf: I was supposed to focus on the Turbulence and Transport section (sect II A).
This does a good job of describing the performance of some of the PIC codes that model plasma microturbulence.
- they get 12-15% of peak machine performance per processor as measured by the FLOP rate
- Fig 2.6 shows excellent scaling (NOTE by AHK at request of math telecon Fig 6 has been removed) (we need this kind of data for the other sections)
They state in subsection (1) that it requires a factor of 40 reduction in stepsize and factor of 403 increase in computational power, but it doesn't provide a baseline resource requirements that could help us to relate it to figure 2.6. It does not have a connection between the code performance and how that relates to the scale of computational model described in Fig 2.6. It also does not provide information about the scale required to model an ITER scale device aside from the 403 increase in computational power (without establishing a baseline). Such an extrapolation was provided in the Dahlberg report, but should probably be reprised here with updated information.
The data provided is for the PIC codes, but not for the continuum codes. Is there any data for the continuum codes?
It should enumerate the names of candidate codes just as it did in the Dahlberg report.
It is not crisp about what codes it may be coupled to in subsection (3). It seems to imply that it would be part of a fully integrated modeling framework. Is this practical, or are there some intermediate pairwise couplings that would be tractable in the first 6 years of the project?
______________________
Ron Cohen: Phil forwarded to me the latest draft of the physics document for FSP. I recognize most of what CS and I wrote in the current draft and for that I am most appreciative.
However there is one key item that is missing from the edge discussion, and I can't recall if that was an oversight on our (CS's and my) part or if it was in the document we submitted but edited out, and that is any mention of the importance of (and need to be able to calculate) the dynamics of large-amplitude coherent structures ("blobs"), and in particular their propagation to the main chamber walls. This phenomenon could be exceedingly important in establishing the distribution of sources of main-species gas and impurities. There is plenty of mention about heat and particle fluxes to divertors, but blobs could completely upset the apple cart...
Note by AHK: Edge is included in discussion of critical issuses for burning plasmas. A few sentences re blobs could be added if they are seen as a critical issues.
______________________
Tom Rognlien: Having read through the Physics panel section (as sent earlier this week - Tuesday, by Phil), I had meant to provide more detailed comments on this section, but I have run out of time - and I am leaving in the morning for a meeting. While I think that many good points and arguments are made here, I do have a few general comments/concerns:
1) The introductory paragraph gives the impression that all physics components are reasonably well in hand, and "all" the FSP has to do is put them together. I think this is both not true and that this detracts from the sense of exciting fundamental scientific discovery within components that still needs to happen. Some of this component work will come from the base program, but certainly some will/should also come from FSP; somehow, this should be acknowledged.
2) The introductory ITER-issue paragraph on the pedestal does not mention the key unknown of what sets the pedestal temperature and thus fusion gain for ITER and how to control it; I think it should.
3) Even though tritium and impurity control is one of the major ITER concerns/issues listed, the wall physics associated with this is not anywhere as a "component" in the next listing. I know this is a complex issue, both physically and computationally, and politically; nevertheless, I think a strategy/vision needs to be mentioned (e.g., Eckstrand's mention of a possible SciDAC in '09 for this "lagging" component - but certainly it will/should be a FSP component in the 5-10 year time frame).
______________________
Ron Cohen: I second Tom's comments and would like to add some:
RE 1 -- I would say there is also exciting discovery outside of individual components, in the realm of meso- couplings (new things will be discovered when one puts together macro-MHD and turbulence, for example). Also I think it is far from obvious that the old notion of a 1D core transport code as the primary integration vehicle is the right vision. we just don't know yet. It may be that diffusive transport is often enough a poor paradigm that there are better solutions -- maybe a 3D extended MHD code, coupled to turubulence codes; maybe an EM gyrofluid code; maybe EM gyrokinetic codes with equation-free methods (projective integration) to get to transport timescales -- many possibilities.
RE 2 and 3 -- indeed 2 of the 5 physics challenges involve the edge, but there is no edge component at all in the list of components. Arguably edge fits in under "turbulence and transport", but the description of the turb. and transport component sounds extremely core-like.
[edit] Comments on Chapter 3 Code Integration
Arnold Kritz and response by Dan Meiron:
DM: Arnold - I took a stab at responding to your comments. Not sure I was able to satisfy everything but the attached version should be closer (and shorter).
All - please read this new version and comment.
Some replies to Arnold below
AHK: Some thoughts and possible improvements for the Integration chapter although I found the Chapter well writen and informative.
Is it possible to establish more of a direct connection in the subsections in the Multi-physics coupling section, section 3, and FSP. Can it be made clearer why a computational infrastructure that is described in the chapter is required for the success of FSP?
DM: I thought we had done this - this is section 3 - perhaps it's still too oblique so let me know if it reads better now.
AHK: Whenever there is a choice between different kinds of computational infrastructure, what criteria should be used in making the choice to make FSP successful?
DM: We don't know that there is much choice - the only risky issues are component frameworks - we do discuss this as a risk that can be carried along and left to a later decision.
AHK: Can a the time line for deliverables be established in order to accomplish the transition be made from current computational capability to the new capability?
DM: I tried to do this in a new section on project phasing - please add or edit as you see fit.
AHK: In the Scientific Issues Chapter, we used names of projects rather than names of associated individual scientists. It might be better to follow this approach in the Code Integration and Management chapter.
DM: OK - could someone go through the section and do this? I don't know all the right project names.
AHK: Is it possible to tighten the connection between the scientific issues (listed at the beginning of Section 2 ,page 1) and the remainder of the chapter on integration?
DM: I tried - I agree it was very discursive - but there are connections in the text between coupling and physics requirements. Maybe we need more.
AHK: Some reduction in the use of acronyms might be helpful. Page 15 seems to be particularly heavy in the use of acronyms. Also, if possible, it is helpful to define the acronyms at their first use. For example, I could not find the definition of SPMD.
DM:I tried to define all acronyms before they appear but please check.
AHK: Verification is carefully defined, and even redefined, on page 18, but validation is used without being specifically defined on pages 18-20. In any event, there may be a separate chapter devoted to verification and validation and perhaps this material should be all collected and merged in that chapter.
DM: That's fine - feel free to excise this material. I do think it's better if VandV were discussed separately
AHK: The findings and recommendations on pages 26 and 27, in general are quite good, but do not seem to be tightly connected with and specifically supported by the text in the chapter. By incorporating FSP more directly in the chapter, a better connection between the recommendations the remainder of the chapter might be produced.
DM: I took these out - see if it reads better now.
AHK: I appreciate the effort that is being devoted by all to making the FSP report effective at accomplishing the goal of getting FSP moving forward. Thank you.
DM: Sure - as I mentioned - after June 11 I most likely can't work on this anymore so perhaps someone else (Tom, Andrew) can carry the torch (so to speak).
__________________________
Comments by Chandrika Kamath
These are comments on the version that Arnold sent around on June 4.
1. Section 7 on software management seems out of place with the rest of the text in the chapter. At the Rockville meeting, there was talk of having a separate chapter on software engineering issues. If so, Section 7 would be more appropriate there.
2. I notice that the chapter mentions "workflows." This is an issue which should also be included in the CS part of the Math/CS chapter. I will put together a short paragraph on the need for workflows and their role in FSP.
3. This is a comment for the CS folks - the integration chapter mentions data transformations, data exchanges, and data formats. The CS chapter has some text on data sharing by John Shalf - this should point back to the integration chapter for motivation and the appropriate parts of both sections should be checked for consistency and to avoid repetition.
4. Section 6 on "Validation and Data". This section includes the text "To a considerable extent, the challenge is not a problem of CS or physics research. It is a software engineering (and human interface engineering) problem ..." This (and the supporting text) seems to indicate that validation is trivial. I am not a physicist, but based on the work I do with physicists in mining their data, I get the impression that validation is rather difficult, especially when image data and/or poorly understood physics is involved. I think there is a lot of work which still needs to be done in validation to generate results which are meaningful both from a physics viewpoint and an analysis/statistical viewpoint.
5. Is there a possibility that as two or more codes are integrated, they may result in new physics issues which have to be addressed? It is not clear from the text if this is the case.
[edit] Comments on Chapter 4 Math and Comp Sci
[edit] Comments on Chapter 5 Verification and Validation
Comments by Chandrika Kamath
I like the way the challenges in V&V are described. I have one question:
Should QMU (quantification of margins and uncertainty) be included in this chapter? it is sort of mentioned in various places, but not called out explicitly.
and a comment:
Some of the text in the data mining section in the CS part of the Math/CS chapter would be relevant here and might allow the phycisists to benefit from some low-hanging fruit. The techniques we use for identifying structures in raw data (meshes, particles, or images) can be used for statistical comparisons. There is also the idea of building code surrogates which can be used for prediction and to guide both experiments and expensive simulations. If done right, it can also indicate gaps in the sampling of the input parameter space.
[edit] Comments on Chapter 6 Management
[edit] Zero Order Draft of Workshop Report
0. Executive summary: (? pages)
1. Introduction (8 pages)
- a. Objectives
- b. Motivation compelling reasons for FSP (based on motivation material on top page of wiki)
- c. Existing FSP protypes
- d. Summary of deliverables and time line (based on Deliverable material on top page of wiki)
- e. Summary of computational requirements to achieve goals
- i. New opportunities based on new computational facilities
- f. Summary of possible project structure and management
- g. End the introduction with a vision of what FSP can achieve
2. Physics components (15 pages)
- a. Physics issues (current status and what needs to be done)
- i. What physics issues need to be addressed for ITER
- ii. Current status of physics simulation codes
- b. What new physics problems can be solved with high performance computer simulations
- c. FSP prototypes
- d. Interaction between physical processes
- i. tight versus loose coupling
- e. Physics issues that will be addressed by FSP
- a. Physics issues (current status and what needs to be done)
3. Integration and Management of Code Components (12 pages)
- a. Component coupling and framework issues
- i. Integration approaches
- b. Approaches used by other simulation projects
- c. Validation and verification procedures
- d. Coding standards
- e. Code management
- a. Component coupling and framework issues
4. Computational and Applied Math Tools (12 pages)
- a. Numerical algorithms
- i. discretization, adaptivity, solution techniques, optimization
- b. Turning legacy code into high performance code
- c. Modern computational engineering
- d. Data handling
- e. Graphics and visualization
- f. Scalability to high performance computers
- g. Performance evaluation and engineering
- a. Numerical algorithms
5. Verification and Validation
6. Project Structure and Management (12 pages)
- a. General management structure
- b. Advisory and oversight
- c. Accountability
- i. process to follow when deadlines are not met
- d. Financial arrangements, resource control
- e. Reporting requirements
- f. Relation to ITER and experimental facilities
7. Conclusion and Summary (2 pages)
- a. Pull the report together with a strong vision statement at the end
Appendix A: Prioritized list of ITER needs
Appendix B; List of acronyms
[edit] Agenda for Workshop
New agenda PDF file, 9 May 2007
http://fspwiki.web.lehigh.edu/images/d/d8/FSP_Workshop_Agenda_Final_May_7.pdf
Draft of Fusion Simulation Project Workshop May 16-18
Wednesday 5/16/2007
Plenary Session
- 8:30 Welcome and Organizational Announcements David Keyes / Arnold Kritz
- 8:35 Michael Strayer, Associate Director for Advanced Scientific Computing Research - Introductory Remarks: Fusion Simulations at Extreme Scale
- 8:55 Ray Fonck, Associate Director for Fusion Energy Sciences, and Steve Eckstrand, OFES - Introductory Remarks: Initiating the Fusion Simulation Project
- 9:15 Wayne Houlberg, ORNL, ITER Integrated Modeling Needs
- 9:50 Questions and discussion regarding ITER requirements
- 10:00 Coffee Break
- 10:15 Marty Marinak, LLNL: Role of Simulation in the Inertial Confinement Fusion Program
- 10:50 Discussion on what can be learned from simulation experience in the ICF program
- 11:00 Project Management and Structure (M&S) Panel Introduces Scope of Project and project structure and management
- 11:30 Feedback to M&S panel from all panel members and observers
- 12:00 Working Lunch M&S Panel discusses feedback; other panels discuss and finalize their presentation
Plenary Session Continues
- 1:00 Physics Panel Presentation to other panels
- 1:20 Discussion of Physics Panel Presentation
- 1:40 Code Integration Panel Presentation to other panels
- 2:10 Discussion of Code Integration Panel presentation
- 2:30 Computer Science / Applied Math Panel Presentation to other panels
- 2:50 Discussion of Computer Science /Applied Math Panel presentation
- 3:20 Break
Breakout Sessions
- 3:40- 5:30 Panel Break out sessions
- 5:30- 7:00 Dinner (Panel Chairs meet to discuss evening work)
- 7:00-10:00 Panel breakout sessions
Thursday 5/17/2007
Plenary Session
- 8:30-10:00 Panel Leads present status reports and allow brief time for feedback from all panel members and observers
- 10:00 Break
Breakout Sessions
- 10:15-2:45 Panels continue to work on draft of report including working through lunch
Closing Plenary Session
- 3:00-5:00 Panels present their (almost) final recommendations and findings to the entire workshop followed by a Q&A session
- 5:00-5:30 Closing remarks by Co-Chairs, OFES, OASCR Possibly by Chair of FESAC Sub panel.
Public part of the workshop concludes. Observers and most panel members leave. FSP Committee and Scribes remain.
Friday 5/18/2007
- 8:30-4:00 FSP Committee, scribes and DOE Office of Science organizers (if needed) meet to assemble draft of the workshop report (the panel contributions should be almost complete by the end of May 18.
- Adjourn 4pm
[edit] Fusion Simulation Project Study
[edit] Panels
- Project Structure and Management
- Integration and Management of Code Components
- Status of Physics Components
- Status of Required Computational and Applied Math Tools
[edit] Motivation
Talk by Joel Parriott/OMB Particularly note slides 10-15
http://fspwiki.web.lehigh.edu/images/b/b3/ParriottOMB.pdf
Our goals for the fusion simulation project:
A. With respect to ITER the highest level goal of the FSP is to contribute to making ITER a successful project. Specifically simulations would:
1. Allow us to carry out the experimental program more efficiently - to make the best use of the finite number of ITER pulses
The ITER specification is for 30,000 pulses over its lifetime. Operational considerations will probably impose limits of 1,000 to 2,000 pulses per year. We expect operational time on ITER to be highly oversubscribed, that is there will many more experiments proposed than there is machine time available(just as on current facilities). The operational space which is explored, is much too large to search exhaustively, thus researchers today use the relatively crude integrated modeling codes available to focus efforts on the most promising scenarios. A capable, validated model for simulating ITER discharges similarly would allow the physics team to design the most productive experiments. This is particularly important as ITER will be the first magnetic fusion experiment to be dominated by self-heating. This plasma regime is fundamentally new, with stronger self-coupling and weaker external control.
High performance fusion plasmas must necessarily operate near disruptive limits but cannot exceed them. Since ITER will only be designed to withstand a fixed number of full-current disruptions, it is imperative that we not determine the disruptive limits purely experimentally, but do so with a combination of experiment and modeling. Also, it is essential that we develop disruption mitigation techniques so that when a disruption does occur, its damage to the first-wall and divertor plates will be minimal. The modeling codes will be indespensible for this purpose. Modeling can also be used to avoid regimes with large ELMs, or to develop mitigation techniques if they do occur.
[Modeling can also reduce risks to the ITER facility by predicting and avoiding interactions which can stress mechanical or electrical systems. For example, by integrating high-quality physics modules with models for control systems and power supplies, codes can help operators reduce the AC losses in the poloidal field coils and thus reduce the chances of a quench in the superconductor windings.]...is this paragraph needed?
I suggest adding a paragraph on ITER start-up. There is very little experience in starting up a superconducting tokamak with very different limitations such as rate of current ramp and more distant field shaping coils. There is very high pay-off using FSP capabilities to simulate start up. Machine safety and protection can also come in here (Vincent)
2. Enable new modes of operation, with possible extensions of performance
Validated, integrated models will enable researchers to extrapolate from smaller experiments carrying out experiments in non-burning regimes. This would allow regimes discovered and explored on these devices to be efficiently tested on ITER. For example, the so-called advanced tokamak regimes could extend ITER's performance and help bridge the gap to DEMO. But the combination of enhanced stability, transport barrier formation, and bootstrap current drive make these regimes very difficult to establish experimentally without comprehensive modeling codes as being developed by this project.
3. Increase the scientific return on the government's investment in the project through improvements in data analysis and interpretation
Just as simulations will be used to motivate and design experiments on ITER, they will be crucial in interpreting measurements and analyzing results. Although highly sophisticated, plasma diagnostics can only sample a very small portion of the available phase space. Codes can be intrumented with "synthetic diagnostics" which provide a bridge between measurement and model and which allow the measurements to be understood in context. Well designed experiments would be used to validate models and allow them to be used for prediction.
Add a discussion on the order of magnitude increase in scientific data necessitating efficient technology for data management, visualization and sharing. FSP will contribute to solving this issue. (Vincent)
4. Provide an embodiment for the scientific knowledge collected on ITER
To move beyond ITER toward commercialization of fusion energy, we must capture the knowledge gained by our research and express it in a form which can be used to design future devices. If the world's innovative confinement concept program is significantly successful during the this period, the U.S. may choose to develop a DEMO based on some other magentic configuration. A set of validated, predictive models from ITER could embody our scientific and technological understanding of fusion systems and allow fusion energy to go forward on a firm basis, even if the underlying confinement geometry was different from a tokamak. (Vincent)
B. There are further goals for the FSP which align with the OFES mission to "advance the knowledge base needed for an economically and environmentally attractive fusion energy source".
To this end, the FSP would carry out cutting edge research in computational plasma physics. Multi-scale, multi-physics modeling in this field are among the most challenging of physical science problems.
The FSP would also produce widely-used computational tools in support of a wide range of OFES programs.
[this is a very rough outline, I will fill in more details, but everyone is welcome to add content and comments. Per Phil's comments, we need to describe the impacts specifically and preferably quantitatively - mjg]
[Two other points: motivation needs to interact with a time line, needs to be sufficiently specific so that it justifies the FSP deliverables. - PC]
[edit] Deliverables
5-year:
Current state-of-the-art plasma simulation capabilities will be combined together into an interoperable code suite within a framework. The capabilities to be present in the code suite include modeling of:
- Integrated Plasma Simulator (IPS)
- Global Nonlinear Extended MHD (XMHD)
- Nonlinear effect of Energetic Particle (EP) Modes
- Turbulence and Transport Modeling (TT)
- RF, NB, and alpha - Heating, current drive, and momentum sources
- Edge Physics (including pedestal, ELMs, atomic physics)
- Fueling Mechanisms including plasma-neutral interactions and radiation
- Experimental data reconstruction
- Synthetic Diagnostics
Interoperability implies that the simulation results from one calculation can be easily utilized by another.
The framework will allow these capabilities to be accessible to the greater plasma physics community, and will facilitate comparison with experimental data and access to computing resources, data storage, and display. It will be flexible enough to allow upgrading in the future.
An extensive program of V&V will accompany the code development
At the end of this 5-year period, basic capabilities will be in place to perform the calculations needed to support ITER facility design and review decisions. The IPS will be capable of performing entire discharge modeling including required coil currents and voltages. Modular plug-in units to the IPS will describe, at a reduced level, all classical and anomalous transport coefficients, all heating, particle, current drive, and momentum sources, MHD events such as sawtooth, island growth, and ELMs. In addition to the IPS, which is essentially axisymmetric (2D), there will be a number of state-of-the-art 3D codes solving more first-principles equations that will be used for time-slice analysis. These 3D codes will be used to better understand the underlying physical processes and in doing so to refine the reduced models in the IPS code. They will also be used for such things as developing mitigation methods for ELMs and disruptions, and for predicting the effects of EP modes. At this stage, the IPS will be capable of basic control system modeling involving coil currents, density control, burn control, etc. Also synthetic diagnostic development will allow the 3D codes to be used for diagnostic development.
10-year:
Each of the 5-year capabilities will have been improved due to improved underlying models verified by extensive experimental comparison. In addition, new capabilities will be added to the code suite to enable the following calculations:
- Coupled physics involving MHD and RF
- Coupled physics involving MHD and EP
- Coupled physics involving MHD and core turbulence
- Coupled physics involving MHD and edge physics
- Coupled physics involving edge turbulence and other edge physics
- Initial modeling of dominant alpha heating with MHD and transport
- Ability to simulate active control using heating, fueling, and CD systems
- Modeling of external feedback by 3D perturbed magnetic fields
At the end of this 10 year period, models will have been developed for most of the complex interactions that involve coupling the effects of physical processes at two time and space scales. These coupled codes will also be capable of IPS time slice analysis. The coupled physics codes will be used to develop more sophisticated control systems where the heating, fueling, and current drive systems as well as external 3D coils are used as actuators. Examples of these are the use of RF to control monster sawteeth and prevent island growth and the use of external 3D fields and/or rapid pellet injection to control ELMs. We expect these coupled codes to lead to significant increases in our understanding of many complex processes including the formation and properties of the edge pedestal, and of the details of the different causal mechanisms that lead to plasma disruptions. These developments will lead to improved modules for the IPS, and to more realistic prediction of plasma scenarios.
15-year
Besides improving all the component physics models and the coupled models, we have moved to a regime where we can perform couplings more complex than the binary couplings listed above. Thus we have the new capability:
- Perform coupled physics calculations involving all or any combination of MHD, EP, RF, core turbulence, edge turbulence, and other edge physics.
At the end of 15 years, we will have a unique world-class simulation capability that will be used in many ways to get maximum benefit from ITER. We can expect that this will be used to identify optimal operation modes for a burning plasma that have the right combination of good confinement, high fusion gain, and are free from disruptions. This capability will be used extensively in experimental shot design for ITER as well as in analyzing the data from ITER and comparing it with predicted simulation data. It will also be used to further tune the many control systems in ITER. We can also expect that such a sophisticated and well validated simulation tool as that developed by this project will play an indispensable role in the design of next-generation fusion devices such as DEMO and beyond. In this regard, the U.S. should now have obtained a competitive edge over our ITER partners in longer term fusion energy development.
[edit] Computational requirements to achieve goals
[edit] Background
_____________________________
Talk give by Wayne Houlberg at US-Japan workshop on ITER_Modeling Needs
http://fspwiki.web.lehigh.edu/index.php/Image:Houlberg_ITER_Modelling.pdf
__________________________
FESAC Subpanel report on Inertial Fusion Energy
http://fspwiki.web.lehigh.edu/images/1/18/IFEPanelReport-1.pdf
