☞ pdf

Conventions

cocos_identifier • coordinate_identifier • coredelta_identifier • coreneutral_identifier • coresource_identifier • coretransp_identifier • distsource_identifier • fast_particle_origin_identifier • fast_thermal_filter_identifier • fokker_planck_source_identifier • pellet_shape_identifier • species_reference_identifier • wall_identifier • wave_identifier • Example: How to fill coresource/values/sourceid

Grid Types in Equilibrium CPO

Grid Type Identifier • Poloidal Angle Identifier

Standardized EU-ITM Plasma Bundle

Standard Machine Names

Top • Previous • Next

The following machine names are suggested:

aug
ftu
iter
jet
mast
tcv
tore_supra
west

Physics Conventions

Top • Previous • Next

The ITM-TF has agreed on a variety of conventions to facilitate the integration of the code modules across EFDA.
In the following the most important conventions are explained in detail to remove confusion and avoid ambiguity. For more physical detail than that represented here see F Hinton and R Hazeltine, Rev Mod Phys48 (1976) 239-308, or R Hazeltine and J Meiss, Plasma Confinement (Addison-Wesley, 1992).

Coordinate System

Top • Previous • Next

There are generally two choices for defining a right-handed coordinate system in a toroidal geometry with the following coordinates:

major radius R
vertical heights Z
toroidal angle $\text{[math]}$

Remaining consistent with ITER, the ITM-TF has chosen to adopt the right-handed system

$\text{[math]}$

i.e. R is to the right, Z is upwards, and $\text{[math]}$ points into the plane on the right-hand side of the torus (i.e. mathematically positive). Looking from above, the toroidal angle is counter-clockwise, i.e. mathematically positive.

The following figures demonstrate the orientation of the toroidal angle $\text{[math]}$ and the poloidal angle $\text{[math]}$ :

source:
http://www-fusion.ciemat.es/fusionwiki/index.php/Toroidal_coordinates
http://en.wikipedia.org/wiki/Toroidal_and_poloidal

Representation of the Magnetic Field and Current

Top • Previous • Next

Generally, the magnetic field is described in terms of two scalar fields as it is divergence free. If the field is also axisymmetric then MHD equilibrium demands these are functions of each other. In the ITM-TF the relevant quantities are $\text{[math]}$ and $\text{[math]}$ and the representation is

$\text{[math]}$

where the factor of $\text{[math]}$ is to have $\text{[math]}$ one and the same with the poloidal flux in Webers (see below).

The current given by Ampere's law is

$\text{[math]}$

The respective covariant toroidal components are useful forms:

$\text{[math]}$

where the latter is often expressed in terms of the "delta-star" operator, $\text{[math]}$ .
These are not the toroidal field and current but the toroidal field and current multiplied by $\text{[math]}$ respectively. The total plasma current $\text{[math]}$ is the integral of $\text{[math]}$ over the poloidal cross section (usually, but not always, over the closed flux surface region only).

Poloidal and Toroidal Fluxes

Top • Previous • Next

The toroidal flux $\text{[math]}$ is the integral of $\text{[math]}$ over the region enclosed by the flux surface. Due to axisymmetry it is also a volume integral

$\text{[math]}$

All volume integrals are understood as integration over the region enclosed by the flux surface. They are therefore flux quantities (pure functions of $\text{[math]}$ ). The units of $\text{[math]}$ are volt-seconds, or Webers (Wb).

The poloidal flux is $\text{[math]}$ due to the construction of $\text{[math]}$ . The factor of $\text{[math]}$ ensures this is not Wb per radian (the more usual quantity $\text{[math]}$ used as a covariant toroidal component of the magnetic potential is in Wb/radian; the factor of $\text{[math]}$ results from integration over one angular circuit). Note that the poloidal flux $\text{[math]}$ and its equivalent per radian $\text{[math]}$ are often used equivalently in the literature.

Safety Factor

Top • Previous • Next

The magnetic pitch parameter is defined in terms of the flux components:

$\text{[math]}$

