• Media type: Report; E-Book
  • Title: B2–B2.5 Code Benchmarking
  • Contributor: Dekeyser, W. [Author]; Baelmans, M. [Author]; Voskoboynikov, S. [Author]; Rozhansky, V. [Author]; Reiter, D. [Author]; Wiesen, S. [Author]; Kotov, V. [Author]; Börner, P. [Author]
  • Published: Forschungszentrum Jülich GmbH Zentralbibliothek, Verlag, 2011
  • Published in: Jülich : Forschungszentrum Jülich GmbH Zentralbibliothek, Verlag, Berichte des Forschungszentrums Jülich 4337, III, 52 S. (2011).
  • Language: English
  • ISSN: 0944-2952
  • Origination:
  • Footnote: Diese Datenquelle enthält auch Bestandsnachweise, die nicht zu einem Volltext führen.
  • Description: ITER-IO currently (and since about 15 years) employs the SOLPS4.xxx code for its divertor design, currently version SOLPS4.3. SOLPS.xxx is a special variant of the B2-EIRENE code, which was originally developed by an European consortium (FZ Jülich, AEA Culham, ERM Belgium/KU Leuven) in the late eighties and early nineties of the last century under NET contracts. The particular code version SOLPS4.3 is at present jointly maintained and upgraded at ITER-IO and FZ Jülich. Other versions of B2-EIRENE (and SOLPS.xxx) have been advanced by other research groups, notably at IPP Garching, in various different directions. Most important amongst those for our present work is the SOLPS5.2 version with the probably most advanced model available today for classical drifts, currents and electric fields in the plasma fluid module, developed by V. Rozhansky and co-workers (St. Petersburg State Polytechnical University). Surprisingly, merging the various versions of B2-EIRENE into one single, all-including code package requires significant effort. Until today even the very similar edge plasma codes within the SOLPS family, if run on a seemingly identical choice of physical parameters, still sometimes disagree significantly with each other. It is obvious that in computational engineering applications, as they are carried out for the various ITER divertor aspects with SOLPS4.3 for more than a decade now, any transition from one to another code must be fully backward compatible, or, at least, the origin of differences in the results must be identified and fully understood quantitatively. No computational engineer can allow his ability to solve an urgent design problem be limited by somebody else’s decision to change a code. Already in the past significant effort went into code-code benchmarking, even within the SOLPS family, but sometimes with limited success. We believe that one of the shortcomings of all previous code-code benchmarks was the application of the entire SOLPS model to highly integrated, multi-physics cases, i.e., to ...
  • Access State: Open Access