1. Introduction


Fig. 1.1 Illustration of the SMITER Graphical User Interface for ITER. The code allows several run-cases in one study (a) to be run (f) in parallel on a compute cluster. ParaView window (b) shows resulting target top panels (blue), selected characteristic field lines (red), omp disk (yellow), a complete blanket sector CAD model from the Geometry module and a shadow mesh from the Meshing module (grey) augmented a for overall evaluation of run-case setup. The magnetic equilibrium with LCFS and Limiter/Wall geometry (c) and other details can be further analyzed with built-in 2D and 3D plots such as flux function detail (d). Triangular meshes (j) are the main run-case geometry setup (e) that are directly imported or meshed from CAD models (i) defeatured to retain only the required PFC surfaces for meshing with different algorithms and hypotheses. Resulting heat fluxes on the panels (g) can be further processed to get ITER first wall panel (FWP) (h) using FEM thermal models built into the SALOME environment of normal heat flux (NHF) or enhanced heat flux (EHF) cooling sub-structures.

The SMITER fieldline tracing code together with its graphical user interface (GUI) provides a simulation framework for variety of use cases. Its main uses at ITER Organisation are:

  • Power deposition mapping for first wall and divertor plasma-facing components
  • Input to control algorithms and production of synthetic surface temperatures for diagnostic design

The GUI framework provides CAD integration, meshing, visualisation, scripting, and state storage in hierarchical data files (HDF) with several simulation cases in one study. SMITER uses the SMARDDA [Arter16] kernel for field line tracing that was thoroughly benchmarked against the CEA field line following code PFCFLUX [Fird13]. SMITER allows fast and accurate calculation and prediction of the power deposition by the plasma on the limiter and the divertor geometries.

Technical features of SMITER are:

  1. accurate field-line integration which includes user controlled tolerance to check the convergence, cubic spline interpolation of the magnetic field, the option to use flux coordinates for speed and accuracy in simple flux geometries, and vacuum field option in 3D space,
  2. local or global calculations for the limiter or the divertor,
  3. toroidally periodic feature which offers the ability to specify only 1/18th of the geometry SMITER engine features.

SMITER requires accurate representations of first wall geometry and magnetic field equilibrium as an input. Optionally, ripple magnetic field representation can be added to the study.

The graphical user interface of the SMITER code (SMITER GUI) has been developed in order to facilitate easier manipulation of geometry and representation of the magnetic field. The SMITER GUI application is integrated in the [SALOME] platform, which is an open software framework for integration of numerical solvers in various physical domains. The SMITER GUI provides an user-friendly and efficient user interface for data preparation and data post-processing of the SMITER simulation results with enhancements in visualisation output. The SMITER GUI provides an interface for the field-line tracing, shadowing effects, and power surface deposition calculations. The GUI framework integrates the SMITER software into a single and extensible framework in which model set-up, visualization, code execution and analysis of the results can be performed. It also provides a built-in 3D analysis tool that will re-assemble required functions normally provided by the ParaView as an external tool to the SMITER.

All input parameters required by the SMITER workflow are easily visible and modifiable by the user in the interface. The GUI interface allows import of CAD objects, meshing or input of the meshes produced from the software NASTRAN, and input of the EQDSK files which describe the plasma equilibrium. The SMITER GUI consists of several pre-processing and post-processing modules with a central SMITER module that provides modelling of several SMITER cases in one study which is then saved as a HDF5 (Hierarchical Data Format) file. The study file contains all the data required to repeat previous cases (configuration, equilibrium, geometry and results). The CAD geometry set-up is integrated in one environment within the SMITER GUI interface which includes: visualisation, selection, modifications and meshing. The workflow shown in the Fig.1.4 is unified where the steps in the blue box (CAD geometry preparation and meshing) are integrated into one interface without the need of using external, proprietary meshing tools.

This documentation provides introduction of SMITER GUI, step-by-step instructions on how the SMITER GUI works and tutorials of the cases and studies. It is included as a help in HTML and PDF formats in the SMITER GUI framework. Furthermore, the code of the SMITER GUI component is documented for users and developers needing programmatic interface to the framework.

[Arter16]W. Arter et al., Power Deposition on Tokamak Plasma-Facing Components, IEEE Tr. Plasma Sc. 42(7), 2016(v2), p. 1932-1942, arXiv:1403.7142
[Fird13]M. Firdaouss et al., Modelling of power deposition on the JET ITER like wall using the code PFCFLux, J. Nucl. Mat. 438 (2013) S536-S539
[SALOME]Salome platform website http://salome-platform.org

1.1. Power Deposition Model

SMITER maps profiles of scrape-off layer (SOL) heat flux density flowing parallel to the magnetic fieldlines onto the plasma facing component (PFC) surfaces. Magnetic fieldlines on the flux surfaces within the magnetic equilibrium need to be followed in 3D space until they intersect a solid surface. The geometry is obtained from the provided CAD model of the structure converted to high precision triangular mesh. In practice, fieldlines are followed backwards from the surface in question, with proper mapping of the heat flux profile specified in the free SOL while taking into the consideration the magnetic flux expansion. This fieldline tracing must take into the account the neighbouring structures around the object of interest in order to ensure that the fieldlines are not intersected by other solid surfaces. Otherwise, the fieldline is shadowed resulting in zero heat flux at the place it started. The SMITER algorithms are programmed for two cases:

  1. limiter case
  2. divertor case