which is a flux quantity. This definition is the same as saying the magnetic pitch is given as the number of toroidal cycle a magnetic field line traverses per unit poloidal cycle. It is also called the local safety factor for MHD stability reasons (here, "local" means local to a given flux surface). Equivalent relations often seen depend on the definition of coordinates. These are given for straight field line coordinates, below.

Signs

Top • Previous • Next

With the above definition of the toroidal coordinate system and the magnetic field, the following sign relationships ensue (where increasing and decreasing refer to going from the magnetic axis to the separatrix on the outboard midplane):

Sign Relations
$\text{[math]}$	$\text{[math]}$	$\text{[math]}$	$\text{[math]}$	safety factor $\text{[math]}$
positive	positive	decreasing	increasing	negative
positive	negative	increasing	increasing	positive
negative	positive	decreasing	decreasing	positive
negative	negative	increasing	decreasing	negative

COCOS - toroidal coordinate conventions

Top • Previous • Next

16 different fundamental coordinate conventions (COCOS) has been identified for toroidal systems. These are described by O. Sauter and S. Yu. Medvedev, Computer Phys. Commun. 184 (2013) 293, and summarized in the figure below.

The current ITM convention (described above) is number 13, while the ITER convention is 11.

Determining the COCOS number

Top • Previous • Next

Equilibrium COCOS transformation library and actor

Top • Previous • Next

A Fortran library has been developed for transforming the equilibrium cpo between different COCOS. The source is found in

https://gforge6.eufus.eu/svn/numerical_tools/tags/COCOStransform_v1_1

and the actor is

https://gforge6.eufus.eu/svn/kepleractors/tags/4.09a/imp12/COCOStransformequil.tar

(also available from: ~sauter/public/ACTORS/4.09a)

Inputs:

Equilibrium_in: input cpo
COCOS_in: COCOS of the input equilibrium (if the COCOS is not stored in Equilibrium_in)
COCOS_out: Requested COCOS for the Equilibrium_out
Ipsign_out: Requested sign for output Ip; -9 if just wants IP_in transformed to new equilibrium, +1 or -1 if a specific sign in output is desired
B0sign_out: Requested sign for output B0

Output:

Equilibrium_out: Output cpo

The Flux Surface Average

Top • Previous • Next

In general, the flux surface average is the operation which annihilates the magnetic derivative $\text{[math]}$ and acts as an identity operator on any flux quantity. It can be proved that this results in a volume derivative of a volume integral (alternatively one starts with the latter property and then proves the former, as the above Ciemat reference does).
The flux surface average of a scalar and divergence of a vector are given by

$\text{[math]}$

where $\text{[math]}$ is the contravariant volume component of the vector $\text{[math]}$ .
It follows that the flux surface average is an angle average weighted by the volume element $\text{[math]}$

$\text{[math]}$

for any choice of toroidal and poloidal angle as well as radial coordinates, where $\text{[math]}$ is the determinant of the covariant metric tensor components in those coordinates.
Note in general $\text{[math]}$ is not an axisymmetric quantity so the integration is actually over both angles.

For more detail see the above references.

The Toroidal Flux Radius as the Radial Coordinate

Top • Previous • Next

The ITM-TF has decided to use the toroidal flux radius $\text{[math]}$ defined by

$\text{[math]}$

where $\text{[math]}$ is the reference (vacuum) magnetic field value. Note that $\text{[math]}$ is a positive quantity which has units of meters.
For several applications the volume radius $\text{[math]}$ is also used. It is a normalised radius going from 0 to 1 and is defined as

$\text{[math]}$

where LCFS refers to the last closed flux surface.
Both should be defined in the equilibrium CPO (as well as $\text{[math]}$ itself).

Toroidal and Parallel Current

Top • Previous • Next

These are not equivalent, despite the often-seen experimental practice of considering them so. The toroidal current given in Amperes depends on some convention applied to $\text{[math]}$ given above, which is not a flux quantity. The ITM-TF has decided on this definition of the toroidal current as a flux quantity:

$\text{[math]}$

This uses the contravariant toroidal component of $\text{[math]}$ which is a pure divergence

$\text{[math]}$

Hence the flux surface average invokes the often-used quantity $\text{[math]}$ in the form

