0/ Kick-off meeting: Edge ITM issues (e-mailed 2006-02-17) People: v.kotov@fz-juelich.de Bonnin@limhp.univ-paris13.fr Sven.Wiesen@jet.efda.org zagorski@ifpilm.waw.pl a.kirschner@fz-juelich.de steve.lisgo@ukaea.org.uk Johnny.Lonnroth@jet.uk dcoster@jet.uk With the exception of Steve Lisgo, we met for half an hour and identified working groups, and arranged a time for the next meetings 1/ Defining a standard for coupling fluid plasma and Monte-Carlo neutrals codes: can it be done, and who is interested in doing it Interested people: Sven, Roman, David, Xavier, Steve, Vladislav Next meeting: Wed, 10:00 2/ Defining a standard for the output of plasma codes: can it be done, should it be done, and who is interested in doing it Interested people: Andreas, Sven, Xavier, Roman, David, Vladislav, Steve Next meeting: Wed, 14:00 3/ Core-edge coupling: can it be done, should it be done, and who is interested in doing it Interested people: Johnny, Roman, Xavier, David, Denis Kalupin? Next meeting: Thurs, 10:00 4/ Atomic physics: standardize data formats (multiple dimension interpolation?) Interested people: Xavier, Roman, Sven, Andreas, David, Detlev Reiter? Next meeting: Fri, 11:00 5/ Transport modules Interested people: Johnny, Roman, David, Xavier, Denis Kalupin?, Par Strand Next meeting: not yet scheduled 6/ Boundary conditions Interested people: Roman, David, Xavier, Johnny Next meeting: not yet scheduled Issues: a. tables? b. compatibility with Monte-Carlo codes 7/ Mixed materials Interested people: Andreas, Xavier, David Next meeting: not yet scheduled 1/ Coupling of edge fluid plasma code and Monte-Carlo neutrals code o Most of the fluids codes use quadrilaterals o In future possibility of triangles o Fluid code should pass to interface whatever it is using Action: Steve and Sven Once their interface is cleaned up to circulate it to the group Question Do we need to access the Eirene settings from the B2 side Possible model: - - - - +---+-------------+---+ - - - - | | | | | | | | A | B | C | D | E | | | | | | | | - - - - +---+-------------+---+ - - - - A: plasma fluid code (e.g. B2) B: fluid code specific part of the interface C: generic interface section D: neutrals code specific part of the interface E: neutrals code (e.g. Eirene) Data flow: 1. fluid code (A) passes geometry and plasma information to (B) 2. B transforms the plasma information to some general representation in a standard set of units, using routines from C, and passes the information to C 3. depending on options, C either writes out the information to a file in a standard format, or passes the information to D 4. D reformats the data as necessary and passes it to E 5. E can also request data from D in which case it will be requested from C, which will read the data from a standard file 6. neutrals code (E) passes sources and other information to (D) 7. D reformats the data to a standard format, using routines from C, and passes the information to C 8. depending on options, C either writes the data to a file in a standard format, or passes the information to B 9. B reformats the data from the standard format to that required by A, and returns the data to A Rationale: 1. By defining a standard format in C, the only fluid code dependent piece is B, and the only neutrals code dependent piece is D 2. B and D are both part of the interface package so that they can be written using "utility" routines from C 3. C could also be used to output "snapshots" of the plasma state in a format that is independent of A or E. Action: Everybody What plasma quantities do we need to transfer to the neutrals code? (Sven will start). Action: Xavier, David, Sven What surface quantities do we need to transfer to the neutrals code Action: Xavier, David, Sven What quantities need to come back from the neutrals code Points where care needs to be taken: cell centred versus staggered velocities solps6 might have a complicated geometry --> conversion to triangles 2/ Data format for plasmas provided to other codes (ERO, ASCOT, DIVIMP) o use same format as that provided for in 1/ above, supplemented by neutrals o also issue of quadrilaterals versus triangles (can we do both?) o surface data o need fluxes at surface (need to define what we mean by energy fluxes) o need temperatures etc at the edge 3/ Core-edge coupling Summary of current approaches: A. COCONUT JETTO density from EDGE2D temperature from EDGE2D flux of neutrals from EDGE2D EDGE2D flux of energy from JETTO (assumed poloidally symmetric) flux of ions from JETTO differential time-steps are possible mostly used by Johnny for ELMs in the last couple of years mostly used separatrix for interface but this is not a requirement B. TECXY-RITM sometimes need a relaxation factor because of a difference in time-steps typically 1 core iteration (with internal iterations to resolve non-linearities) 10 - 100 edge iterations mostly used for looking for steady state need to have compatible transport coefficients typically go in about 5 cm inside for interface C. COREDIV - RITM-TECXY COREDIV: slab geometry, to separatrix RITM-TECXY: some ring inside (-4 cm) Possible specification of interface: 1. would call initialization routines in both the edge and core codes 2. would then call the core and edge codes alternately, passing the information required, accepting back the information needed by the other code 3. would call a finalization step at the end of the calculation 4. should also provide a "unified" plasma description by calls to both codes 5. should also provide a standard set of diagnostics/output (in addition to that provided by the two codes) 6. interface might also need to handle any averaging/smoothing 7. should also do some sanity checks Comments: o Better if you have compatible atomic physics 4/ Transport modules: falls under Denis Kalupin within IMP3 o already an interface for core codes by Par Strand o gets settings o chooses modules o calls modules o at the moment only 1d transport coefficients using 1d radial profiles o for 2d edge codes need poloidal resolution of input and output o neo-classical transport not (yet) included in this structure 5/ Atomic Physics o Define a format o Define access routines Format definition --- probably in the form of table interpolation --- could be based on o Roman's use o SOLPS use o ADAS Some concern about data size for multi-dimensional data o sputtering data which might be a function of o projectile energy o target temperature o flux density o mixed materials o layer thickness o ... Working team: Xavier, Roman, Detlev, Dimitri Borodin (?), David Issues: o Extrapolation: use a flag to choose between: 1. stop 2. no reason to go beyond table 3. "simple extrapolation" using asymptotic forms 4. use boundary value o flag for log vs non-log o need to agree units o need to have comments for o origin of data o data quality o max deviation ****************************************************************************** Observations [DPC]: Do we want to combine features of the plasma-neutrals code coupling scheme and the edge-core code coupling scheme? At the moment the schemes differ slightly in philosophy