The geometry for both cases is separated into two types:

  1. the “result geometry” – the part where the power deposition is calculated,
  2. the “shadowing geometry” – the part which protects the edges of the “result geometry” by the fieldline shadowing.

The “shadowing geometry” covers the “result geometry”. That means that some fieldlines hit the shadow geometry before they can hit the target geometry. This results in no power deposition in that region of the target.

Magnetic equilibrium, usually desribed in text format files with .eqdsk extension, is defined as a simple model where input parameters besides equilibrium file are decay length and power loss. Decay length \(\lambda_{q||}\) (sometimes \(\lambda_{m}\)) is power decay length at outer midplane defined in \(mm\). Power loss \(P_{SOL}\) (sometimes \(P_{loss}\)) is total input power to the plasma crossing the separatrix and is defined in \(W\). In order to construct the radial profile of parallel power flux we need to impose 0D power balance at outer midplane.


Fig. 1.2 Outer midplane point. Black polyline represents wall mesh.

Heat flux at the PFC is calculated from

(1.1)\[q_{\parallel}(r)=q_{\parallel omp}\exp(-(r-r_{sep})/\lambda_q),\]

where \(q_{\parallel omp}\) is defined as

(1.2)\[q_{\parallel omp}=P_{SOL} / (4 \pi R_{omp}\lambda_q (B_{\theta}/B_{\Phi})_{omp})\]

Magnetic field line tracing gives the power flux anywhere else, accounting for flux tube distortion. Power deposition is then computed with an equation

(1.3)\[q_{\parallel PFC}=q_{\parallel}(r)R_{omp}/R_{PFC}\]

Note that specifications are always for a heat flux density parallel to magnetic field lines and are not perpendicular heat fluxes onto plasma facing components. Because of that we need to use full field line trace in order to obtain component heat flux by projection onto real surface. To do that use the following equation.

(1.4)\[q_\bot = q_\parallel \sin{\alpha}\]

Fig. 1.3 Flux tube of the magnetic field \(B\) connecting the torus midplane and surface.

The power deposition in SMITER is calculated using mathematical model with flux tubes. The basic idea is explained in Fig. 1.3, where the flux-tube connects the tokamak midplane with a physical surface of area \(A_1\). It is assumed from the figure that input power at midplane is traced through the flux-tube to the surface at the bottom and particles follow the fieldlines.

So the power at the top of the tube falls exponentially with radial distance at an empirically determined rate \(\lambda_m\) from the last closed flux surface (LCFS). The LCFS is given by \(\psi = \psi_m\) where \(\psi_m\) is the value of the poloidal flux where the geometry touches the plasma, or equal to \(\psi\) at the X-point in case of divertor plasmas. The power density \(Q\), deposited on the PFC is shown to vary as:

(1.5)\[Q = C_{std} \cdot \mathbf{B} \cdot \mathbf{n} \cdot \exp\left(-\frac{\psi - \psi_m}{\lambda_m R_m B_{pm}}\right),\]

where \(\psi\) is the flux function value for the tube at the midplane, \(B\) magnetic field, \(n\) the normal of surface \(A_1\), \(B_{pm}\) midplane poloidal component of the field, and \(R_m\) major radius.

1.2. Workflow

SMITER is usually installed in a directory ~/smiter under which also the GUI framework is built. The GUI interface is single study and multiple case interface that allows different workflows depending on the input provided and case study.

The SMITER framework is composed of several modules for pre- and post- processing. Pre-processing provides transformation of input CAD surfaces into meshes required by the main module SMITER that provisions calculation. Post-processing allows analysis of the results with ParaView visualisation module and exporting data to other formats.

The SMITER module consists of several codes that transform input data into expected format. The transformation can start with building up the CAD model or from meshes provided externally. The CAD model is built from curves and surfaces which are defined by the non uniform rational basis splines (NURBS). However, intersection of the NURBS surfaces are approximately represented by the NURBS. Approximation is needed in order to compute the parametric representation of non-parametric algebraic intersection curves. This approximation can result in small gaps between the surfaces. In order to avoid these small gaps, surfaces are represented by triangles, that is, the CAD geometry is meshed. Meshing of the CAD model can be done with a meshing module SMESH inside SMITER or externally, in this case with MSC Nastran.

Another input that SMITER requires for the calculation is the magnetic equilibrium file (EQDSK file). The GEOQ code is used to analyse the flux function usually defined in the EQDSK file. It produces contour plots of the flux gradients, overlay flux function contours with silhouette wall, and CAD geometry as \((R, Z)\) points.

The HDSGEN code computes the multi-octree hierarchical data structure (HDS), which is designed to accelerate the computation of track/ray-triangle intersection.

The POWCAL code performs the power surface deposition calculation, following the fieldlines using the transformed geometry from the GEOQ and the HDS from the HDSGEN.

The vacuum magnetic field is defined with the MAGTFM.