$\text{[math]}$

Here, $\text{[math]}$ explicitly using the toroidal flux radius as the radial coordinate.

The parallel current is different from this due to the finiteness of the poloidal current and magnetic field. Generally the correction is $\text{[math]}$ which is usually a few percent (but not in a spherical tokamak). Using the representations for $\text{[math]}$ and $\text{[math]}$ given above we find

$\text{[math]}$

Since $\text{[math]}$ is a flux quantity the flux surface average behaves as for $\text{[math]}$ and we use a factor of $\text{[math]}$ to provide the correct units, yielding

$\text{[math]}$

This form has been chosen due to the natural use of the flux surface average $\text{[math]}$ in neoclassical theory and the magnetic flux diffusion equation (see the Hinton and Hazeltine reference above).

Straight Field Line Coordinates

Top • Previous • Next

A variety of modules in the ITM-TF use straight field line coordinate systems to represent the closed flux surface region.
To guarantee consistency with the definition of the poloidal flux and the magnetic field representation given above, a standard definition of the coordinate volume element follows. This is the same sense as the usage of the term "Jacobian" in the CPOs (note many papers use the inverse volume element as the "Jacobian" by contrast).
Here, "straight field line coordinates" refers to the use of the right-handed coordinate system $\text{[math]}$ with the poloidal flux $\text{[math]}$ , the straight field line angle $\text{[math]}$ , and the toroidal angle $\text{[math]}$ . Therefore, $\text{[math]}$ has the same orientation as the poloidal angle $\text{[math]}$ in toroidal coordinates, while the toroidal angle $\text{[math]}$ is in the opposite direction of $\text{[math]}$ . This is standard usage generally in terms of "flux coordinates" (see Hazeltine and Meiss, above).

Note here that while the toroidal angle is the geometric one in the orientation sense of flux coordinates, the poloidal angle is not geometric. This results from the demand that the field lines be straight in the coordinate plane $\text{[math]}$ . The definition of this property is given by the specification of the ratio of contravariant components of the magnetic field as a flux quantity, which is one and the same with the pitch parameter ("local safety factor"):

$\text{[math]}$

where the minus sign appears by consistency with the primary definition in terms of the flux components as given above. This represents a magnetic differential equation for the poloidal angle:

$\text{[math]}$

Due to the choice of "natural" coordinates (with $\text{[math]}$ , not $\text{[math]}$ ) this relation is close to the definition of the volume element $\text{[math]}$ and, equivalently, the Jacobian $\text{[math]}$

$\text{[math]}$

Note the ordering of $\text{[math]}$ and $\text{[math]}$ .
The components of the magnetic field are then

$\text{[math]}$
$\text{[math]}$
$\text{[math]}$

With these relations the following relationship between the Jacobian and pitch parameter ("local safety factor") holds

$\text{[math]}$

This is the quantity labelled $\text{[math]}$ in the equilibrium CPO.

Plasma Betas

Top • Previous • Next

Out of the many definitions of plasma betas, the ITM has agreed to adhere to the following definitions:

Following Wesson (p. 116), the poloidal beta is defined as an integral over the poloidal cross section

$\text{[math]}$

where $\text{[math]}$ is the poloidal cross section enclosed by the flux surface $\text{[math]}$ , $\text{[math]}$ is the flux surface averaged poloidal magnetic field, $\text{[math]}$ the toroidal plasma current inside the flux surface $\text{[math]}$ and $\text{[math]}$ the length of the poloidal perimeter of flux surface $\text{[math]}$ .
This definition yields a one-dimensional profile $\text{[math]}$ stored in profiles_1d%beta_pol in the equilibrium CPO . The overall poloidal beta $\text{[math]}$ is stored in global_param%beta_pol.

The toroidal beta is defined as

$\text{[math]}$

with $\text{[math]}$ the vacuum magnetic field as stored in global_param%toroid_field%b0. The integral is carried out over the entire plasma volume and the result stored in global_param%beta_tor.

The normalized plasma beta is defined as

$\text{[math]}$

with $\text{[math]}$ the total plasma current (following Y.-S. Na et al., PPCF44 (2002), 1285) and a is the minor radius. It is stored in global_param%beta_normal.

