Quick links

 2011 FACETS Winter Meeting

Documentation for users and developers

Interfaces and naming scheme

Tutorial on FACETS input files

Tutorial on creating a new FACETS updater

Welcome to the FACETS project

FACETS, the Framework Application for Core-Edge Transport Simulations, has the goal of providing modeling of a fusion device from the core to the wall.

(Supported by the  U.S. Department of Energy.)

The image at right shows the cross section of a tokamak plasma, which has a toroidal (donut) shape. The separatrix (so labeled) separates hot, plasma in the center from the cooler, surrounding plasma.

The central plasma is hot because it can move primarily only along the magnetic field lines, and those always remain in the core of the system. Thus, it is never in direct contact with material walls, which would cool the plasma.

In the edge region of the plasma, just outside the separatrix, the magnetic field lines (projections on a poloidal plane shown in green) wrap around the core, but then terminate on the walls. This contact with the walls leads to much cooler plasma.

In the two regions, the plasma is analyzed with different approximations. In the core, the velocity distributions of the particles are nearly Maxwellian, and bulk parameters, such as temperature and density, are nearly constant along field lines and, hence, on flux surfaces, the surfaces on which the field lines remain. This constancy in flux surfaces implies that the plasma has only one-dimensional variation, where the dimension that crossing flux surfaces. In the edge, the plasma varies strongly along a field line, from region in the midplane near the core to the ends, which are in contact with the walls. Hence, in this region the plasma has two-dimensional variation. Being cooler, the edge region can have a high density of atomic species, while in the core, the plasma is for the most part fully ionized.

Just inside the separatrix is a transition region, where the cool, two-dimensional plasma of the edge morphs into the hot, one-dimensional plasma of the core. The atomic physics processes become less important, and the character of the turbulence, which controls the plasma confinement, changes. In this region it is possible for a pedestal to form. At the pedestal there can be nearly a transport barrier, such that the temperature of the plasma can be very different across it. Good pedestals are needed for the beneficial H-mode of operation.

Important to the dynamics of this system is how the edge plasma interacts with the wall. The fuel for fusion is Hydrogen (actually, its isotopes, Deuterium and Tritium). The nuclei of these atoms can diffuse into the wall and be released at a later time. These processes are important to fusion confinement devices, as they act as boundary conditions on the edge plasma, determining, in part, the influx of particles.

Bringing together the capability to model this complex, combined system requires contributions from multiple scientific disciplines (plasma physics, applied math, computer science). The project will make maximal reuse of existing software, developing strategies for coupling this software to provide comprehensive modeling capability. Issues of coupling cross multiple fields as well. An important goal of FACETS is to be able to take advantage of the largest petascale computational facilities now coming on line.

FACETS FAQ

Q1. What can FACETS couple now and in the future?

A1. We distinguish between in-memory coupling and coupling that results from the workflow which is done through files and is shown at wiki:CoreEdgeWorkflow. It involves experimental data analysis (fluxgrid), processing the results into a facets-readable file, running facets, and visualization. All of this can be fairly asynchronous.

We are also working on more complex workflows in collaboration with DIII-D experimentalists. For these, we are using a combination of shell/python scripts to handle the more complex sources of data (iterDB, UFILES, etc.

Our in-memory, or application coupling consists of, for now:

a) Surfacial coupling of an edge code and a transport code within the framework (which mediates all couplings)

b) Coupling of embedded turbulence computations in a transport code

c) Coupling of neutral beam sources to the framework.

In the future:

d) Coupling of the wall to the edge (within the framework)

e) Coupling a dynamic equilibrium code into the mix. f) Coupling of fluid edge turbulence codes (e.g., BOUT++)

g) Coupling of kinetic edge transport codes (e.g., TEMPEST, XGC0)

h) Coupling to kinetic edge turbulence codes (e.g., XGC1, ESL code)

Q2. What kind and size of data being exchanged at coupling?

A2. For the cases above numbers are:

a) a few numbers

b) a few numbers for each fluxtube

c) a few hundreds of numbers with a complex communication pattern NUBEAM collects profile data on rank 0. That data is brought to facets through memory. FACETS sends per-flux-surface data to each of those. Those broadcast that (now just a few numbers) throughout a few-hundred sized communicator

d) Each rank of the edge code has a few numbers per boundary cell that must be communicate to the wall code instance.

e) A few 10ks of numbers to be communicated. Strategy not yet determined.

g) Same as in a

f,h) Very much a research topic due to the non-locality of edge turbulence.

Q3. How often the coupling occurs (every step etc)?

A3. Since the core and edge codes are implicit, at least a, b, d are done 10's of times per step. May have to with d as well.

Causality implies that core-edge-wall-sources coupling be at the same time.

Q5. What is summary of the performance (coupling vs the rest)?

A5. This is under study now. But initial tests indicate that the framework imposes a minimal overhead which is expected given that the amount of communication is small and the amount of component computation is high.

Q6. Do we have control over external codes (where are the repos?).

A6. All collaborators have allowed copies of codes with all source to be put in repos at Tech-X. Periodic syncing occurs for codes with external homes (NUBEAM, GYRO), but there is total openness. Anyone can look at all source code.

Documentation

Documentation home page

Participants

The FACETS project is a multi-institutional, interdisciplinary project. Funded participants are contributing to the software and/or carrying out research on code coupling. Unfunded participants act as liaisons to other projects and provide advice.

Currently (as of August 2010) funded participants

	Institution	acknowledges support from the Department of Energy under grants and contracts
	Tech-X Corporation (lead): John R. Cary (Tech-X and FACETS PI), Johan Carlsson, Ammar Hakim, Scott Kruger, Mahmood Miah, Alex Pletzer, Svetlana Shasharina, Shrinath Vadlamani	DE-FC02-07ER54907
	Argonne National Lab: Lois Curfman McInnes (PI), Satish Balay, Sean Farley, Michael McCourt, Hing Zhang	DE-AC02-06CH11357
	Colorado State University: Don Estep (PI), Tavener	DE-FC02-07ER54909
	General Atomics: Jeff Candy (PI), Richard Groebner	DE-FC02-07ER54921
	LLNL, Ron Cohen (PI), Tom Rognlien, Tom Epperly, Linda Lodestro	DE-AC52-07NA27344
	ORNL: John Cobb (PI)	DE-AC05-00OR22725
	Paratools Inc.: Allen Morris (PI), Sameer Shende, Wyatt Spear	DE-FC02-07ER54910
	Princeton Plasma Physics Lab: Doug McCune (PI), Greg Hammett, Kumar Indireshkumar	DE-AC02-76CH03073
	University of California at San Diego: Alexander Pigarov (PI)	DE-FC0207-ER54908, DE-FG0204-ER54739

Unfunded participants

	Columbia University: David Keyes, PI
	PSFC-MIT: Paul Bonoli, PI

SciDAC collaborations

The FACETS project is making use of software developed by the SciDAC program. This includes the PETSc library of the TOPS Center, the  BABEL interlanguage package of  TASCS, the  VisIt visualization tool from VACET, and the  TAU Performance System (R) supported by  ParaTools, Inc.