The complete workflow from the start to the end of calculation can be described as:

  1. Inputs
    • Magnetic equilibrium from simulation or experiment
    • CAD surfaces (STEP) or 3D triangular meshes (NASTRAN)
    • Heat flux profile
  2. Shadowing and heat flux calculations on 3D surfaces
    • Particles are following magnetic field lines
    • Shadowing by neighboring structures
  3. Outputs
    • Shadowing and wetted areas
    • Heat flux and incident angles
    • Thermal model (in development)

Fig. 1.4 SMITER workflow

Fig. 1.4 shows top-down data-flow through several SMITER GUI modules.

1.2.1. Input

Preparation of input data for SMITER consist of several pre-processing steps that are all handled in 3D space. Throughout these steps different coordinate systems are used due to their convenience for particular operation in space.

  1. The first step before calculating the power deposition is description of PFC geometry. This can be provided by many commercial and open-source Computer-Aided-Design (CAD) programs such as SMESH included in SMITER GUI. CAD data for the first wall geometry is usually provided in CATIA geometry database or portable STEP format. The geometry is described in cartesian coordinates (X, Y, Z) with dimensions in millimeters.

  1. The cylindrical coordinate system is used for description of magnetic fields and their parameters. Cylindrical polars form \(RZ\zeta\) space, where R and Z are in metres (m) and \(\zeta\) in radians.

  2. Toroidal polars in \(r\theta\zeta\) space where r is in metres and angles in radians (or in form \(r\theta\xi\)). Angle is measured from vertical through X-point.

  1. The flux mapped coordinate system is used for description of flux topology. Flux coordinates in \(\psi\theta\zeta\) space (or \(\psi\theta\xi\)). Angles are in radians and are measured from the vertical through X-point.


The SMITER codes have many configurable options and switches passed in at run time as (.ctl) control files that are actually standard FORTRAN namelist files used for changing code’s internal variables. The standard way to execute FORTRAN codes with configurable parametres is:

code .ctl file

e.g. geoq wall, where file wall.ctl contains inputs controlling geoq run.

The .ctl files contain Fortran namelists which must appear in a strict order although the variables within a namelist may be (re)defined in any order. Variables are documented using doxygen.

Example wall.ctl file input to geoq:



plot_geoqx = .true.,
plot_geoqvolx = .false.,


Namelist &inputfiles describes input files. Namelist &miscparameters can be used for future/expert use etc. Namelist &plotselections allows creation of different outputs (see index of outputs in Section 1.2.2). For namelist &beqparameters one should use doxygen documentation headed “Data Types List” in SMITER reference manual (index under “Data Fields” sub-heading).

Editing .ctl parameters for the code with GUI is possible with the “editor” included or by using dialog boxes when right-clicking on the code icon of the study. Details on use are described in Sec. Tutorials.

1.2.2. Output

All the codes produce a log file, which contains typically time-and-date stamps, information about the files used, a selection of key parameters, execution times and at end a summary of errors and warnings, terminating with “END OF LOG FILE”. Output to the terminal (Fortran print command) consists of the code header, errors associated with log-file writing and a small sub-set of the log-file output, notably serious errors, and the execution times if the code completes normally.

The suite is set up so as to terminate codes when a serious error occurs, other errors are classified as warnings, and execution continues. Most also produce a .out file, which is primarily used for inter-code communication, and also acts as a “lock-file”, in that the same .ctl file cannot be re-run until the corresponding .out file is deleted. (Good practice is to change the .ctl file-name if the contents change.)

Index of suffix strings of output files, either with terminating .vtk or graphics (.png, .ps) suffixes.

The .vtk files begin with the geometry definition, then the quantities in angled brackets, which are cell-centred rather than point quantities (unless stated otherwise) in case this is an option. J is the Jacobian of the mapping to flux coordinates (so R/J is the right-hand side of the ODE representing the fieldline), \(I = R B_T\) , Bcart is B in Cartesian coordinates, Msign is mask (0=shadowed) with the sign of B.n (where n is the surface normal), \(\psi_{start}\) is \(\psi\) at the nominal start of the fieldline (i.e. at the end which is NOT the PFC intersection). L=lenpath and objhit are taken from trackx file header line described below. Mapped geometry refers either to flux-mapped coordinates or cylindricals depending on the type of calculation.

<\((0,J,I) (point)\)> geoq output on volume flux-mapped geometry
<Bcart (point)> geoq output on volume Cartesian geometry
<surfaces> hdsgen output in quantised geometry
<XYZ \(\psi (point)\) Bcart (point) Normal Bcell> geoq output on Cartesian geometry
<points> hdsgen output in quantised geometry
<XYZ Bcart> geoq output on mapped geometry
<HDS> hdsgen output in mapped geometry
<HDS> hdsgen output in quantised geometry
<Q Msign \(\psi_{start}\) L objhit> _powx file augmented using addlenvtk
<Q Msign \(\psi_{start}\)> powcal output on mapped geometry
<Q-avg Q-dev> powcal output on mapped geometry (EXPERT)
<Q-avg Q-dev> powcal output on Cartesian geometry (EXPERT)
<Q Msign \(\psi_{start}\)> powcal output on Cartesian geometry
<points \(\psi\)> geoqgnu output in RZ geometry
<points \(\psi\)> geoqgnu output in flux-mapped geometry