Internal Inductance

Top • Previous • Next

The definition of the internal inductance follows J.A. Romero et al., NF50 (2010), 115002. The magnetic energy contained inside the flux surface $\text{[math]}$ is
$\text{[math]}$
where $\text{[math]}$ is the poloidal component of the magnetic field.
The (unnormalized) internal inductance is then defined as
$\text{[math]}$
where $\text{[math]}$ is the toroidal plasma current enclosed by the flux surface $\text{[math]}$ .
The normalized internal inductance, as stored in profiles_1d%li is defined as

$\text{[math]}$

with the surface averaged major radius
$\text{[math]}$ .
The overall internal inductance $\text{[math]}$ is stored in global_param%li.

Poloidal Angle Dimension in Equilibrium CPO

Top • Previous • Next

The following entries in the equilibrium CPO are defined along the poloidal dimension (as dim2 in the case of a flux surface equilibrium, i.e. radial coordinate psi in dim1 and poloidal angle in dim2):

coord_sys%jacobian(:,:)
coord_sys%g_11(:,:)
coord_sys%g_12(:,:)
coord_sys%g_13(:,:)
coord_sys%g_22(:,:)
coord_sys%g_23(:,:)
coord_sys%g_33(:,:)
profiles_2d%position
profiles_2d%grid
profiles_2d%psi_grid(:,:)
profiles_2d%jphi_grid(:,:)
profiles_2d%jpar_grid(:,:)
profiles_2d%br(:,:)
profiles_2d%bz(:,:)
profiles_2d%bphi(:,:)

The ITM-TF has decided not to repeat the first poloidal point (with poloidal angle $\text{[math]}$ ), which is identical to $\text{[math]}$ . This option was chosen to facilitate Fourier transforms along the poloidal direction. To that purpose it is required that the dimension dim2 be equidistant in the poloidal angle $\text{[math]}$ (going from $\text{[math]}$ to $\text{[math]}$ where ndim2 is the number of poloidal grid points), whatever the choice of this angle is.

Numerical and computational conventions

Top • Previous • Next

Standardized Variable Types

Top • Previous • Next

To ensure that physics modules produce identical results on various computer architectures and to avoid issues with double precision versus single precision interfaces, the ITM-TF has agreed on a set of standardized variable types.
It is recommended that these types be used throughout all ITM modules, but at least for the interface definitions.
The Fortran90 module defining the type standards itm_types.f90 is hosted by the project itmshared.
To check out the relevant files please do

svn checkout https://gforge6.eufus.eu/svn/itmshared/trunk/src/itm_types target_dir

For Fortran90, the following standard types have been defined

INTEGER,  PARAMETER :: ITM_I1 = SELECTED_INT_KIND (2)        ! Integer*1
INTEGER,  PARAMETER :: ITM_I2 = SELECTED_INT_KIND (4)        ! Integer*2
INTEGER,  PARAMETER :: ITM_I4 = SELECTED_INT_KIND (9)        ! Integer*4
INTEGER,  PARAMETER :: ITM_I8 = SELECTED_INT_KIND (18)       ! Integer*8
INTEGER,  PARAMETER :: R4 = SELECTED_REAL_KIND (6, 37)   ! Real*4
INTEGER,  PARAMETER :: R8 = SELECTED_REAL_KIND (15, 300) ! Real*8

To implement these types in your code, please add the following line to your modules

use itm_types

Compiled versions of the module can be found in

$ITMLIBDIR/itmtypes/lib/$OBJECTCODE

where the following values of OBJECTCODE are supported

amd64_g95_0.92 
amd64_gfortran_4.7 
amd64_intel_12 
amd64_pgi_10

(More information about the ITM libraries.)

Standardized Physical Constants

Top • Previous • Next

To avoid discrepancies in simulations from using different definitions of the physical constants, the ITM-TF has agreed upon a set of standardized physical constants (all in SI units except for temperatures) based on the NIST recommendations.
It is recommended that these constant be used throughout all ITM modules.
The Fortran90 module defining the standardized physical constants itm_constants.f90 is hosted by the project itmshared.
To check out the relevant files please do