The following files have no prefix, because unless stated, they are 2-D plots of flux-related quantities, and of course the fieldline tracks only depend on the geometry to the extent of their end-points, files:

<\(\psi\) silhouette> geoqgnu output in RZ geometry
<\(\partial \psi /\partial R\)> geoqgnu output in RZ geometry
<\(\partial \psi /\partial Z\)> geoqgnu output in RZ geometry
<\(R\)> geoqgnu output in flux-mapped geometry
<\(R/J\)> geoqgnu output in flux-mapped geometry
<\(\psi\)> geoqgnu output in RZ geometry showing flux-mapped region
<\(\psi\)> geoqgnu output in RZ geometry confined to flux-mapped region
trackm.*n* 01.vtk
<element \((n-1)\) fieldline> powcal output in mapped geometry
trackx.*n* 01.vtk
<element \((n-1)\) fieldline> powcal output in Cartesian geometry
<\(Z\)> geoqgnu output in flux-mapped geometry

In track files, the header line contains

i.e. 1+(identifier of triangular element line starts at)
length of fieldline track in file in mm (accurate in trackx files only)


>0 1+(element hit)

0 no collision, ODE integration limits reached

-1 track left computational domain

-2 track hit mid-plane

1.3. Description of Constituent Codes

Fig. Workflow indicates how the codes are combined to perform a shadowing calculation. Each of the codes is briefly described below. As described in the introduction, they are driven ultimately by namelists in .ctl files. The namelists expected in the respective .ctl files are listed below. Precise descriptions of the usage of the variables in each namelist may be referenced in the online documentation, as data types at smiter/doc/srcdoc/html/classes.html.

1.3.1. geoq code

The geoq code may be used to analyse the flux function \(\psi\) , usually defined in a .eqdsk file. (A good of effort has been exerted to ensure that SMITER can read the many variants of the EQDSK G “standard”.) To aid understanding, geoq produces as output .gnu files which may be plotted using the geoqgnu script (from the smiter/Extras directory). Running geoq makes it possible to

  • Produce contour plots of flux gradients ( \(\propto B\) components)
  • Overlay \(\psi\) contours with silhouette wall.vtk, and also CAD geometry as \((R,Z)\) points
  • Obtain the extrema of flux on geometry \(\psi_{ltr}\) , flux values from .eqdsk file \(\psi_{q}\) and the flux value at nearest X-point \(\psi_{X}\) as labelled output in the .log file. This output the user should inspect, and if necessary set up new input file with appropriate \(\psi_{m}\) . Sometimes it may be necessary to define a special search box to locate the correct X-point, by setting beq_xsearch=1 in namelist beqparameters. The .ctl file also controls whether inboard (HFS) or outboard (LFS) values of \(R\) and \(B\) are used in the power calculation (to account for the effects of flux expansion) via input beq_bdryopt in namelist beqparameters.

It is also possible to define the flux function analytically, if the the variable equil_input_file has a suffix .ana, this file must contain namelists as set out below. The suffix .equ is also recognised and corresponds to an output format related to that produced by the FIESTA code, see example the MAST-U test case Test-MNEW8-sha12-res12 .

Namelist order in .ctl as follows

  • inputfiles
  • miscparameters
  • plotselections
  • beqparameters

Namelist order in .ana as follows

  • equilparameters
  • meshparameters

1.3.2. hdsgen code

This computes the multi-octree HDS, which is designed to accelerate the computation of track/ray-triangle intersection. The user should not normally need to be concerned with details of hdsgen operation, except for the need to increase the parameter limit_geobj_in_bin for geometries with a large number of triangles, i.e. greater than approximately 100000 triangles, depending on their degree of clustering.

Namelist order in .ctl as follows

  • inputfiles
  • hdsgenparameters
  • btreeparameters
  • positionparameters
  • plotselections

1.3.3. powcal code

This is the code that actually performs the power surface deposition calculation, following fieldlines using transformed geometry from geoq and the HDS from hdsgen. There is the capability to select from a range of power deposition profiles, and even define new ones, provided by namelist edgprofparameters (see the documentation for namelist edgprofparameters). For global calculations, a wide range of fieldline termination criteria may be set using namelist termplaneparameters, including multiple simultaneous criteria, useful for private flux region calculations.

Partly to indicate that execution is continuing successfully, powcal outputs to the terminal, the numbers of elements for which the starting direction is uncertain, together with the values of B.n in the Cartesian co-ordinate system and in the mapped system which because of their different signs gave rise to the condition (these elements are regarded as shadowed). powcal local or “escape” calculations give rise to warnings in the .log file that “Object not found in binary tree”,one for each element that is thus regarded as illuminated or “wetted”.

powcal may also produce the track files described in SMITER output files if the right plotselections are made. The utility addlenvtk is provided to process connection length information, and append to the corresponding _powx.vtk file (the root of which must be specified), producing a file root_powlenx.vtk

Namelist order in .ctl as follows

  • inputfiles
  • miscparameters
  • plotselections
  • powcalparameters
  • (termplaneparameters if termination_planes=T)
  • (edgprofparameters if more_profiles=T)
  • odesparameters

1.3.4. magtfm code