svn checkout https://gforge6.eufus.eu/svn/itmshared/trunk/src/itm_constants target_dir

Compiled versions of the module can be found in

$ITMLIBDIR/itmconstants/lib/$OBJECTCODE

where the following values of OBJECTCODE are supported

amd64_g95_0.92 
amd64_gfortran_4.7 
amd64_intel_12 
amd64_pgi_10

The C equivalent ("itm_constants.h") can be found in

$ITMLIBDIR/itmconstants/include/

and the Python in

$ITMLIBDIR/itmconstants/lib/python2.6/

A Java version is available but has not yet been released --- contact ISIP if you are interested.
(More information about the ITM libraries.)
The following constants are available:
itm_constants.xml
All constants are double precision floats (R8).

Invalid Data Base Entries

Top • Previous • Next

The ITM data base does not allow for setting data base entries directly to invalid in case they should not be set.
Since the Universal Access Layer (UAL) always pulls out complete CPOs, i.e. complete data structures, of which not all fields may be filled, the problem arose of how to identify those fields which have not been filled.
In the case of arrays, this is simply done by not associating the corresponding pointer.
In the case of scalars, however, unique values for floats and integers had to be defined to identify empty fields. These values identify invalid data base entries and can be tested through comparison.
The values for invalid data base entries in Fortran90 are defined below:

INTEGER,  PARAMETER :: itm_int_invalid = -999999999
REAL(R8), PARAMETER :: itm_r8_invalid = -9.0D40

They have been found to be safely out of any physical range for the affected fields such that no accidental confusion with real values may occur.

The Fortran90 module defining these values itm_types.f90 is hosted by the project itmshared.
To check out the relevant files please do

svn checkout https://gforge6.eufus.eu/svn/itmshared/trunk/src/itm_types target_dir

The module also includes three functions of type boolean itm_is_valid_int4, itm_is_valid_int8, and itm_is_valid_real8 which are overloaded under the interface itm_is_valid to check whether a data base entry has been filled.

Example:

if (itm_is_valid(equilibrium%global_param%i_plasma)) then
  write(*, *) 'Plasma current Ip = ', equilibrium%global_param%i_plasma
end if

Enumerated datatypes/Identifiers

Top • Previous • Next

This section concerns how to specify the origin of data in certain types of CPOs. The specification is performed using the datatype identifier. The following specifies the conventions of the allowed enumerated datatypes.

Compiled versions of the modules can be found in

$ITMLIBDIR/itmconstants/lib/$OBJECTCODE

where the following values of OBJECTCODE are supported

amd64_g95_0.92 
amd64_gfortran_4.7 
amd64_intel_12 
amd64_pgi_10

The C equivalent can be found in

$ITMLIBDIR/itmconstants/include/

and the Python in

$ITMLIBDIR/itmconstants/lib/python2.6/

A Java version is available but has not yet been released --- contact the CPT if you are interested.
(More information about the ITM libraries.)

Example: How to fill coresource/values/sourceid

Top • Previous • Next

When filling in an enumerated datatype, like coresource/values/sourceid, it is recomended to use the parameters and functions built into the fortran modules associated with each such datatype. These modules are available as part of the UAL package. As an examples we may include the coresource_identifier:

use coresource_identifier, only: fusion, get_type_name, get_type_description__ind

Here the value of the integer-parameter fusion is the Flag for fusion reactions in the coresource_identifier structure (i.e. fusion=5). Once we know the Flag we may get the Id using the function Id=get_type_name(Flag) and the Description using the function Description=get_type_description__ind(Flag). These function are available for every datatype.

Below you have an example of how to use these functions:

program coresource_example
  use euitm_schemas, only: type_coresource
  use coresource_identifier, only: fusion, get_type_name, get_type_description__ind
  use write_structures, only: open_write_file, write_cpo, close_write_file
  use deallocate_structures, only: deallocate_cpo
  implicit none

  type (type_coresource) :: coresource
  integer :: idx, i

  character*128 :: filename
  integer :: shot, run

  data filename / &
       & 'coresource.cpo' &
       & /

  allocate(coresource%values(1))
  allocate(coresource%values(1)%sourceid%id(1))
  allocate(coresource%values(1)%sourceid%description(1))
  coresource%values(1)%sourceid%flag = fusion
  coresource%values(1)%sourceid%id = get_type_name(fusion)
  coresource%values(1)%sourceid%description = get_type_description__ind(fusion)

  call open_write_file(1, filename)
  call write_cpo(coresource, 'coresource')
  call close_write_file

  call deallocate_cpo(coresource)

end program coresource_example

This example program, and similar examples for other enumerated datatypes, are available in:

https://gforge6.eufus.eu/svn/itmshared/trunk/src/itm_constants/examples

Grid Types in Equilibrium CPO

Top • Previous • Next

Equilibria may be represented in a variety of different ways depending on which ITM module has calculated them and which module shall use them. To avoid ambiguity and to allow modules to check which type of equilibrium is stored in the equilibrium CPO, a unique grid identifier is stored in profiles_2d%grid_type.
The grid identified currently consists of 4 strings (at 132 chars) with the following structure (array indices in Fortran notation):

Position	Content
grid_type(1)	integer identifier for grid type
grid_type(2)	string identifier for grid type
grid_type(3)	integer identifier for poloidal angle
grid_type(4)	string identifier for poloidal angle

Grid Type Identifier

Top • Previous • Next

The currently allowed values (integer and string) for the identifier of the grid type are listed below:

Integer Values	String Value	Description
1	rectangular	Regular grid in $\text{[math]}$ .'EFIT-like grid'.
2	inverse	Regular grid in $\text{[math]}$ .'flux surface grid'.
3	irregular	Irregular grid. All fields in profiles_2d are given as (ndim1, 1) degenerate 2D matrices, i.e. as lists of vertices (for triangles or quadrilaterals).

Poloidal Angle Identifier

Top • Previous • Next

The currently allowed values (integer and string) for the identifier of the poloidal angle are listed below:

Integer Values	String Value	Description
1	straight field line	straight field line angle $\text{[math]}$ as defined in Straight Field Line Coordinates
2	equal arc	Poloidal angle $\text{[math]}$ defined by equal arc lengths along flux surfaces
3	polar	Poloidal angle $\text{[math]}$ in toroidal coordinates as defined in Coordinate System

Standardized EU-ITM Plasma Bundle

Top • Previous • Next

The ITM has agreed on a standardized way to bundle CPOs and control parameters inside KEPLER.

Field names			Type	Description
time			`real`	The synthetic time of the simulation, or for time-dependent workflows; the end of the present time step. For example, consider a time dependent workflows, where physics quantities are update one after the other. Thus, while the physics quantities are updated the various fields below (e.g. the CPOs) may be describe at different time points. In such workflows the this "time"-field describe the time at the end of the present time step. Units: (s)
CONTROL	tau		`real`	time-step (s)
	tau_out		`real`	time interval for saving output (s)
	ETS	amix	`real`	mixing factor
		amix_tr	`real`	mixing factor for profiles
		sigma_source	`integer`	option for origin of plasma electrical conductivity: 0: plasma collisions; 1: transport module; 2: source module
		solver_type	`integer`	choice of numerical solver
		conv_rec	`real`	required fractional convergence
CPOS	MHD	equilibrium	`cpo`	see type and fortran descriptions
		toroidfield	`cpo`	see type and fortran descriptions
		mhd	`cpo`	see type and fortran descriptions
		sawteeth	`cpo`	see type and fortran descriptions
	CORE	coreprof	`cpo`	see type and fortran descriptions
		coretransp	`cpo`	see type and fortran descriptions
		coresource	`cpo`	see type and fortran descriptions
		coreimpur	`cpo`	see type and fortran descriptions
		coreneutral	`cpo`	see type and fortran descriptions
		corefast	`cpo`	see type and fortran descriptions
		coredelta	`cpo`	see type and fortran descriptions
		compositionc	`cpo`	see type and fortran descriptions
		neoclassic	`cpo`	see type and fortran descriptions
	EDGE	edge	`cpo`	see type and fortran descriptions
	HCD	waves	`cpo`	see type and fortran descriptions
		distsource	`cpo`	see type and fortran descriptions
		distribution	`cpo`	see type and fortran descriptions
	MACH	vessel	`cpo`	see type and fortran descriptions
		wall	`cpo`	see type and fortran descriptions
		nbi	`cpo`	see type and fortran descriptions
		antennas	`cpo`	see type and fortran descriptions
		ironmodel	`cpo`	see type and fortran descriptions
		pfsystems	`cpo`	see type and fortran descriptions
	DIAG	fusiondiag	`cpo`	see type and fortran descriptions
	DIAG	scenario	`cpo`	see type and fortran descriptions
	EVENTS	pellets	`cpo`	see type and fortran descriptions