Generally, in SMITER, the goal is to study field lines in axisymmetric magnetic field. For most cases, magnetic field is given in the form of equilibrium file with 2D data, that repeats itself on every step around the torus. The assumption of 3D field is different. In this case the magnetic field is represented as a 3D vector field, that contains magnetic field components in all three coordinate axes.

The purpose of taking into an account full 3D field is to study the effect of perturbations or anomalies of the magnetic field in the tokamak. Those perturbations could appear because of coil misalignment, deformation of the coil due to its mass, installation error of the coils, etc.

Full 3D field case inside SMITER was primarily designed for use on ITER tokamak geometry but can be easily extended to other tokamaks, as long as the input data follows a specified input format.

Namelist order in .ctl as follows

  • magfiles
  • plotselections
  • miscparameters

In this documentation, several studies on 3-D magnetic field are presented. These studies were performed in order to verify the accuracy of MAGTFM code.

  • First step: Create a uniform 3-D magnetic field and apply it to toroidal target of first wall panels (FWP) 4. The goal of this study was to verify the code by showing that for the axisymmetric 3-D magnetic field the result is the axisymmetric power deposition. One expects that the wetted area on every FWP 4 in toroidal direction should be the same.
  • Second step: Repeat the NF_55 benchmark case, but this time with 3-D magnetic field. First the study with axisymmetric magnetic case was prepared. One expects the same wetted area as per NF_55 benchmark case. Then the case was run with perturbed 3-D magnetic field. Results for both cases are presented here.
  • Third step: Use the full toroidal FWP 4 with circular plasma equilibrium. The goal was to again first use axisymmetric 3-D field and show that each panel has the same wetted area as one would expect. Then the perturbed 3-D magnetic field was studied. The differences in wetted area are presented here.
  • Fourth step: Take studies from step 3 and increase the helicity in order to magnify the differences in wetted areas. Both studies are presented in this chapter. SMITER 3D file format

Input file to SMITER with 3D magnetic field is defined in a .txt file and has the following format:

Zeta grid

R grid

Z grid

B(component:{x,y,z},zeta,r,z). Toroidal sector in negative y adjoining x=0.
Bx(R_1, Z_1, Zeta_1) By(R_1, Z_1, Zeta_1) Bz(R_1, Z_1, Zeta_1)
Bx(R_1, Z_1, Zeta_Nzeta) By(R_1, Z_1, Zeta_Nzeta) Bz(R_1, Z_1, Zeta_Nzeta)
Bx(R_2, Z_1, Zeta_1) By(R_2, Z_1, Zeta_1) Bz(R_2, Z_1, Zeta_1)
Bx(R_Nr, Z_1, Zeta_Nzeta) By(R_Nr, Z_1, Zeta_Nzeta) Bz(R_Nr, Z_1, Zeta_Nzeta)
Bx(R_1, Z_2, Zeta_1) By(R_1, Z_2, Zeta_1) Bz(R_1, Z_2, Zeta_1)
Bx(R_Nr, Z_Nz, Zeta_Nzeta) By(R_Nr, Z_Nz, Zeta_Nzeta) Bz(R_Nr, Z_Nz, Zeta_Nzeta)

The magnetic field is given in structured grid with equally spaced steps in each direction (\(\zeta, R, Z\)). First, one set of sample points is given as specified above. \(R\) and \(Z\) are specified in metres, while \(\zeta\) is specified in radians, one value per line. Magnetic field \(B\) is given in Cartesian components, one vector per line (\(Bx, By, Bz\)). Note that for SMITER input, the B vectors are ordered with \(\zeta\) varying the fastest, then \(R\) and finally \(Z\) varying the slowest. Each of the 4 items (\(\zeta\), \(R\), \(Z\) and \(B\) ) in the file is separated from the next by a blank line, each item starts with a description line, followed by the array size, except in the case of B.

The vacuum magnetic field is defined in a .txt file, in what will be referred to as mag format. Details of the required contents may be deduced by inspection of the example file ./smiter-aux/Data/Equilibrium/testov5.txt. Inputs and Outputs

The input parameters that correspond to 3D magnetic field case, are

  • data_layout: Parameter data_layout corresponds to the format of input file that contains 3D magnetic field components, given in .txt file. For working with full \(360^{\circ}\) ITER magnetic field, there are two main options that should be used in this case.
    • data_layout=14: Option 14 corresponds to magnetic field data, where the number of points in toroidal direction (\(\zeta\) direction) \(n_{\zeta}\) subtracted by 1 (\(n_{\zeta}-1\)) is a prime number. This is unfortunate because of the existing Fourier transform algorithm then equires an expensime matrix multiply, that is possibly also subject to significant rounding error.
    • data_layout=12: This option corresponds to the magnetic field data where the number of points in toroidal direction (\(\zeta\) direction) \(n_{\zeta}\) subtracted by 1 (\(n_{\zeta}-1\)) is not a prime number. If possible, this option should be used instead of option 14.
  • zeta_start: Toroidal angle \(\zeta_{start}\) of first point in samples (degrees). This is the angle of the beginning of the first point in the first segment, in case of ENERGOPUL data this parameter should be set to \(-10^{\circ}\).
  • plot_bcartx: Plot option that creates 3D vtk plot of magnetic field components B. The magnetic field can be thus visualized in Paraview.
  • i_requested: This number is the product of toroidel magnetic field \(B_T\) at the nominal radial position \(R\), i.e. i_requested= \(B_TR\).
  • mode_cutoff: Relative mode cut-off amplitude, default \(.0001\).

1.4. Graphical User Interface

The SMITER graphical user iterface (GUI) uses several modules (or components) that are used independently and interoperable in the workflow. Only one module is activated at one time. Modules create data that is usually stored into study that is saved into HDF file for reuse.


Fig. 1.5 Main window of SMITER GUI.

We can use newstudy_icon icon to create a new case. To save the study use savestudy_icon icon that will write HDF file containing all data.

Initial SALOME window window contains the following important icons:

Initial SALOME window  
newstudy_icon New case Starts New case in Salome.
savestudy_icon Save study Saves current study.
runsmiter_icon Open SMITER module Opens SMITER module in SALOME.
mesh_module_icon Open Mesh Module Opens Mesh Module in SALOME.
geometry_module_icon Open Geometry Module Opens Geometry Module in SALOME.
open_icon Open Study Opens study.

Main SMITER GUI modules are:

Smiter module

With a click on runsmiter_icon we activate Smiter module. If a study has not been created yet, the message box menu will appear. In this case we can click New button to start the a new case or Open button to open the existing case.

Actions are available through icons shown in the toolbar, by right-clicking on the study tree depending on the context, or through menu as shown in the following figure.


Some of actions available are listed in the table below.

SMITER Module icons Function
wallmesh_icon Create Wall Mesh Adds ITER wall mesh to Mesh Module. Wall is hard-coded to SMITER module and can be used as a reference in displaying results.
mesh_icon NASTRAN to MESH Converts NASTRAN file to Salome mesh.
patran_to_smesh NASTRAN to MESH Converts PATRAN file to Salome mesh.
smesh_to_patran SMESH to PATRAN Converts Salome mesh to PATRAN file.
newcase_icon New Case Creates new SMITER case.
verifycase_icon Verify case Verifies the setup of SMITER case.
loadctlcase_icon Load CTL file parameters case to SMITER case Load CTL file parameters into SMITER case components
singleexeprofile_icon Custom single exe profile Dialog to prepare a custom single exp power deposition profile
plotfieldlines_icon Calculate fieldlines by selecting … Calculate fieldlines by selecting triangles in ParaViS and a SMITER case
ior_icon Get Salome object IOR Displays Interoperable Object Reference (IOR) value of selected Object in Object Browser.
ior_paraview_icon Show object in Paraview Displays IOR value of selected GEOM or SMESH object in Object Browser and ParaVieW.
smesh_to_ids Write SMESH mesh to IDS Read SMESH mesh data and writes it to IMAS ids.
eqdsk_to_ids Write EQDSK G to IDS Write the contents of EQDSK G file and store it to IMAS ids.
ids_to_smesh Read mesh data from IDS Reads mesh data from IMAS ids and imports it into SMESH
ids_to_eqdsk Read EQDSK data from IDS Reads eqdsk data from IMAS ids and writes it on a file you specify.

1.4.1. Case actions

These actions allow user to prepare, modify and run SMITER cases.

newcase_icon New Case Creates new SMITER case.

This opens a dialog in which the user creates a SMITER case. In the dialog the user specifies the following parameters:

  • name

    The name of the case

  • decay length

    specified in meters

  • power loss

    specified in MW

  • Wall mesh (optional)

    a 2D polyline silhouette mesh from which the reference flux on the silhouette (flux value on the LCFS)

  • Target mesh

    a triangle mesh on which the power deposition is calculated

  • Shadow mesh

    a triangle mesh that causes shadowing

  • EQDSK file

    an EQDSK G file describing the equilibrium

  • MAG file (optional)

    3D magnetic field in magtfm format


Only the meshes that are inside the SMESH module can be selected.

verifycase_icon Verify case Verifies the setup of SMITER case.

This opens a dialog in which you select a Smiter case and verify that the mesh entries (SALOME object entry) is not pointing to an empty object.

The following scenario explains this. Each object in the SALOME object browser has a unique entry, i.e. “0:1:1”. This entry holds the position of the object in the object browser. Whenever you delete a SALOME object, it is no more visible in the SALOME object browser, BUT a null or empty object still exist with the unique entry. Since the names of the SALOME objects are not unique, the entries are used for actual position of the objects and therefore the underlying data (geometry, mesh, other,…).

Now we create a Smiter case and select a mesh as our target mesh, but find out that we need to change it (resolution, shape, ..) which means delete the old one and produce a new one with the same name. In the Smiter case we will still have the same name for the target mesh, and since the name hasn’t changed it should know how to pick the right mesh. But the actual position of the mesh is stored in the entries and the name only serves for easier recognition. So while the name of the mesh is the same, it’s entry, the unique ID, has been changed. In this case if we’d compute the Smiter case, it would fail.

We can verify the case to see if the mesh are not pointing to an empty object, or also check the checkbox to automatically change the entries to same named mesh objects.

loadctlcase_icon Load CTL file parameters case to Smiter case component Load CTL file parameters into Smiter case components