PCS	input		pcs_in	Diagnostics input signals to the plasma control system (see comple-type definition below)
	reference		pcs_ref	Reference signals for the plasma control system (see comple-type definition below)
	output		pcs_out	Output signals from plasma control system (see comple-type definition below)

The complex-types used in the PCS.

Field names	Type	Description

pcs_in (under development)		Diagnostics for plasma control
`pcs.inputs.plasma_variables`	`type_plasma_ variables`	Plasma variables
`pcs.inputs.plant_variables`	`type_plant_ variables`	Plant variables
pcs_ref (under development)		Reference signals for plasma control
`pcs.reference.plant_variables`	`type_plant _variables`	Plant variables
`pcs.reference.plant_configuration`	`type_plant _configuration`	Plant configuration
pcs_out (under development)		Output signal for plasma control
`pcs.output.plasma_variables`	`type_plasma _variables`	Plasma variables
`pcs.output.plant_variables`	`type_plant _variables`	Plant variables. NOTE: only for artificial control.


type_plasma_variables (under development)		Plasma properties relevant for plasma control
`plasma.shape.ZIP`	`float`	Z_centre*Ip (used for vertical control; definition of Z_centre can vary) [Am]
`plasma.shape.gaps(:)`	`float`	Distance between the plasma and the wall components [m]
`plasma.magnetics.b_toroidal`	`real`	Toroidal magnetic field at the magnetic axis [T]
`plasma.magnetics.Ip`	`real`	Current (A) CPO element: `equilibrium().global_param.current_tot`
`plasma.magnetics.v_loop`	`real`	Loop voltage (V) CPO element: `coreprof().profiles1d.vloop.value`
`plasma.confinement.ne_line_integrated`	`real`	Line integrated electron density ( $\text{[math]}$ )
`plasma.confinement.beta_toroidal`	`real`	Toroidal beta CPO element: `equilibrium().global_param.beta_tor`
plant_variables (under development)		Plant variabels
`pf_system...`	`-`	-
`plant_variables.fuelling.pellet.trigger`	`integer`	TRUE if pellet is being launched, othervise FALSE
`plant_variables.fuelling.gas.puff_rate`	`real`	Gas puffing rate (1/s)
`plant_variables.hcd.nbi.power`	`real`	NBI power (W) CPO element: `nbi().nbi_unit().pow_unit.value`
`plant_variables.hcd.nbi.injection_angle`	`real`	NBI launching angle (rad) CPO element: `nbi().nbi_unit().pow_unit.value`
`plant_variables.hcd.ec.power`	`real`	EC power (W) CPO element: `antennas().antenna_unit().antenna_ec.power.value`
`plant_variables.hcd.ec.angle`	`real`	EC launch angle (definition depend on the machine) [rad]
`plant_variables.hcd.lh.power`	`real`	LH power (W) CPO element: `antennas().antenna_unit().antenna_lh.power.value`
`plant_variables.hcd.lh.n_parallel`	`real`	Parallel refractive index [1]
`plant_variables.hcd.ic.power`	`real`	IC power (W) CPO element: `antennas().antenna_unit().antenna_ic.power.value`
`plant_variables.hcd.ic.frequency`	`real`	RF wave frequency (Hz) CPO element: `antennas().antenna_unit().antenna_ic.freq`

last update: 2019-01-31 by g2dpc