This opens a dialog in which you select a component of the Smiter case from the SALOME object browser and a CTL file on the filesystem, after which the contents of the CTL, i.e., parameters are loaded into the component.

This utility eases the loading of parameters of a CTL file to a Smiter component. Each parameter is also checked if it belongs to the component, so nothing will happen if the wrong CTL is loaded to a Smiter case component.

singleexeprofile_icon Custom single exe profile Dialog to prepare a custom single exp power deposition profile

This action opens a dialog, where the user can set a custom single exponential, by setting the \(Q_0\), \(\lambda\) and ranges for the profile. To apply the profile to a SMITER case, a SMITER case must be highlighted (or clicked). It is mandatory that the target GEOQ has been computed so that the necessary values are read from it’s output for the normalization factor.

The user can plot both profiles to see how it will look like and to apply the profile to the case click the Apply profile to POWCAL while a SMITER case is selected.

plotfieldlines_icon Calculate fieldlines by selecting … Calculate fieldlines by selecting triangles in ParaViS and a Smiter case

This action requires that you first select a Smiter case and from an already precomputed POWCAL VTK result, select the triangles for which you would like to see the fieldlines.


Afterwards click on the Calculate fieldlines… button. This will generate trackx*.vtk files in the run directory. When opened in ParaViS you will have fieldlines for those selected triangles.


Under Smiter -> Case we can access all case actions that are in the Smiter toolbar and other actions that are normally executed by right clicking on Smiter objects in the SALOME object browser.

Find LCFS with interpolations Find the LCFS by selecting Smiter EQDSK, object, specifying flux value

This action opens a dialog in which you select a Smiter EQDSK object from the SALOME object browser, specify a flux value and then with the use of bilinear interpolation the LCFS curve is found and plotted.

editctl_icon Edit CTL Edit the parameters of GEOQ, HDSGEN MAGTFM and POWCAL objects
compute_icon Compute case Run a Smiter case
renamecase_icon Rename case Rename a Smiter case
deletecase_icon Delete case Delete a Smiter case
duplicate_icon Duplicate case Duplicate a Smiter case
replacemesh_icon Replace mesh Replace mesh in a GEOQ object
replaceeqdsk_icon Replace EQDSK Replace EQDSK in a EQDSK object
Plot plasma and limiter geometry Plot LCFS from EQDSK object

These are standard actions for modifying a case.

Prepare case for running in batch Prepares a case for running in batch

This action packages the case by archiving the input files and a script for running the case in non-GUI mode. This can be used to prepare the case to be run on a HPC by remote submit or just for preparing a case to be used in non-GUI mode via terminal.

Plot gnuplot files Plot output gnuplot files of a Smiter case

There are output gnuplot files when you run a case and this utility helps you plot them inside SMITER. This opens a dialog in which you select a Smiter case, then browse the Smiter case run directory and select which gnuplot files to plot.

GEOM/SMESH from GEOQ eqdsk gnuplot files Extract the LCFS from the GEOQ eqdsk gnuplot file and export it to GEOM/SMESH

GEOQ has a switch called plot_eqdsk_boundary. This produces a gnuplot file containing the R and Z points of the LCFS. This action imports these values to SMESH and GEOM.

1.4.2. Mesh actions

Different mesh operations that are needed to run the field line case are included into Smiter.

wallmesh_icon Create Wall Mesh Adds ITER wall mesh to Mesh Module. Wall is hard-coded to Smiter module and can be used as a reference in displaying results.

This opens a dialog in which you can select the following silhouettes:

  • c_3NHXN_v3_15
  • nf_55_033019
  • smiterauxWallmesh

and produce SMESH mesh and optionally GEOM geometries. These silhouettes describe the curve of the tokamak reactor and are used to calculate the reference LCFS flux value on it. They are not necessary to have in a Smiter case, if you already know the LCFS flux value, which can be set in target and shadow GEOQ components, under beq_psiref.

mesh_icon NASTRAN to MESH Converts NASTRAN file to Salome mesh.
patran_to_smesh PATRAN to MESH Converts PATRAN file to Salome mesh.

These actions serve to either convert NASTRAN/PATRAN mesh files to SMESH mesh objects.

smesh_to_patran SMESH to PATRAN Converts Salome mesh to PATRAN file.

This action is used to convert a SMESH mesh object to PATRAN file.

1.4.3. CORBA actions

SALOME architecture is based on Common Object Request Broker Architecture technology using distributed system model of applications. SALOME combines several software components, which are built in such a way that it allows to integrate solvers and existing meshing algorithms along with the specification of physical properties for a given domain. These actions are needed if user wishes to transfer information between different components.

ior_icon Get Salome object Interoperable Object Reference (IOR) Displays Interoperable Object Reference (IOR) value of selected Object in Object Browser.

This action displays the Interoperable Object Reference (IOR) value of the selected object in the Object browser.

ior_paraview_icon Show object in Paraview Displays IOR value of selected GEOM or SMESH object in Object Browser and ParaVieW.

This action displays the IOR value and exports a GEOM or SMESH object into ParaViS.

1.4.4. IMAS actions

These actions can save and load different data to and from IMAS.

smesh_to_ids Write SMESH mesh to IDS Read SMESH mesh data and writes IMAS ids.

This opens a dialog in which you select SMESH mesh objects from the SALOME object browser, specify the IDS parameters, which then writes those SMESH objects to the IDS.

ids_to_smesh Read mesh data from IDS Reads mesh data from IMAS ids and imports it into SMESH

This opens a dialog in which you specify the IDS parameters, from which meshes are read and stored to SMESH.

eqdsk_to_ids Write EQDSK G to IDS Write the contents of EQDSK G file to IMAS ids.
imas_write_eqdsk_ids Read G EQDSK from IDS Reads G EQDSK from IMAS ids and saves it to a file

Similar functionality as the before mentioned actions, this one writes/reads G EQDSK files to/from IMAS IDS.


1.4.5. VTK actions

These are utility actions for data transform from VTK format to X format.

vtk_to_matlab_icon Convert VTK to MATLAB Converts data in vtk format to MATLAB format

With this dialog you select a VTK file and afterwards select which array or vector quantities to write in a MATLAB format file.


Geometry module

GEOM module is capable of many different functionalities for creation, visualization and modification of geometric CAD models. It can read CAD files in many different formats, including STEP and IGES. It enables us to create geometrical and topological objects with different modelling operations.

Mesh module

This module is used to create meshes on the basis of geometrical models created or imported into GEOM. It uses a set of meshing algorithms and their corresponding conditions (hypotheses) to compute meshes. Main functionalities are computation of meshes based on different hypotheses and algorithms, group management of meshes and mesh modifications. This module also provides information and quality control functions of computed meshes and importer/exporter od different mesh format files.


ParaViS is a data analysis and visualization application that embeds ParaView tool inside SMITER GUI. ParaVis is a post-processing tool used to analyze data using qualitative and quantitative techniques. The data exploration can be done interactively in 3D or programmatically using ParaView’s batch processing capabilities.

1.4.6. Preferences

SMITER has several preferences that can be set after module is activated. With File ‣ Preferences ‣ Smiter the following sections can be set or are enforced or suggested by environment variables:

Path settings

Smiter directory points to SMARDDA exec/ subdirectory. It can be enforced by SMITER_DIRECTORY by environment module, user or AppImage.

Smiter extracts meshes from the study and creates them under Compute directory/case name/ subdirectory and arranges them along with control files and input files under eqdsk/, shadow/, target/, hds/, and power/ subdirectories therein. Compute directory shoud reside on a node-shared directory (e.g. $SCRATCH/smiter-compute) if computing on cluster is used. The content of this directory can be always removed as it is used for computaion only. The directory can be set externally by SMITER_COMPUTE_DIRECTORY environment variable.

MPI options

Only power calculation with powcal is run in parallel with MPI. Some speedup can be achieved by running combined executable smiter that overcomes output to input passing by MPI broadcast from geoq and hdsgen to powcal.

If Use MPI is checked then MPI parallelisation is used locally on a workstation or through batch queue (e.g. SLURM, LSF, PBS). If Use MPI is not selected then MPI run command is not used at all and SMARDDA codes are run serially on a local machine. Running serially with batch submission is still possible with Use MPI and specifying single core or empty MPI run command.

Disable combined smiter executable may be selected in rare cases where one wants to compare results obtained by without combined executable. Combined smiter executable lowers number of batch submissions necessary to one with the exception of optional wall or magtfm pre-computation.

Submit through: Execute <MPI run command> without a shell is most commonly used as usually for interatcive submission there is no need to add additional shell in between MPI run command. If there are some input/output file errors observed, then one may try to run through one of the shells. There is also SMITER_MPI_SHELL_TYPE that defaults to 0 and can be used to enforce externally index of the shell available in the drop down box.

MPI run command is used to run SMARDDA in various cluster configurations. Some of MPI run command examples are available under drop down box. However, only the MPI run command is used for starting each code in interactive way. Meaning that MPI run command should not use batch submission commands (e.g. sbatch) but rather those that return prompt when job completes (e.g. srun). System administrators or AppImage may additionally add further default example to the top of the drop down box by setting SMITER_MPI_DEFAULT_COMMAND variable. User may also export once such variable to appear permanently on this drop down box list. Therefore, this list can be populated externally only and saved in users’ preferences. To clean the list to default one, the easies way is to erase preferences with rm -rf ~/.config/salome.


There is no mechanism to enforce MPI run command and is up to the user to select and adjust it appropriately regarding the number of cores, partition, wall time,… Top on the list is what it may be advised to start with. Other settings

Due to possible differences in shared libraries used by SALOME and LD_LIBRARY_PATH enforced external browser launched for Help may need clean library path. For that File ‣ Preferences ‣ Salome->General->External browser->Application is set to env --unset LD_LIBRARY_PATH /usr/bin/firefox.

Another useful setting is File ‣ Preferences ‣ Salome -> Directories ‣ Quick directory list’ that are listed left when using :menuselection:`File ‣ Open or File ‣ Save. Users may wish to add $HOME/Documents/smiter or similar to this list for their daily use. Adding to this list externally is possible with SMITER_STUDY_EXAMPLES_DIR, where you may find also read-only study examples provided by the system installations.