This document contains information on how to maintain and operate
TRANSP: the time dependent tokamak transport and data analysis code.
Since TRANSP as a research code is under continuous developement there
can be no guarantee that the information contained in this help file
is complete and up to date. However I will attempt to update contents
occasionally as time permits.
This information is for users viewing this file through a web
browser.
This is a HTML-ized VMS help document. Some of the older information
is oriented to VMS users. My apologies to UNIX users! However, the
"Namelist" section is equally valid for UNIX and VMS. (Note Apr 2002:
most VMS information, being obscolescent, has now been removed).
Sometimes this document will refer to text in another part of the
document with a statement like:
see $ TRANSPHELP OPER NAMELIST NCLASS
WWW users can interpret this as follows:
TRANSPHELP refers to the "root" of the document
OPERations refers to a "1st level" subtopic, under the root.
NAMELIST refers to a "2nd level" subtopic under OPERATIONS.
NCLASS refers to a "3rd level" subtopic under NAMELIST.
which you should be able to find by following the presented outline
of HTML links.
It is not necessary to have a deep understanding of all the physics
models in TRANSP in order to run TRANSP-- although it helps. This
document does not describe the details of the physics models: only how
to turn them on and off and what minimum information must be supplied
to control them.
TRANSP operational commands-- i.e. how to start a TRANSP run and how to
monitor its progress-- are also described in this document.
There is also information on code structure and maintenance, but much of
this is old (e.g. VMS oriented), has been moved to the bottom of the
edocument, and should not be of interest to the average user.
LEVGEO=8 upgrade (Nov 2006) -- see subtopic.
PTRANSP upgrade (June 2006) -- see the subtopic.
NUBEAM module doc update -- McCune Oct 2004
Fusion Collaboratory Update -- Ludescher/McCune Apr 2002
date: Oct 2004: transp.hlp documentation of NUBEAM controls has been
cleaned up. NUBEAM includes a new feature for automated timestep
adjustment based on accuracy criteria; DTN in TRANSP namelists (which
used to adjust NUBEAM timestep controls) is now ignored.
date: April 2002: TRANSP has been added to the Fusion Collaboratory
and can be run as a computational service at PPPL. Documentation of
this service is under development; in the meantime interested potential
users should write to D. McCune (dmccune@pppl.gov).
Also new in 2002: predictive features added to TRANSP:
-- radiative loss model (based on Coronal Equilibrium)
-- modern predictive transport models (GLF23 and MMM95 from the
NTCC modules library).
TRANSP physics and other software packages are being made available for
use outside of TRANSP, e.g. by other driver codes. The famous TRANSP
Monte Carlo fast ion package is now available. See:
http://w3.pppl.gov/NTCC
The "scrunch2" program and TRANSP have been upgraded (Nov. 2006) to enable:
A) Direct representation of inverse MHD equilibia as
{R(theta,x;t),Z(theta,x;t)} (avoid Fourier series truncation).
theta is defined in terms of equal arc length instead of
a VMEC-derived formulation meant to minimize the number
of moments needed.
TRANSP is no longer dependent on the moments representation
internally, using instead "xplasma" bicubic splines.
TRANSP output (rplot) still has the output in moments form;
the maximum number of moments is now 64.
B) External field-- Psi(R,Z;t) can be extracted from EFIT via
"scrunch2". This is blended with the interior equilibrium,
however computed or read by TRANSP, with smoothing at the edge
of one grid spacing of the (R,Z) rectangular grid. Future
upgrades of NUBEAM may allow accurate tracking of fast ion
orbits beyond the plasma boundary, using this data. An (R,Z)
guiding center integrator is being added to NUBEAM.
C) Numerical limiter-- The EFIT {(R_i,Z_i)} piecewise linear contour
can now be used as a limiter, e.g. for detection of fast ion
orbit loss. When this is used it supersedes the traditional
"circles and infinite lines" limiter description from the
TRANSP namelist.
The PTRANSP project (development of predictive upgrades for TRANSP)
resumed in July 2007. This project is focused on predictive upgrades
to TRANSP itself. Important upgrades, such as improvements to the two
temperature stiff solver, have been implemented.
PTRANSP-related TRANSP namelist variables will be described in the main
body of this document.
PTRANSP upgrade -- June 2006. TRANSP can now be configured to analyze
results from a free boundary predictive tokamak model. In TRANSP
terminology, this predictive model is known as a "Fusion Simulation
Project" (FSP) client. TRANSP itself acts as a "Fusion Simulation
Project" (FSP) server. The services TRANSP provides are:
(a) provide heating and current drive sources due to neutral beams,
RF, alpha heating, and neutral gas sources.
(b) carry out a standard TRANSP analysis of the predictive solver
results (as if these were experimental data) and produce the
standard TRANSP output database (NetCDF or MDSplus).
In its initial configuration, the FSP client will control the timestep
for updating sources and will need to provide providing the following
time evolving data:
(1) MHD equilibrium and poloidal field evolution
(This includes the vacuum field, total plasma current, and the
surface voltage).
(2) Electron temperature and density
(A particle confinement time tau(p) = N/gamma(a) must also be
specified).
(3) Ion temperature.
(4) Zeff.
In addition it may optionally provide:
(5) Toroidal angular velocity profile.
(6) Profile of radiated power.
If these are omitted, TRANSP itself can either use input data or its
internal predictive models to compute their evolution.
In this mode, of course, one is not really "using" TRANSP, but rather,
using the code which calls TRANSP services.
We have implemented this for the PPPL TSC code. Users provide TSC
namelists and use TSC tools to view code results, but TRANSP data is
also produced.
This is work in progress.
Other sources of information (besides this HELP file) are available
to figure out what is going on in TRANSP:
TRANSP webpage:
http://w3.pppl.gov/transp
National Transport Code Collaboration webpage (where many TRANSP
code components are available for download):
http://w3.pppl.gov/NTCC
People collaborating on TRANSP development projects also have access
to the source code. Most TRANSP sources have a lot of internal
documentation. Of particular interest will be:
source/freeshare/port.for -- TRANSP COMMON & namelist specification
including default values.
source/outcor/plotgen.i -- TRANSP output data specification
source/misc/trdatgen.spec -- TRANSP input data specification
and possibly also:
source/tr_vaxdata/dprset.for -- TRANSP (trdat) namelist defaults
For those not engaged in code development, the above can also be
found at
ftp://ftp.pppl.gov/pub/transp/codata/gen
A number of plaintext documents are available in source/doc/* which
are also mirrored at
ftp://ftp.pppl.gov/pub/transp/codata/doc
In this archive some documents of particular interest might be:
trintro.doc -- a short (3-page) introduction to using TRANSP.
(somewhat dated)
sampletr.dat -- a sample namelist (dated but gives a general idea).
refs.doc -- references to published scientific literature related
to TRANSP.
And there is much additional information covering a wide variety of
topics.
The BEST source of information on TRANSP would be talking with current
expert users and developers. People at PPPL with greater or lesser
familiarity with various aspects of TRANSP are:
D. McCune R. Budny S. Kaye
K. Indireshkumar C. Ludescher A. Pletzer R. Andre
choose subtopic--
If you have your namelist and Ufiles already, and want to start a
TRANSP run, see the section TRANSPruns.
TRANSP run id's have been generalized to allow a shot-try format.
See the section Run_identification.
All TRANSP software supports both the old and new format run id.
So you want to make a TRANSP run? You need two things:
(a) access to high quality tokamak data
(b) the time and patience to learn how to use the TRANSP namelist,
input data preparation tools, and output data display tools.
TRANSP and supporting codes constitute a large system. It is
essentially a collection of physics and empirical data processing
knowledge. The complete system encompasses a about a million
lines of FORTRAN, over 100 executable programs, over 100 subroutine
libraries. Just TRANSP itself contains 500,000 lines of FORTRAN,
over 2000 subroutines, and up to 1000 named quantities in its plot
output database. Mastery over this system is not won with only
one or two days' effort.
On the other hand, the effort may be worth the cost. TRANSP is often
the best tool available for time dependent analysis of tokamak data.
Just going through the process of gathering and preparing a self-
consistent data set for a TRANSP run is often very instructive,
revealing much about the quality of the data. The analysis itself
then yields a vast amount of information. If the data holds up under
analysis, then the TRANSP output database can serve as the starting
point for numerous quantitative comparisons with theoretical plasma
physics models, giving a point of contact between theory and experiment.
For purposes of getting started it is probably best to work first
with an experienced TRANSP user. This HELP file is probably most
useful as a reference for those who already have considerable
familiarity with the system.
In 1999-2002, TRANSP i/o was generalized to allow operation with data
sharing over the network, based on the MDSPlus software of the MIT
Plasma Fusion Center. (see http://w3.pppl.gov/transp/MDSPLUS ). A
"standard MDSplus TRANSP tree" was agreed to by the major U.S. fusion
labs (PPPL, GA, MIT, see: http://w3.pppl.gov/transp/MDSPLUS/tree.html ).
Although PPPL TRANSP runs (even in MDSplus) continue to be identified
using the traditional "tokamak.year shot-try" nomenclature, other labs
have chosen a more MDSplus oriented approach, in which archived TRANSP
runs are associated with an MDSplus experimental "shot tree", and each
distinct TRANSP run is given a separate subtree name such as "TRANSP01",
"TRANSP02", etc. However, the precise method for run identification
is basically under the control of the TRANSP client site, and it does
vary from lab to lab, although MDSplus based accessibility is now
standard.
All PPPL tools for looking at TRANSP output can access TRANSP results
in the traditional method (via files on a local disk) or by the new
MDSplus method (from MDSplus servers over the internet). Many of the
traditional TRANSP client tools (such as "rplot" and "ufiles" software)
are available for download from the PPPL National Transport Code
Collaboration (NTCC) website: see http://w3.pppl.gov/NTCC .
Complete identification of a PPPL TRANSP run requires the following
information:
(a) a tokamak acronym (3 or 4 characters)
(b) a two-digit shot year code
(c) a run id: either the old four digit run number or the new
shot-try identifier.
The following are examples of complete TRANSP run ids:
TFTR.84 9900 (TFTR, 1984 shot data, 4 digit run id 9900)
TFTR.88 35782P02 (TFTR, 1988 shot data, shot-try run id
35782P02 which in the PPPL usage indicates
a predictive run based loosely on data from
TFTR shot 35782)
A complete run id can be used for at most one TRANSP run. At PPPL
the program $ GETRUN can be used to determine what runs exist and
where the data is stored (i.e. on magnetic disk, optical disk, or
tape).
Introduced in 1990, the eight character shot-try string is the
new, preferred way of labeling TRANSP runs. The shot-try string
has the format
nnnnnCmm (typical), or
nnnnnnCmmm (with 6 digit shot number and 3 digit try number).
where:
nnnnn is the 5 or 6 digit shot number (identifies the tokamak shot)
6 digit variant cannot have a leading zero.
C is a one character run classification code (A-Z).
mm is a 2 or 3 digit try number used to distinguish different
runs of the same class on the same data. The 3 digit try
numbers cannot have leading zeroes.
TRANSP users or user groups may use the one character run class-
ification code in any way they see fit.
For example, the PPPL TFTR group used A for analysis, P for
predictive runs, and Z for code testing or debug runs. Thus the
run id 35782Z90 corresponds to a debug test run. However, this
is a local convention of use and is not in any way imposed by
the TRANSP code system.
Prior to 1990, the four digit run number was the only mechanism
available for the labeling of TRANSP runs.
The newer shot-try run identification scheme should be used in
preference to the four digit run number. However, the four digit
run number is still supported and will continue to be supported in
TRANSP and related codes.
Selection of run numbers for TRANSP runs is entirely in the hands
of the operator(s) of TRANSP.
Suggestion (if you must use the four digit run number):
for each new "shot" or data set, "allocate" 20 unused run numbers for
that shot. For example: for shot 12345 allocate run numbers 1220
through 1239. TRANSP run numbers are always 4 digits long, i.e.
between 1000 and 9999. The first run number in the TRANSP run
"series" for shot 12345 would be 1220, the second 1221, etc. For
major changes in the input data one might skip to numbers 1230, 1231...
or perhaps allocate a fresh set of 20 run numbers.
Reusing run numbers for runs on data from the same tokamak and year
of shot is not recommended.
If more than one user is working on data from the same tokamak shot
year, special caution must be employed in selecting run numbers, to
avoid conflicts.
The old TRANSP system used to run exclusively on PPPL VMS machines.
The system has long since been ported to unix, and, recently, the
last VMS TRANSP run production system was turned off.
However, PPPL TRANSP results can still be accessed on the PPPL VMS
machines...
TRANSP results data (from completed runs) reside on disks identified
by the logical name RUNDATA:
TRANSP run documentation resides on a disk identified by the logical
name TRINF:
TRANSP code and procedures reside on a disk called TRHOME:.
Users that do not execute the TRANSP LOGIN procedures can also use
the system wide TRANSP$ logical name to access TRANSP utilities:
TRANSP$:[COM] is synonymous with TRHOME:[TRANSP.COM] (a directory
of TRANSP DCL procedures).
(read the section on disks first!)
At PPPL (Apr 2002) the following tokamak directories are known:
PLT PDX PBX PBXM TFTR NSTX
ASDX AUGD BPX CIT D3D DIII FIRE HL1M ISX ITER JET JT60
JULI MAST NCSX TORS TXTR WRK
Ufile data directories --
TRANSP provides a default set of directories for input data.
UFILES physics input data are stored in subdirectories
TRHOME:[TRANSP.<tok>.DATA], also conveniently accessible via the
LOGICAL NAMES <tok>_DATA. All TRANSP runs analyze data from one
nominal shot (namelist item NSHOT) although the data itself may
represent an amalgam from several actual shots. The shot number
NSHOT must be imbedded in the filename of all UFILES to be used
in a given TRANSP run.
It is possible and may be desirable to create more directories
for input data storage. At PPPL we do this for TFTR data. TFTR
UFILEs are stored in areas TR_DISK:[name] where "name" is the
name of the physicist preparing the input data for TRANSP.
TRANSP run namelists are modified to specify where to find the
UFILE input data.
TRANSP run results directories --
Files for COMPLETED TRANSP runs are stored in subdirectories
RUNDATA:[TRANSP.<tok>.<year>] where <year> is a two-digit code
constituting the last two digits of the YEAR of the SHOT.
After a period of time, runs are removed from the RUNDATA:
magnetic disks, because of limitations of storage space.
However, the run's documentation file (xxxxTR.INF) and its
input namelist (xxxxTR.DAT) are retained on disk and may be
found in the directory TRINF:[<tok>.<year>].
Example: The TRANSP run TFTR.90 46470Z02 ...
completed results resided in RUNDATA:[TRANSP.TFTR.90]
information on the run can be found in TRINF:[TFTR.90]46470Z02*.*
At PPPL the program $ GETRUN can be used to restore migrated runs.
Runs on laser disk can be restored by reference with $ RPLOT.
Unix based TRANSP development systems and production systems
are now the norm. Documentation for unix based systems
is found largely in files found in the source distribution
under codesys/source/doc. See for example unix_transp.doc.
For general information on setting up a UNIX TRANSP system,
see also anonymous ftp at:
ftp::ftp.pppl.gov:pub/transp/codata
start with the README file.
TRANSP run results directories --
Output files for COMPLETED TRANSP runs are stored in subdirectories
$ARCDIR/<tok>/<year> where <year> is a two-digit code
constituting the last two digits of the YEAR of the SHOT.
Namelists and inf files are stored in $TRINF/<tok>/<year>
The following programs are used in the process of creating a TRANSP
run.
** this section to be updated (dmcApr16) **
** for PPPL and Collaboratory Users **
** VMS/UNIX differences to be noted (dmcApr16) **
RPLOT -- interactive program to look at TRANSP plot output. Also
runs in batch to produce standard hardcopy plots.
Define Environment TERMINAL_TYPE
xterm -- "xterm" terminal emulator
XTC -- "xtc" terminal emulator
XTRANSPIN -- GUI to prepare a Namelist for a Transp run and submit the run.
To produce a PostScript file define environment "PLOT"
(e.g. export PLOT=',foo.plt-ps')
See http://w3.pppl.gov/~pshare/help/body_sg_hlp.html
Note: tek2ps_sh and tek2ps must be in your $PATH
tek2ps.pro should be in /usr/ntcc/etc, $cwd or in $TRANSP_LOCATION
The UNIX TRANSP developer with a standalone system will typically use
the following programs:
pretr -- set up scripts for a TRANSP run
trdat -- examine input data for a TRANSP run
runtr -- execute a TRANSP run
A UNIX TRANSP user in a shared local UNIX production system may
use commands as described in the user interface section of
codesys/source/doc/tr_start.doc
which if you need help finding you should ask the person at your site
who is acting as keeper of the TRANSP production source code.
See also: http://w3.pppl.gov/transp/production.html
Note: JET has its own locally developed TRANSP production system.
INPUT: namelist and physics data
1234TR.DAT, UFILES, (optional) 1234EX.FOR for special code
--all the above can now be in an MDSplus tree instead.
PERMANENT OUTPUT in VMS RUNDATA:[TRANSP.<tok>.<year>]
or UNIX $RESULTDIR/<tok>.<year>
traditional format:
1234TF.PLN -- plot data map and labels for RPLOT
1234MF.PLN -- profile plot data for RPLOT
1234NF.PLN -- scalar plot data for RPLOT
NetCDF format:
1234.CDF -- all of the above in a single portable binary
random access NetCDF file.
--or, output may be stored in an MDSplus tree instead
During execution, TRANSP creates and removes a sizable collection of
temporary files. There are also some relatively seldom used special
purpose output files which are not documented here.
physics data input to TRANSP. stored in a directory indicated by
the INPUTDIR variable in the TRANSP namelist... or instead, input
signals may now be stored in MDSplus.
Ufiles help is available via the http://w3.pppl.gov/NTCC or
http://w3.pppl.gov/transp webpages.
(these tools, which are used to prepare TRANSP input data, in the
past read and wrote Ufiles but can now also read/write to MDSplus).
(note -- the program names are in lower case on UNIX systems).
GSMOO1 - SMOOTH 1d UFILES
GSMOO2 - SMOOTH 2d UFILES
GSMOOn routines also allow various types of smoothing,
removal of glitches, "units transformations" (i.e. linear transforms
f-->a*f+b for any axis of the data), and in GSMOO2, an interchange
of axes f(x,y)<-->f(y,x).
GAVER1 - AVERAGE 1d UFILES
GAVER2 - AVERAGE 2d UFILES
Input UFILES to the GAVERn routines should contain equivalent data
units appropriate for averaging. The meaning of the dependent and
independent axes of the inut data files should be compatible.
In 1986 the GAVERn utilities were upgraded so that precise matching
of independent axes of input data is no longer required. The first
input file determines the axes for the output file; subsequent input
files have their data interpolated to this fixed grid.
Also in 1986 variable weighting and data summing options were added
to the GAVERn programs.
UGRAF1 - PLOT 1d UFILES
UGRAF2 - PLOT 2d UFILES
PROPANE - GENERATE hand-entered or analytic shaped UFILES
EXTRAC - EXTRACT subset UFILES from 2d input UFILE.
EXTRAC permits extraction of 1d UFILE "slices" with averaging options,
or 2d "blocks" with sections of the original 2d UFILE deleted. Useful
for removing bad sections of data, or taking the "most useful" part of
a 2d UFILE and creating out of it a simpler to use 1d UFILE.
CONCAT - CONCATENATE a series of 1d UFILES into a single 2d UFILE.
Used e.g. to join a series of Thompson Scattering profiles (1d vs. r
at individual times) to form a profile evolution file vs. r and t.
The 1d input UFILES must have the same x axes (no. of pts and values)
and each must contain a scalar from which the 2nd independent axis is to
be constructe
CONCAT can also be used to add additional profiles or time series to
existing 2d Ufiles.
New 1986 Utilities:
SPLICE1 - splice 1d UFILES to form new 1d UFILE. E.g. read in a series
of time trace UFILES, specify time intervals and associate a file with
each interval; plot the result and/or write as a new UFILE. Sample
application: splice neutron detectors so that the best count rate
detector is in use at all times during a shot.
SPLICE2 - 2d analog of SPLICE1
UFILES utilities are described in more detail in the UFILES manual
(D. Mc Cune's office). All utilities are interactive menu driven
programs. All use UREAD for control input and so may be readily
adapted to batch mode use for automatic processing of large amounts
of similar data (for UREAD HELP info type $ URHELP).
UFILES utility experts at PPPL: R. Budny, D. Mc Cune, M. Zarnstorff.
The TRANSP namelist file nnnnTR.DAT actually contains two namelists:
(1) TRDAT namelist. Define UFILEs input data to TRANSP. Specify
certain data options, e.g. normalization of density profile data.
The TRDAT namelist contains CHARACTER data and is not read by
TRANSP. All entries in this namelist are described under the
subtopic TRDAT. TRDAT is the input data preprocessor for TRANSP.
(2) TRANSP namelist. All TRANSP options. This namelist is read by
both TRDAT and TRANSP.
When a TRANSP namelist switch setting requires availability of UFILEs
data for TRDAT this fact is stated but the specifics of how to make
consequential modifications to the TRDAT namelist are not repeated.
see the TRDAT subtopic.
NOTE: in places the documentation refers to files in the TRANSP
source distribution. Some of the more commonly referenced objects
are described above in the section on "Documentation". For other
items-- if you do not have access to the TRANSP source but need it,
contact Doug McCune at PPPL (dmccune@pppl.gov) (noted 16 Apr 2002).
... choose subtopic
It is highly advisable to use the namelist of a recently completed
TRANSP run as a template when preparing a new run. If you are new
to TRANSP namelists it is instructive to examine an existing namelist
file. The file contains inline comments preceded by the comment
character "!". (The file is not in FORTRAN namelist format; it is
sorted and transformed before actually being read in by any FORTRAN
NAMELIST READ statement).
As a reliability feature, TRANSP writes RESTART records. The data
in the restart records allows the TRANSP job to be restarted in case
the computer on which the job is running crashes. On the VAXs this
is usually done automaticly.
However, the writing of these restart records can be time consuming.
Therefore, set
MRSTRT= n
to write restart records only once every nth plot output record,
or, even better, set
MRSTRT= -m
to write restart records only once for every m minutes of cpu
time consumed. The default is MRSTRT = -20.
If a job is stopped and restarted, and MRSTRT.GT.1 or MRSTRT.LT.0
was used, then, the run output data may contain duplicate time points.
The plot post-processor program POPLT2 removes them while converting
the data to binary form for RPLOT access.
To completely suppress restart records set MRSTRT=0. This is
not recommended.
DMC May 2003: the user value of MRSTRT will be overridden and
set to -1, if ELVIS runtime graphical monitoring is enabled (see
next section).
(this section not finished)
It is now possible to restart a TRANSP run under a new runid with
modified input data-- a capability generically referred to as
"steering" a run. The procedure for this is
(a) interrupt the TRANSP run to be restarted. This can be pre-
programmed using stop times TABORT(...) in the namelist, or
it can be requested on the FusionGrid while the run is still
executing (how?).
(b) submit a new run with modified namelist, which references the
original run (a) but provides input data that is modified; the
modifications apply only to times after the time of interruption
of the original run.
The set of allowed changes for such a modified restart namelist is
limited. The revised input data is merged, i.e. combined from the
original run for times prior to its interruption, and taken from the
new run namelist for times after the interruption. This merger is
executed by the TRANSP data acquisition front end program, trdat.
Therefore, only namelist changes which modify the data seen by trdat
are allowed. These are generally:
-- names of Ufiles or MDS+ signals containing input data
i.e. input data (e.g. electron density, Zeff) can be changed
on this type of restart, the change only applying after the
restart time.
-- neutral beam powers and voltages (and on/off times)
-- RF antenna powers (and on/off times)
-- stop time of run
-- future interruption (TABORT) times in the run
Anything else, such as, generally, controls for the TRANSP simulation,
e.g. choice of transport model, which variant of neoclassical bootstrap
current and/or resistivity, etc., can NOT be changed on restart.
(A tool will be provided to assist with construction of a restart
namelist, and to check the validity of a namelist intended to be
used for a restart with modified data).
The namelist for the modified run will contain explicit references
to the original run:
old_transp_run = <path-to-old-run> (character string)
old_transp_time = <time to which old-run plasma data is valid>
old_transp_stime = <time to which old-run source data is valid>
blend_time = <transition time interval to new data>
(need to describe how to specify MDS+ path to old_transp_run data).
Although a run can reference it's own input data, that input data will
be modified when the restart executes-- and therefore, this is not
recommended.
The default value for "blend_time" is 0.01 seconds.
Since the input data of the original run is now archived separately,
the namelist remains valid after the restart run completes, i.e. the
calculation can be rerun from the beginning under a 3rd runid, and
will see exactly the same hybrid data, part from "old_transp_run"
and part from the Ufile/MDS+ specifications in the namelist.
The floating point quantities (old_transp_time) and (old_transp_stime)
refer to the time extent of the original run's input data. The former
applies to plasma state data (temperatures, densities, total current);
the latter applies to data pertaining to heating and current drive
sources (neutral beam powers, RF antenna powers, etc.). These are
slightly different, because TRANSP's heating and current drive
calculation leads the transport calculation by a small amount,
typically a few milliseconds.
By the methods described here, a "base run" for steering can be prepared
and held in place, allowing many variant runs to reuse the run's results
for the "early part" of a discharge, saving computer time.
However, such runs cannot be preserved across code updates. I.e. if
the TRANSP code version changes, base runs will have to be re-executed.
TRANSP can generate limited numerical output which can be graphically
monitored during execution of the run. To enable this, an ELVIS
graphics server must be available, and, the environment variable
ELVIS_SERVER
must be defined to give the name of the server, on the machine where
TRANSP itself executes.
If these conditions are met, then, the following namelist controls
determine what quantities are to be output. These controls use the
language of RPLOT, the traditional tool for the viewing of TRANSP
output (documented elsewhere).
CHARACTER*128 RPLOT_PROG(20) -- RPLOT calculator script -- can
contain a sequence of up to 20 RPLOT calculator commands which
can be used to define additional outputs beyond what TRANSP
itself defines. This is optional; the default is that this
script is empty.
CHARACTER*30 RPLOT_ITEM(20) -- up to 20 names of RPLOT items:
the following types of RPLOT objects can be named:
-- scalar functions of time (example: "VSUR").
-- multigraphs of scalar functions of time (example: "CPDIS").
-- profile functions of time & addl. coordinate (example: "TE").
-- multigraphs of profile functions of time. (example: "IEBAL").
Additionally, profile multigraphs can have applied transformations,
i.e. RPLOT_ITEM(j)="VOLINT(IEBAL)" means the j'th ELVIS display
will be the volume integrated ion power balance, in Watts.
If ELVIS_SERVER is defined and RPLOT_ITEM(...) is defaulted, then the
following scalar multigraph outputs will be provided:
CPDIS -- cpu time usage with breakdown by code component.
LBPOL -- li/2 + beta(poloidal) multigraph.
XNEUT -- neutron emission multigraph.
If RPLOT_ITEM(1)="NONE", then, the whole feature is suppressed
regardless of the availability of ELVIS_SERVER.
If ELVIS_SERVER is given a name starting with '/' or '.', then it is
interpreted as the name of a directory and instead of transmitting
the data to a server, the data will be written to the file
${ELVIS_SERVER}<runid>_<tok>.gw.
Elvis output data is generated at the same time as the rplot data. The
Elvis data will be sent to the ELVIS_SERVER no more frequently then
every SEEDIT cpu seconds (default 15). If SEEDIT<=0., the Elvis data
is not sent to the server.
[New DMC 6 Dec 1991]
TRANSP has a new output facility -- Ascii Compressed files or ACFILES.
This facility may be used to select a few special times and output
any part or all of TRANSP COMMON to a file in a convenient portable
compressed ascii format.
Details concerning this facility are given in the separate document
source/doc/acfile.doc (also on the ftp server).
The following is a summary of ACFILE-related TRANSP namelist controls:
Character variables:
SELOUT=' ... ' -- list of names of TRANSP COMMON symbols to output.
If defaulted, ALL OF TRANSP COMMON is output (usually this is best).
SELAVG=' ... ' -- list of names (REAL variables and arrays only) to
average prior to output. Must be a subset of SELOUT. If
defaulted, nothing is averaged before output.
For example:
selavg='FBM BMVOL BDENS2 EBA2PL EBA2PP'
selects a basic set of data for fast ion distribution functions.
OUTTIM=1.5,1.7,1.9, ... -- list in ASCENDING ORDER of times when
ACFILEs should be written. A maximum of 9 times may be given.
If fewer than 9 times are given, fewer than 9 ACFILEs will be
written. The ACFILEs are named e.g. for run 12345A01:
12345A01.DATA1 -- at OUTTIM(1),
12345A02.DATA2 -- at OUTTIM(2), ... etc.
The following are relevant if SELAVG is non-empty:
AVGTIM=averaging time, seconds -- for the jth output ACFILE, data
that is averaged is averaged over the time range OUTTIM(j)-AVGTIM
to OUTTIM(j). NOTE -- OUTTIM(j) and OUTTIM(j+1) must be separated
by at least AVGTIM seconds! (Only one average can be accumulated
at a time).
MTHDAVG=averaging method. set MTHDAVG=1 for default (use heating
source timestep if available); MTHDAVG=2 to sample on completion
of each heating source timestep; MTHDAVG=3 to use a sampling period.
Recommendation: use the default, MTHDAVG=1.
AVGSAMP=sampling period, seconds. If MTHDAVG=3 and the time is in
range for averaging data for the next ACFILE, and if AVGSAMP or
more time has passed since the last time point was averaged, then
the next time point is averaged. The effective sampling rate will
be longer than AVGSAMP by of order 1/2 a TRANSP energy balance
timestep.
[New DMC 15 Apr 2003]
...This is a debugging feature.
At up to 9 user selected times, data may be saved to allow the modular
fast ion codes to be run in standalone mode. Sufficient data is saved
to allow bit-for-bit reproduction of a fast ion calculation done at a
particular time in TRANSP, if the standalone code is run in a machine
which is binary compatible with the machine on which TRANSP itself ran
when producing the data. If the standalone code runs on a machine
which is not binary-compatible, the standalone rerun will not be
identical bit it will be "very close" to the original.
The saved data is a unix archive (tar file) compressed with gzip.
Therefore, the data can only be unpacked on a unix machine which
supports tar and gzip. The contents will depend on what fast ion
models are present in the TRANSP run. Generally, the contents will
consist in namelists (to drive the modules), NetCDF-based module
state files, and a NetCDF-based xplasma state file containing the
MHD geometry and various plasma parameters. Unix-TRANSP includes
a script, codesys/csh/fi_gzn_unpack, to unpack this data.
The output times are specified in the namelist variable FI_OUTTIM(...):
FI_OUTTIM(1) gives the time at which to write <runid>_FI_TAR.GZ1
FI_OUTTIM(2) gives the time at which to write <runid>_FI_TAR.GZ2
...
FI_OUTTIM(n) gives the time at which to write <runid>_FI_TAR.GZn
(1 <= n <= 9).
Codes that can be driven by this data
xfpprf -- standalone Fokker Planck code with attached RF full
wave solvers. (Assuming TRANSP itself was using the
Fokker Planck package).
nubeam_test -- standalone test driver for NUBEAM, Monte Carlo
fast ion code (for beam- and fusion product ions).
(Assuming TRANSP itself was using the Monte Carlo
package).
Note that `xfpprf' can also be run using standard TRANSP output data.
This avoids having to define the FI_OUTTIM(...) times of interest in
advance. A TRANSP program, `gfpprf', is used to extract the xfpprf
driver namelist at the selected TRANSP time, and to specify where
(what file or MDS+ path) the TRANSP data is currently located. The
`xfpprf' calculation driven in this manner is not bit-for-bit the
same as what was executed in TRANSP. The Fokker Planck code's state
file (with beginning-of-timestep fast ion distribution function data)
is not available, and a Maxwellian distribution with the right
average energy is assumed instead. Nevertheless, this is adequate
for many purposes, e.g. testing most RF wave codes.
"fi_gzn_unpack" is a csh shell script distributed with TRANSP and also
in the NTCC TRANSP tools module (tr_client). To use it:
a) go to a (preferably empty) working directory.
b) copy the desired <runid>_FI_TAR.GZ<n> file to this directory.
c) executate fi_gzn_unpack script with the filename as argument:
fi_gzn_unpack <runid>_FI_TAR.GZ<n>
(If you do not have access to fi_gzn_unpack script, you
can use:
tar xvfz <runid>_FI_TAR.GZ<n> )
d) if the original TRANSP run used NUBEAM, the files needed to
execute the "nubeam_test" program have been unpacked.
e) if the original TRANSP run used FPPMOD, the files to execute
the "xfpprf" program have been unpacked.
f) the filenames inside <runid>_FI_TAR.GZ1 and <runid>_FI_TAR.GZ2
are the same, so use separate directories to look at both of
these independently.
Even if FI_OUTTIM(...) is not used (cf preceding section): FPPMOD
namelists are saved N_FPWRNML times per TRANSP run. These can be
retrieved by `gfpprf' and used in `xfpprf' to approximately reproduce
an ICRF/FPPMOD timestep, with extra plotting of wavefields, etc. The
minority fast ion distribution function has not been saved, in this
mode; instead, the starting condition for the xfpprf timestep will be
a maxwellian at elevated average energy.
N_FPWRNML is a namelist control:
default value: 100
minimum value: 20
maximum value: 2000
The N_FPWRNML output times are spaced evenly throughout a TRANSP run;
the associated namelist data is concatenated in an ascii file,
<runid>FPPRF.DATA
specify
NSHOT=nnnnn
in the namelist, where nnnnn is the "nominal" shot number of the
data to be analyzed in the TRANSP run. This shot number is
"nominal" in the sense that the actual data may have been
assembled from multiple shots. The specification of NSHOT is
important because
(a) all UFILES read by TRANSP for this analysis must have the
shot number NSHOT imbedded in their filenames, and
(b) documentation. The shot number NSHOT is associated with
the run's run number in TRANSP databases.
TRDAT is used to acquire UFILE input data for TRANSP runs. The
names of the input Ufiles and related controls are entered in
the TRDAT namelist. These quantities are entered in the
nnnnTR.DAT file between the records $TRDATA and $END. Quantities
between these two records are known as TRDAT namelist quantities;
all other quantities are TRANSP namelist quantities. TRDAT
namelist quantities are known to TRDAT but not to TRANSP; TRANSP
namelist quantities are known to both TRDAT and TRANSP. A handful
of TRANSP controls which specify handling of profile data are
important to TRDAT and will be referred to in this section of
TRANSPHELP.
This section added March 1992 -- new TRDAT installed.
The new TRDAT checks the units labels of input Ufiles. UFILES ARE
NOT ACCEPTED UNLESS the Ufile units labels conform to the standard
defined by trdatgen.spec, the input file to the TRDAT code generator
TRDATGEN. Instructions on how to find trdatgen.spec are in the
documentation section near the top of this file.
See also the description of the TRDAT namelist control LFIXUP.
General units conventions:
all times are in SECONDS
all distances are in CM
ECE frequencies in GHZ
Temperatures in eV, densities in CM**-3
Surface voltage in VOLTS, plasma current in AMPS,
.. etc ..
Some standard units conversions are also supported with LFIXUP=2,
e.g. KeV --> eV for temperature data (cf trdatgen.spec).
The new TRDAT namelist switch LFIXUP is used to control units
conversion:
LFIXUP = 0 ==> suppress all units conversion (if an unknown
units label is encountered a warning is printed).
This emulates the behaviour of the "old" TRDAT.
LFIXUP = 1 ==> require labels to strictly follow TRANSP
conventions-- if unconventional labels are
detected, the input data is rejected.
LFIXUP=1 is the default value.
LFIXUP = 2 ==> support conversion of data (e.g. multiply
data by 1000.0 to go from KeV to eV) and
support axes swap if needed for profile data,
to satisfy the convention that "time" be the
"first" independent coordinate of the data.
mixed modes (added by dmc, Apr 1996):
LFIXUP = 3 ==> as LFIXUP=0 but 2d Ufile time axes swap *is done*.
LFIXUP = 4 ==> as LFIXUP=1 but 2d Ufile time axes swap *is done*.
LFIXUP=0 should be used only to allow old TRANSP runs to be
rerun, even if the input Ufiles units labels are incorrect.
The most restrictive option LFIXUP=1 is the default.
LFIXUP=2 is recommended. HOWEVER, the units labels in your
Ufiles must be correct! This is a change from the old TRDAT,
which did not care what was in your Ufiles units labels!
If there are errors in the Ufiles units labels
(e.g. the file says "KeV" but the data is actually in eV)
then the run could fail using the new TRDAT, even though the
old TRDAT would have accepted the data and TRANSP would have
been happy-- because with LFIXUP=2, the new TRDAT will multiply
"KeV" data by 1000.0 to try to put it in "eV" for TRANSP.
LFIXUP=3 or LFIXUP=4 will be of use if it is desired to have
TRDAT standardize the axes ordering of input 2d Ufiles but
not convert units.
... added Jul 2007
A multiplicative scaling factor may now be defined for any input Ufile,
using a namelist card SC_xxx. This changes the data values ( only ) --
independent coordinates (R or X) and time T are unchanged.
If a factor SC_xxx is supplied, then any error resulting from unknown
Ufile units will be disregarded, on the assumption that the scale factor
has been supplied to correct the error. It is the user's responsibility
to ensure that this is in fact the case.
... modif Aug 1986 -- see update note...
All input UFILEs for TRANSP runs reside in [TRANSP.<tok>.DATA] where
<tok> is the tokamak id. The UFILE names all have the form
<prefix>mmmmm.<extension>
where:
<prefix> is an upto 16 character prefix specified in the TRDAT
namelist as CHARACTER*16 variable PRExxx,
<extension> is an upto 16 character filename extension specified
in the TRDAT namelist as CHARACTER*16 variable EXTxxx,
and xxx specifies the type of data to be contained in the named
UFILE, and
The SHOT NUMBER mmmmm is an integer of up to 6 digits length
which is specified in the TRANSP (not TRDAT) namelist as variable
NSHOT.
EXAMPLE:
NSHOT = 12345
$TRDATA
PRELID='S'
EXTLID='MWL'
$END
specifies S12345.MWL as input UFILE for the run. The code "LID" in
the variable names indicates that the data type in the UFILE should
be "line integrated electron density" in units cm**-2
August 1986
UPDATE NOTE -- the TRDAT namelist controls INPUTDIR and INPUTDSK may
be set to override the source disk:[directory] for UFILES. E.g. for
TFTR most ufiles are NOW stored in directories TR_DISK:[username]
where username = the name of the physicist preparing the data. Set
INPUTDIR='username' in the namelist, and INPUTDSK='TR_DISK'. The
default value for INPUTDSK is the TRANSP disk logical name TRHOME
(except at PPPL for TFTR runs only, TR_DISK is the default name).
Mere specification of an input UFILE for TRANSP usually does not
suffice to tell TRANSP "what to do" with the data. It is usually
necessary to also set additional namelist switches to tell TRANSP
e.g. whether to use the data directly in modeling the plasma or
simply to pass it through to the plotting output file for comparison
with a simulation.
As of July 1985 the following 1D UFILES data types are recognized
by TRDAT and TRANSP as possible input files. Set TRDAT namelist
variables PRExxx and EXTxxx to request the data type for input.
ALL FILES ARE VS. TIME ONLY; TIME IN SECONDS ***
xxx description units notes
--- ------------------------------------ ---------- ----------
CUR plasma current amps A
VSF loop voltage *at plasma surface* volts A
POS plasma major radius cm B
RMN plasma minor radius cm B
RBZ external B field * major radius tesla*cm A,B
L2B li/2+beta (Shafranov) vs. time none A,B
BDI diamagnetic beta vs. time none A,B
DFL diamagnetic flux vs. time webers A
LAD line average density cm**-3 C
LID line integral density cm**-2 C,D
FMN minority ion fraction nmin/ne none T
TET electron temperature (scalar data) eV E
TIT ion temperature (scalar data) eV F
PFL passive cx Ti lower fit limit eV F
PFL passive cx Ti upper fit limit eV F
TXI passive cx "intercept" PDX units ?
NTX neutron production sec**-1 F
ZEF Zeff (impurity parameter) none G
VSB ctr chord Vis. Bremsstrahlung light VB/cm**2 G
RCY recycling ion source #/sec H
TPI ion particle confinement time seconds H
XKF ion conduction parameter none J
VPH plasma axial toroidal rotation cm/sec K
SAW sawtooth event times sec P
(In TRANSP the interpolation of this data to a specified time
is performed in subroutine PLPARM, datcor/plparm.for. There
is a scalar TRANSP common variable for each data type)
In TRDAT the UFILES for the data are read. The data is interpolated
to a standardized timebase which covers the TRANSP analysis time
range (TRANSP namelist quantities TINIT, FTIME). The data is passed
to TRANSP via the ascii "unified physics file".
TRANSP has some expectations regarding the signs of f(t) input
signals. TRDAT enforces these conventions where it can; other
conventions require user conformance. The most important of these
f(t) sign conventions are as follows:
CUR (plasma current vs. time) is positive
--The input data is multiplied by -1 to force this if necessary.
RBZ (R*Btoroidal in vacuum) is positive
--The input data is multiplied by -1 to force this if necessary.
--the RBZ sign multiplier XRNRBZ (+/-1) is saved for application
to DFL data (see below).
VSF (surface voltage) positive voltage is supposed to drive current
in the direction of the main plasma current.
--Since VSF changes sign, TRDAT makes no attempt to correct the
sign. The user needs to assure that the convention is followed.
DFL (displaced diamagnetic flux) positive means a paramagnetic plasma
(Bphi increased over vacuum value); negative means a diamagnetic
plasma (Bphi reduced from vacuum value).
--The multiplicative factor XRNRBZ applied to force RBZ positive
is **also** applied to the DFL data.
--The user needs to assure that if the RBZ data is negative, then
XRNRBZ*DFL (XRNRBZ = -1.0) fulfills the convention (positive =>
paramagnetic plasma).
As of July 1985 the following 2D UFILES data types are recognized
by TRDAT and TRANSP as possible input files. Set TRDAT namelist
variables PRExxx and EXTxxx to request the data type for input.
There are several options for defining the spatial coordinate of
profile input Ufiles-- see the section on Ufile_characteristics.
The filename of the TRANSP subroutine which does the final
interpolation of the data is given. TRDAT performs a preliminary
interpolation after reading the UFILE.
xxx description units notes subroutine
--- --------------------------------- ---------- ----- ----------
NER electron density profile data cm**-3 C,L PROFE.FOR
TER electron temperature profiles eV E,L PROFE.FOR
ECF ECE electron temperature data eV E,L PROFE.FOR
NMR minority ion density profile data cm**-3 T,L PROFE.FOR
BOL bolometer/ power radiated data Watts/cm3 M RADX.FOR
ZF2 Zeff profile data none G GZEFF.FOR
VB2 Visible Bremsstrahlung profiles VB/cm**3 G GZEFF.FOR
TI2 ion temperature profiles eV Q,J KAPAI.FOR
KI2 ion conductivity profiles cm2/sec Q,J KAPAI.FOR
NB2 TFTR waveform neutral beam data mixed.......R NBPDAT.FOR
VP2 plasma rotation profile data cm/sec K GOMEGA.FOR
OMG plasma angular rotation data rad/sec K GOMEGA.FOR
KE2 elec.conductivity profiles cm2/sec S KAPAE.FOR
BPB Field tilt Bp/Bt vs major radius none U FBCALM.FOR
BPA Field tilt a, tan(a)=Bp/BT, vs R none U FBCALM.FOR
Note -- dmc 18 Sep 1998 -- the list is much longer now. See
the specification file for a complete list: trdatgen.spec --
described in the Documentation section at the top of the document.
As of summer 1986 most TFTR neutral beam shots are analyzed using a
special UFILE containing data vs time and "channel no." where each
channel specifies a power, or voltage, or energy fraction time trace
for a beam firing in the shot. To use this method of inputting the
TFTR neutral beam data into TRANSP, the TFTR neutral beam waveform
data must be correct on the VAX. Prepare a namelist for a TFTR
TRANSP run in the area WORK:[TRANSP.TFTR]. Then run the program
EXE:NBFILE.EXE and specify the run id. Interactively specify use
of waveforms; individual waveforms may be turned on and off if
necessary. NBFILE.EXE will create the NB2 UFILE containing the
neutral beam data (including estimated energy fraction data). The
Namelist must contain geometry constants for all beams. Old-style
namelists must be converted with nblist.
RF antenna powers (watts) vs. time and antenna number may be input
via the RFP 2d UFILE. If the file is 1d, it is assumed that it
there is only one antenna and the file contains the power on this
antenna as a function of time.
RF frequencies (Hz) vs. time and antenna number may be input
via the RFF 2d UFILE. If the file is 1d, it is assumed that it
there is only one antenna and the file contains the frequency
on this antenna as a function of time.
There several flavors of "moments Ufiles" for specifying the
evolution of the plasma boundary (or interior) geometry.
Set TRDAT namelist variables PRExxx and EXTxxx to request the data
type for input.
TRANSP loads the boundary data via subroutine PLPARM (PLPRMF.FOR)
and the processing is handled via the GFRAM0/GFRAME subroutines
(see information under Code_Structure key).
Traditional (1980s) up-down SYMMETRIC boundary Ufile set:
xxx description units notes
--- ------------------------------------ ----- -----
RM0 0th R moment vs. time only (1d) cm B,N
RMM higher order R moments vs. time and
moment number (1d or 2d UFILE) cm B,N
YMM higher order Y moments vs. time and
moment number (1d or 2d UFILE) cm B,N
Up-down ASYMMETRIC boundary Ufile set (a single 3d Ufile, usually
generated by TRANSP's `scruncher' program):
xxx description units notes
--- ------------------------------------ ----- -----
MRY complete {R,Z} boundary moments set cm
For LEVGEO=8, a complete moment-based equilibrium geometry is
specified as a 3d Ufile, produced by TRANSP's `scrunch2' program,
and TRANSP does not have to solve the MHD equilibrium:
xxx description units notes
--- ------------------------------------ ----- -----
MMX all {R,Z} equilibrium moments cm
--OR (also available via `scrunch2' --
xxx description units notes
--- ------------------------------------ ----- -----
RFS R(theta,x) of flux surfaces cm
ZFS Z(theta,x) of flux surfaces cm
The set {RM0,RMM,YMM} is required by LEVGEO=5 (updown symmetric VMEC).
The updown asymmetric solvers (LEVGEO=6,7,9,10,...) can use any of the
above sets; if MMX is specified only the boundary moments are used; if
{RFS,ZFS} is used, boundary moments are derived from the x=1 (R,Z)
contour.
For LEVGEO=8, where the entire equilibrium is input, either the MMX
file or the {RFS,ZFS} pair of files must be provided.
NOTES referenced in the TRANSP input UFILE data type descriptions
A - see TRANSP namelist info, re. MAGNETICS
B - see TRANSP namelist info, re. GEOMETRY_LEVEL. Major and
Minor radii and beta, li/2+beta data valid for circular
bdy geometry only (LEVGEO .LE. 2)
C - see TRANSP namelist info re. ELECTRON_DENSITY
D - line integral density is from an interferometer measurement
of some sort. If the wavelength of the interferometer is not
specified in CM as scalar "LAMDA:" in the UFILE, it must be
specified through the TRDAT namelist variable DLAMDA.
E - see TRANSP namelist info re. ELECTRON_TEMPERATURE
F - see TRANSP namelist info re. ION_TEMPERATURE
G - see TRANSP namelist info re. PLASMA_COMPOSITION
H - see TRANSP namelist info re. PTCL_BALANCE&neutrals
J - see TRANSP namelist info re. ION_PWR_BALANCE (conduction)
K - see TRANSP namelist info re. ROTATION
L - if time dependent profile data is not available a 1d UFILE
vs. position coordinate only may be substituted. Then the
profile shape is fixed for the duration of the TRANSP run.
M - see TRANSP namelist info re. POWER_RADIATED. A 1d UFILE
vs. TIME may be used as a "wide angle" measurement. A flat
radiation profile shape will be assumed.
N - 1d UFILES each contain single bdy R or Y moments vs. time.
2d UFILES contain a sequence of either R or Y moments vs.
time. The 2d files must be organized time contiguous with
order 1st, 2nd, ... nth moment. Using 1d UFILES for the
RMM and YMM inputs provides a convenient means of specifying
a time evolving elliptical boundary.
...new Aug 1986...
P - list of sawtooth event times as calculated by the pattern
recognition code EXE:SAWTOO.EXE based on analysis of a trace
of ECE or x-ray data. See namelist info re. SAWTOOTH_MODEL
Q - Ti and/or conductivity *profile* data may now be accepted for
*time and space* dependent setting of ion conductivity for the
ion power balance. See namelist info re. ION_PWR_BALANCE.
R - TFTR only. See special section on neutral beam data.
...new June 1987...
S - Conductivity (thermal diffusivity) profile data may now be
read from a UFILE, to be used to PREDICT the evolution of
electron temperature. Te measured (UFILE) input data is
still required (a) to provide initial and bdy conditions;
(b) for comparison to predicted result. See ELEC_PWR_BALANCE
options under description of the namelist. Conductivity
UFILEs may be extracted from TRANSP analysis runs using the
RPLOT program. **Write such UFILES in ASCII to avoid loss
of data resolution to binary digitization/compression.
...new Feb 1989...
T - see TRANSP namelist info re. MINORITY_ION_DENSITY
...new Jan 1990
U - input of Ufile data containing Bp/Bt vs. t,R, i.e. the tangent
of the angle of the field lines vs. time and midplane major
radius, permits generation of a comparison with the result of
the TRANSP poloidal field simulation -- see RPLOT profile
multigraph. The comparison will be aided if the Ufile data
follows this sign convention: Bp/Bt .gt. 0 if R.gt.Raxis,
.le. 0 otherwise; Raxis = radius on midplane where Bp=0.
The TRDAT program has been rewritten to take advantage of the new
code generator TRDATGEN. This makes it far easier to add new input
data types to TRANSP.
See section on documentation (misc/trdatgen.spec).
All data types, including time series data types, are identified
by three character "trigraphs". For example, "CUR" is the
trigraph for the time series data type giving the total plasma
current, amps, vs time.
For a given data type "XYZ", specify the TRDAT namelist quantities
PREXYZ='<Ufile prefix>'
EXTXYZ='<Ufile suffix>'
To set the prefix and suffix of the Ufile name. If these quantities
are set, TRDAT will try to read and process the XYZ data using the
named Ufile (see section on Ufile_names for information on the
shot number and input disk and directory of the Ufile). Although
TRDAT will read the data and make it available to TRANSP, this
does not always guarantee TRANSP will use it. Sometime an
additional switch needs to be set to tell TRANSP whether to use
the data or just pass it on to RPLOT for comparison to a model
calculation.
If the XYZ data is subject to discontinuous changes at sawtooth or
pellet events, see the sections on sawteeth, pellets, and
event_handling.
All data types, including profile data types, are identified
by three character "trigraphs". For example, "NER" is the
trigraph for the profile data type giving the plasma electron
density, ptcls/cm3, as a function of time and radius.
For a given data type "XYZ", specify the TRDAT namelist quantities
PREXYZ='<Ufile prefix>'
EXTXYZ='<Ufile suffix>'
To set the prefix and suffix of the Ufile name. If these quantities
are set, TRDAT will try to read and process the XYZ data using the
named Ufile (see section on Ufile_names for information on the
shot number and input disk and directory of the Ufile). Although
TRDAT will read the data and make it available to TRANSP, this
does not always guarantee TRANSP will use it. Sometime an
additional switch needs to be set to tell TRANSP whether to use
the data or just pass it on to RPLOT for comparison to a model
calculation.
If the XYZ data is subject to discontinuous changes at sawtooth or
pellet events, see the sections on sawteeth, pellets, and
event_handling.
Use of profile data requires specification of the spatial range
covered in the input Ufile (see "Range_specification"). TRDAT
checks that the data in fact covers the claimed range specification.
The severity of this check is determined by taking the minimum of
the "global" TRDAT control RMJCHK and the XYZ-specific control
XRCXYZ. The default is RMJCHK=XRCXYZ=1.0 which sets TRDAT to
impose the most stringent requirement on coverage of plasma range.
Set
XRCXYZ = <a non-negative number less than one>
to reduce the stringency of the range coverage constraint and allow
greater extrapolation, for the XYZ data. Set
XRCXYZ = <a negative number>
to entirely suppress the range converage constraint for XYZ.
For more details see the subkey RANGE_CHECK.
Similarly, set RMJCHK to a number less than one to relax the range
coverage constraint for ALL TYPES OF PROFILE INPUT DATA.
Summary of TRANSP namelist impact of using profile data:
Whenever profile data is to be used, the range specification control
NRIxxx must be set. If NRIxxx specifies two-sided symmetrizable
data, then the symmetrization control NSYxxx must also be set to
select the symmetrization algorithm. See "Range_specification...".
The resolution (number of points) of the interpolation/extrapolation
of the data may be controlled by setting the control NXxxx, if for
some reason the default resolution is inadequate. NOTE -- because
of the need for compatibility with old TRANSP namelists, sometimes
alternates to the name NXxxx are supported. For example, for NER
either namelist control NXNE0 or NXNER may be used to specify the
resolution of the interpolation of the NER (electron density) data.
List of supported nonstandard names as of April 1992:
nonstandard name standard name
================ =============
NXNE0 NXNER
NXTE0 NXTER
NXZEF2 NXZF2
NXNM0 NXNMR
Users are urged to use the standard names, but old namelists with
the old names will work OK.
TRANSP accepts several "profile evolution" Ufiles, i.e. Ufiles
which give the time evolution of a profile measurement of a
plasma parameter. Such Ufiles contain 2 independent coordinates,
one of which must be time. The definition of the other coordinate
giving the spatial dependence is set by the namelist control NRIxxx
(where xxx is the TRANSP/TRDAT trigraph for the input data type).
The following options are available:
NRIxxx=1 --> data vs. midplane major radius R covering range
R0 to R0+a -- covering the "outer half" of the plasma
NRIxxx=-1 --> data vs. normalized radius x=(R-R0)/a (0.0 to 1.0)
covering the outer half of the plasma.
NRIxxx=2 --> data vs. midplane major radius R covering range
R0-a to R0+shift -- covering the "inner half" of the
plasma, ideally allowing for outward shift of axis.
NRIxxx=-2 --> data vs. normalized radius x=(R-R0)/a (-1.0 to 0.0)
covering the inner half of the plasma.
NRIxxx=3 --> data vs. midplane major radius R covering the whole
plasma from R0-a to R0+a.
NRIxxx=-3 --> data vs. normalized radius x=(R-R0)/a (-1.0 to +1.0)
covering the both sides of the plasma.
if NRIxxx= +/- 3, NSYxxx must also be set to specify the
symmetrization algorithm-- see the section
TRANSPHELP OPER NAMELIST DATA_SYMMETRIZATION
NRIxxx=4 --> data vs. minor radius r covering range 0 to a.
NRIxxx=-4 --> data vs. normalized minor radius r/a covering range
0.0 to 1.0
*UPDATED* 7 Feb 2002 (DMC)
Flux coordinate options -- summary:
NRIxxx=+/-5 -> data x axis is SQRT(normalized TOROIDAL flux)
NRIxxx=+/-6 -> data x axis is normalized POLOIDAL flux
NRIxxx=+/-7 -> data x axis is SQRT(normalized POLOIDAL flux)
NRIxxx=+/-8 -> data x axis is normalized TOROIDAL flux
Details...
NRIxxx=5 --> same as NRIxxx=-5
NRIxxx=-5 --> data vs. flux coordinate xi = SQRT(tflux/tfluxbdy)
where tflux = the toroidal flux enclosed by the
surface labeled by xi, and tfluxbdy is the total
toroidal flux enclosed within the surface defining
the plasma boundary. xi is used internally in
TRANSP to label flux surfaces; xi ranges from 0
(the magnetic axis) to 1 (the plasma boundary).
NRIxxx=6 --> same as NRIxxx=-6
NRIxxx=-6 --> data vs. flux coordanate psi =
psipol/psipol(bdy) , where psipol = the
poloidal flux enclosed within the surface, and
psipol(bdy) the poloidal flux enclosed within the
bounding surface; psi ranges from 0 to 1.
caution: points must be finely spaced near psi=0
to get good spatial resolution near the magnetic
axis.
NRIxxx=7 --> same as NRIxxx=-7
NRIxxx=-7 --> data vs. flux coordinate xpsi=SQRT(psipol/psipol(bdy)),
where psipol = the poloidal flux enclosed within the
surface, and psipol(bdy) the poloidal flux enclosed
within the bounding surface; xpsi ranges from 0 to 1.
NRIxxx=8 --> same as NRIxxx=-8
NRIxxx=-8 --> data vs. flux coordinate psitor = tflux/tfluxbdy
where tflux = the toroidal flux enclosed by the
surface, and tfluxbdy is the total toroidal flux
enclosed within the surface defining the plasma
boundary.
caution: points must be finely spaced near psitor=0
to get good spatial resolution near the magnetic
axis.
(NOTE: NRIxxx and NSYxxx go in the TRANSP namelist, not the
TRDAT namelist -- this information is needed by TRANSP as well
as TRDAT).
Note that in general TRANSP supports analysis of data with time
dependent geometry. Input profile data must actually have the
claimed plasma coverage **at all times** in the analysis. However,
if the data time range does not cover the analysis time range,
TRDAT will extrapolate it in time flat along lines of constant
x = (R-R0)/a.
If an input profile Ufile contains only one coordinate, this is
usually interpreted as requesting use of the same profile
information at all times in the analysis. (Exception: bolometer
data and any other data for which /fallback_to_timeseries is set
in misc/trdatgen.spec). CAUTION-- if time independent profile
Ufiles are used, then the plasma position or boundary should also
be time independent or at least nearly so.
TRDAT imposes range coverage requirements on input Ufile data,
depending on the Ufile range coverage specification control
NRIxxx.
The default is that the data must "come close" to covering the
specified range at all times in the analysis. This requirement
can be relaxed by setting the TRDAT namelist input XRCxxx to a
number less than one; it can be turned off entirely by setting
the input XRCxxx to a number less than zero.
The following table gives coverage requirements for XRCxxx=1.0
and XRCxxx=0.0, in terms of the normalized major radius
coordinate x = (R-R0)/a, where R0 and a are the plasma major
and minor radii defined on the plasma midplane:
x=(R-R0)/a x=(R-R0)/a x=(R-R0)/a
NRIxxx ideal range requirement range requirement
value coverage XRCxxx=1.0 XRCxxx=0.0
====== ========= ================= =================
+/- 1 0 to +1 0.1 to 0.9 0.5 to 0.5
+/- 2 -1 to axis -0.9 to 0.0 -0.5 to -0.1
+/- 3 -1 to +1 -0.9 to 0.9 -0.5 to 0.5
+/- 4 0 to +1 0.2 to 0.9 0.5 to 0.5
+/- 5 [not checked -- already mapped]
+/- 6 [not checked.]
note that for NRIxxx=2, the data should ideally reach far
enough over in radius to cover the magnetic axis; because
of "Shafranov Shift" this usually is a positive value of x.
The namelist default value of XRCxxx is 1.0. For namelist
values of XRCxxx between 1.0 and 0.0, a cover requirement
intermediate to the ranges shown above is taken.
A global range check relaxation control RMJCHK is also
available, but its use is not recommended.
These controls provide for profile data renormalization IN TRDAT.
All renormalizations default "off".
NLRNNE - set .TRUE. to renormalize density profile data IN TRDAT.
DLAMDA - line density interferometer wavelength, cm. required if
scalar "LAMDA:" is not in LID UFILE.
XDGLID - option to reduce or eliminate use of edge data (beyond
nominal plasma bdy) in computing the ne renormalization.
default: any edge data provided is used, XDGLID=large.
Set XDGLID=1.0 to prevent use of any profile data beyond
r/a=1.0; set XDGLID=1.05 to prevent use of any data
beyond r/a=1.05, etc.
NLRNTE - set .TRUE. to renormalize electron temperature profile data
(TER) or (ECF) to scalar data (TET) in TRDAT. Additional
control available via TRDAT namelist inputs XFRTE and
RMJRTE:
RMJRTE = major radius location of time series data
being used to normalize the profile. This
radius must be in the range of the profile
data and of the plasma. If defaulted, the
peak value of the profile is renormalized
to match the time series data
XFRTE = renormalization adjustment. XFRTE=1.0 by
default. If TER is the profile data and
TET is the scalar data, then the factor of
renormalization is
ZNORM = 1 + [TET/TER(RMJRTE) - 1] * XFRTE
at each time; i.e. XFRTE=0.5 causes a
renormalization to a data value half way
between the profile data and the renormal-
izing time series data; XFRTE=0.0 would be
a complicated way of turning off the
renormalization.
NLRNTI - set .TRUE. to renormalize the ion temperature profile data
(TIR) to scalar data (TIT) in TRDAT. Additional controls
RMJRTI and XFRTI are defined analogously to RMJRTE and
XFRTE.
NLRNVP - set .TRUE. to renormalize the rotation profile data
(VP2) to scalar data (VPH) in TRDAT. Additional controls
RMJRVP and XFRVP are defined analogously to RMJRTE and
XFRTE. CAUTION-- since VPH and VP2 can be zero, an
"additive" rather than multiplicative renormalization
algorithm is attempted. It is recommended that RMJRVP
be set. This option has not been extensively tested.
If a TRANSP run includes pellet injection then, for each pellet, a
"hazard time interval" should be input to TRDAT to specify the time
range about the pellet injection time during which none of the UFILE
input data should be trusted. TRDAT will extrapolate all UFILE data
forward/back to the pellet time(s) based on data values and time
derivatives at the endpoints of the hazard interval(s)-- except as
modified, cf section on event_handling.
In the TRDAT namelist,
TPELDA(1,J) = LAST VALID TIME for input UFILE data PRECEDING
injection of the Jth PELLET.
TPELDA(2,J) = FIRST VALID TIME for input UFILE data FOLLOWING
injection of the Jth PELLET.
NOTES:
1. The time interval TPELDA(1,J) to TPELDA(2,J) must enclose an
actual pellet event as specified in the TRANSP namelist. See
TRANSP namelist info on PELLETS.
2. The hazard intervals must be bounded away from the start and
stop times of the TRANSP analysis (TRANSP namelist variables
TINIT, FTIME). These intervals may not overlap.
3. TPELDA controls do not have to be set for ablation simulations;
they are only needed if there is an actual pellet event in the
data.
The TRANSP namelist switch DTSAWD specifies a data "safety interval"
of +/- DTSAWD seconds around each sawtooth event. Except as modified
by explicit namelist control, Ufile data which falls within the
safety interval will not be used (if the Ufile is subject to event
discontinuities). Data in this range will be extrapolated linearly
from surrounding data to the actual sawtooth event time, where
a discontinuity will be formed. This is essentially the same
treatment as is given for pellet events.
TRDAT data types which in their definition in misc/trdatgen.spec
include the switch /event_discontinuity are subject to event
handling code which uses flat or linear extrapolation to enhance
event discontinuities in the data.
(See the sections PELLETS, SAWTEETH).
New *** you can change the time extrapolation method used for
events. See the extrapolation subtopic.
The extrapolation windows are by default defined for all diagnostics
with the /event_discontuity characteristic; this includes mainly
all temperature, density, and Zeff related data. For individual
event sensitive diagnostic data type ABC, the extrapolation window
may be INCREASED by setting
XDTABC = <wider extrapolation window, seconds>.
This means that the ABC data within +/- XDTABC of any event is not
to be used, and that the event extrapolation is to cover this wider
range.
Event extrapolation can be disabled over several time ranges by
setting
XTMABC = time1a,time2a, time1b,time2b, ...
Where the time ranges (time1a,time2a), etc., must be specified in
ascending order without overlap and time2a .gt. time1a is required.
All times are in seconds.
Default extrapolation forward/back to events from outside the
event window is *linear*.
You can instead choose flat extrapolation, or some weighted
average between linear and flat. The namelist controls for
this are in the TRDAT namelist. There is one set of controls
for sawteeth events and one set for pellet events. In each
set there is one global control that modifies the default
extrapolation for all diagnostics, and then there is a
specialized control for each diagnostic which is subject
to event handling (i.e. temperatures, densities, Zeff
related information, neutrons, surface voltage).
Each control accepts a floating point number between
0.0 and 1.0. 1.0 means linear extrapolation, 0.0 means
flat extrapolation, something inbetween means something
inbetween extrapolation.
The TRDAT namelist controls are:
Pellets:
XXTPEL (default 1.0) -- global control for all diagnostics.
XTPaaa (default out of range) -- specific control for
diagnostic aaa. If defaulted or given a value not
between 0.0 and 1.0 inclusive, the control is ignored
and the global control is used for diagnostic aaa.
Sawteeth:
XXTSAW (default 1.0) -- global control for all diagnostics.
XTSaaa (default out of range) -- specific control for
diagnostic aaa. Works same as XTPaaa.
If the run includes sawtooth or pellet events and extrapolation
is not disabled for a given data type ABC, then, the original Ufile
data that falls within the extrapolation windows bracketing events
is NEVER USED. Extrapolation is based on "good" data that falls
outside event windows. To do a normal linear extrapolation, there
must be at least two good data points between event windows. If
this condition is not satisfied, TRDAT will produce warnings and
a fallback extrapolation scheme will be used:
* if there is one good data point, that data will apply between
surrounding events with no time variation, creating step-
function-like time dependence in the processed data.
* if there are no good data points, data from before the preceding
or from after the following event will be copied; there will
be a discontinuity at only one of the (2 or more) events with
no intervening valid data. Pellet events will be selected
over sawtooth events for "receiving" the discontinuity, but
if there are multiple pellet events or no pellet events
involved the discontinuity will be placed arbitrarily.
(A further elucidation is given in the comments to the TRDAT
subroutine trdatusub/setupel.for).
These additional controls are available in the TRDAT namelist.
TIME0 Time of start of plasma (=0.0 normally, =40.0 for JET!)
- this number is subtracted from the timebase of all
input Ufiles; TRANSP wants t=0.0 = time of start of
plasma.
XTEND - distance (in normalized spatial coordinate x=(R-R0)/a )
to extend the data beyond the plasma boundary. The
default is XTEND=0.05, which is normally adequate.
PCURI - input fixed plasma current (amps). If no UFILE available.
VSURI - input fixed surface voltage (volts). If no UFILE available.
TLIM1 -- ignore all Ufile data before time t=TLIM1. The data at
t=TLIM1 is extrapolated back flat in time.
TLIM2 -- ignore all Ufile data after time t=TLIM2. The data at
t=TLIM2 is extrapolated forward flat in time.
In March 1992 a new TRDAT was installed. The new TRDAT namelist is
NOT STRICTLY COMPATIBLE with the old namelist; some anachronisms
have been cleaned up.
Therefore, if an old TRANSP namelist is to be re-used it will have
to be converted first!
This conversion can usually be done automatically using the program
EXE:FIXNL.EXE
just run this program in the directory in which the faulty namelist
resides and give the run id imbedded in the namelist filename.
If FIXNL cannot fix the namelist, consult D. McCune for help.
At non-PPPL sites, the new TRDAT and FIXNL arrived with the
February 1994 release of TRANSP.
(New June 1999)
You can specify a (non-default) source for the TRANSP run's
expert module ("SUBROUTINE EXPERT") by setting the trdat namelist
variable
expert_file
to a string containing the full path to the desired source file.
This causes a copy from the indicated source file that overwrites
any pre-existing <runid>EX.FOR file. The write is done when TRDAT
writes its physics data output file.
NOTE -- expert files contain subroutines that modify TRANSP operation.
It is not easy to get these to do so correctly; if in doubt seek help
from a TRANSP expert.
NOTE ALSO -- in March 2005, the TRANSP code switched from a COMMON-
based internal communications mechanism "include 'TRCOM'" to a
fortran-90 based equivalent mechanism "use trcom". EXPERT modules
written in the old style will not work.
TRANSP input can also be specified by reference to a properly prepared
MDSplus TRANSP input tree.
** this section to be updated (dmcApr16) **
The following general observations about TRANSP coordinates and
mapping options of profile input data were written in response to
a query from the JET group -- D. McCune 24 Sep 2003.
(a) the internal TRANSP radial coordinate "XI" is sqrt(Phi/Philim)
where Phi is the toroidal flux enclosed within a surface, and
Philim the toroidal flux enclosed within the boundary.
(b) The X and XB (seen in the TRANSP output and e.g. by the "rplot"
program that comes with TRANSP for looking at output data) is
also sqrt(Phi/Philim).
(c) TRANSP has a front end program, "trdat", which reads in data
signals-- the measured input data for the TRANSP run.
(d) The trdat program does NOT use sqrt(Phi/Philim), because, it
does not have an MHD equilibrium available to it. However, TRANSP
is a "prescribed boundary" code, and so, TRDAT does know the boundary
of the outermost flux surface. Accordingly, it defines a midplane
mapping coordinate defined in terms of major radii and the boundary
surface half-width:
x_trdat(R_mp) = (R_mp-R0_mp)/a_mp
where
R0_mp = (R_outer + R_inner)/2
a_mp = (R_outer - R_inner)/2
R_outer = outer (large R) midplane intercept of outermost
flux surface (the bdy)
R_inner = inner (small R) midplane intercept of outermost
flux surface (the bdy)
are all functions of the time varying prescribed plasma boundary
contour. x_trdat, by definition, covers the fixed range [-1,1].
(e) There are a variety of options for specifying the spatial coordinate
of TRANSP profile input data (NRIxxx namelist options for profile
xxx), as described in the TRANSP help. Several of these indicate
variation against major radius (R_mp) with stipulation of coverage
of either the inside half, outside half, or both sides of the plasma
column. Such profiles are mapped by trdat to x_trdat. Subsequently
inside TRANSP, when the full MHD equilibrium is known, these are
mapped to XI flux surfaces; two-sided data is "symmetrized" by
one of two namelist selectable algorithms.
(f) TRANSP profile input data can also be given as functions of normalized
sqrt-toroidal or poloidal flux. For such data, x_trdat is not used.
The profile's flux grid is passed directly to TRANSP, and then
interpolated to the TRANSP grid (evenly spaced in sqrt-toroidal flux,
not evenly spaced and with internal time variation in poloidal flux).
(g) A special mapping for ECE electron temperature data allows these
profiles to be specified directly as functions of EC frequency.
This allows the mapping to flux surface to be deferred until the
MHD equilibrium and field are known.
TRANSP supports several levels of plasma (MHD flux surface)
geometry. The selection is made via namelist integer switch
LEVGEO. The supported levels are:
DMC Jan 2003 -- LEVGEO=0 & LEVGEO=1 are no longer supported!
LEVGEO=0: simplest model. Plasma flux surfaces are taken as
concentric toroids of circular cross section, with the major and
minor radius of the outermost surface fixed in time (specify via
namelist inputs RMINOR and RMAJOR, or specify UFILEs inputs of
major and minor radius vs. time which will be time averaged--
time variation ignored). Specify the toroidal field by setting
namelist quantity BZ = external toroidal field (tesla) at RMAJOR.
LEVGEO=1: geometry as in LEVGEO=0, except that major and minor
radius of outermost surface, and toroidal field, are functions of
time. UFILEs are needed for: major and minor radius vs time;
external field vs. time specified in form R*Btoroidal, Tesla*cm.
LEVGEO=2: boundary as in LEVGEO=1 (same UFILEs data required),
but a Shafranov style MHD calculation is done to estimate the
shift of interior (assumed circular) surfaces relative to the
outer surface. This shift information is then used in the
throughout the code. Note that the surface cross-sections
are still circular.
LEVGEO=3: [no longer available.] The original version of VMEC
(c.f. LEVGEO=5, below) ... known as EQ2D. These runs now use
LEVGEO=5.
LEVGEO=4: [no longer available.] LEVGEO=4 runs now use VMEC
(LEVGEO=5). This option used to invoke the VMOMS equilibrium
solver (1987).
LEVGEO=5: The plasma boundary may be non circular and is input in
"scrunched" Fourier moments form as time dependent UFILEs
("scrunching" indicates a particular theta parametrization for
the moments expansion. For PBX the "scrunching" is done in
program [TRANSP.PBX.DATA]MOMGET.). The external field is input as
with LEVGEO=1 or 2. The internal plasma geometry is generated
with a full 2d MHD equilibrium calculation.
LEVGEO=6: The plasma boundary may be non circular <AND> up-down
asymmetric (e.g., JET, DIII-D, etc.). It is input in "scrunched"
Fourier moments form as a single time dependent 3D UFILE.
"Scrunching" indicates a particular optimal theta parametrization
for the moments expansion. It is obtained by running
SCRUNCHER.. The external field is input as with LEVGEO=1 or 2. The
internal plasma geometry is generated with a full 2d MHD
equilibrium calculation.
LEVGEO=7: This option has been indefinitely disabled as of 26Mar2008
and will force LEVGEO=11 (TEQ) to be used instead. [The ESC code
(Leonid Zakharov, Alex Pletzer) -- see the subtopic.]
LEVGEO=8: *** The entire Equilibrium is input data from SCRUNCH2 ***
LEVGEO=9: The JSOLVER code -- see the subtopic.
LEVGEO=10: This option has been indefinitely disabled as of 26Mar2008
and will force LEVGEO=11 (TEQ) to be used instead. [The Rzsolver code
(A Pletzer). Solves the Grad-Shafranov equation in (R,Z) coordinates.
Also invoked in rescue mode when Esc (LEVGEO=7) fails to converge.
Rzsolver may not be available on all sites; the code has some external
dependencies (Python modules) that don't ship with Transp. See
rzsolver.doc for installation notes.]
LEVGEO=11: TEQ from Larence Livermore National Laboratory
Input data to these MHD solvers are:
required:
external field (UFILES data -- R*Bz) vs. time
plasma boundary (UFILES data -- Fourier moments set) vs. time
optional Ufiles:
q profile (equiv. current profile) from the poloidal field solver.
Pressure profile (or Beta) from kinetic data, fast ion modeling,
and power balance calculations.
For LEVGEO=8, the Ufiles output by scrunch2, specifying the entire
equilibrium, are required.
Output data are: a full metric solution to the MHD fixed
boundary problem, including interior flux surface locations, and
"g function" i.e. para/diamagnetic correction to the toroidal
field due to poloidal plasma current.
NSCRUNCH_OPT-[INT] if set nonzero then the flux surfaces will be scrunched
so poloidal flux lines are separated by equal arc lengths. The number
of moments used internally (NMOM) will be reset to the maximal permissible
value. Available for TEQ(LEVGEO=11).
This option corresponds to a very old version of VMEC which has
been superseded by the LEVGEO=5 version.
LEVGEO=3 runs are treated with LEVGEO=5.
VMOMS is no longer available in TRANSP.
LEVGEO=4 runs are treated with LEVGEO=5.
This code (VMEC = Variational Moments Equilibrium Code) was
written by Steve Hirshman of ORNL. In its full glory it solves
the full 3-d mhd equilibrium equations for arbitrary geometry.
Dick Wieland and Steve Hirshman have truncated to a 2-d code
suitable for modeling tokamak geometries of arbitrary moment and
adapted it to TRANSP. Its description follows.
1. It is a fixed boundary code; the plasma boundary prescribed by a
set of Fourier coefficients in R and Y. [Cf. Namelist inputs for
specifying the RM0,RMM,and YMM ufile inputs, respectively.]
2. It works on an equi-spaced "s" grid, where "s" corresponds to the
normalized toroidal flux. Note that this is different from the
TRANSP "radial" grid, which corresponds to "xi", the square root of
toroidal flux. This stretching of coordinates leads to greater
radial resolution at the edge, which is an advantage for high beta
plasmas where the q profile increases rapidly at the edge.
3. It uses the steepest descent method to find a force balance
solution to the MHD equations.
4. It requires as input :
a> Fourier specification of the plasma boundary
b> enclosed toroidal flux
c> pressure profile p(s)
d> iota-bar profile i(s)
Note that this implies that i(s), or q, is "conserved".
5. It can handle pressure anisotropies IN PRINCIPLE. The stand-alone
version, which mimics a TRANSP-driven environment, has options for
invoking the anisotropy. The version currently in TRANSP, however,
is purely isotropic.
For references, cf.
a> S.P.Hirshman and J.C.Whitson, PHYS.FLUIDS 26, 3553 (1983).
b> S.P.Hirshman and H.K.Meier, PHYS.FLUIDS 28, 1387 (1985).
c> S.P.Hirshman and D.K.Lee, COMP.PHYS.COMM. 39, 161 (1986).
7. Sources for TRANSP VMEC can be found in the TRANSP CMS library
under Group VMEC_SRC. Sources for the Standalone version are
under Group VMEC_STANDALONE.
There are a number of namelist variables that control various
aspects of its operation. They are described below. [#NYI# means
"not yet implemented"]. Default values, as defined in "port.for"
are shown in parentheses.
VMCEXPF-[REAL] TENSOR CODE- PRESSURE GOES LIKE
BMOD**EXPF (1.0) #NYI#
VMCFTOLA-[REAL(10)] CONVERGENCE ARRAY
(1) => RELATIVE CONVERGENCE OF FSQ - FORCE BALANCE (1.E-9)
(2) => RELATIVE CONVERGENCE OF BETAP - BETA POLOIDAL (5.E-4)
(3) => RELATIVE CONVERGENCE OF R00 - MAGNETIC AXIS (5.E-4)
(4) => ( >0) RELATIVE CONVERGENCE OF IP - TOROIDAL CURRENT
( <0) ABSOLUTE CONVERGENCE WRT EXPIP (1.E-3)
"RELATIVE CONVERGENCE" MEANS HOW HAS THE
PARTICULAR PARAMETER CHANGED SINCE THE
LAST ITERATION
"ABSOLUTE CONVERGENCE" MEANS HOW CLOSE IS THE
CALCULATED VALUE TO THE VALUE OF IP AT THE
TARGET TIME STEP?
FOR DETAILS ON THE CONVERGENCE ALGORITHM,
CF. VMCCNVRG.FOR
NVMCDATA-[INT][IN] MODE OF OPERATION FLAG (1)
=0 => RUN WITH NAMELIST INPUT (STANDALONE)
=1 => USE TRANSP ISOTROPIC PRESSURE
=2 => USE TRANSP ANISOTROPIC PRESSURE (#NYI)
VMCANISO-[REAL][IN] [NVMCDATA=1 ONLY] (1)
=0 => PPERP=PPARL=PRES(S) - ISOTROPIC
>0 => SIMULATE ANISOTROPIC USING ISOTROPIC
-PPAR= PRES(S)*(B/B0)**VMCANISO
-PPERP=PPAR*(1.-VMCANISO)
NVMCNINT-[INT] GRID SIZE FOR SOLVING INITIAL GUESS (10)
NVMCITER-[INT(10)] ITERATION LIMIT ARRAY
(1) MAX # OF ITERATIONS ALLOWED IN INITIAL (GUESS) LOOP (3000)
(2) MAX # OF ITERATIONS ALLOWED IN MAIN (RESTART) LOOP (5000)
NVMCORDR-[INT] [NVMCDATA=2 ONLY]
ORDER OF P(BMOD) FIT (#NYI#) (1)
NVMCSTEP-[INT] NUMBER OF TIMESTEPS BETWEEN : (100)
- CONVERGENCE TESTS
- PRINTOUTS
VMCPEXP-[REAL] EXPONENT IN THE <M> CRITERION ADDED TO FORCE (4.0)
BALANCE TO MINIMIZE FOURIER SPECTRUM
A WORD OR TWO HERE ABOUT THE WAY IN WHICH THE CONVERGENCE TESTS
ARE IMPLEMENTED. EXTENSIVE STANDALONE TESTS INDICATE THAT OF ALL
THE POSSIBLE METRICS TO SCAN IN TRYING TO ASCERTAIN THE DEGREE OF
CONVERGENCE (E.G., FORCE BALANCE(FSQ), BETA POLOIDAL(BETAP), THE
POSITION OF THE MAGETIC AXIS (R00), AND THE NET TOROIDAL
CURRENT(IP) ) IP IS BY FAR THE MOST SENSITIVE. THE USER CAN
REQUEST IP CONVERGENCE IN A RELATIVE SENSE OR IN AN ABSOLUTE
SENSE, IN WHICH CASE COMPARISON IS MADE WITH THE TARGET IP. THIS
ABSOLUTE OPTION IS NOT RECOMMENDED. THE NATURE OF THE
BOOTSTRAPPING BETWEEN MAGDIF AND VMEC IS SUCH THAT THE TARGET IP
CANNOT ALWAYS BE SATISFIED. THE RELATIVE OPTION IS RECOMMENDED.
ALL THE ABOVE MENTIONED CONVERGENCE METRICS ARE TESTED BY AND-ING
THEM TOGETHER.
IF PROBLEMS OCCUR IN VMEC, SUCH AS AN INABILITY TO CONVERGE TO A
SOLUTION, THENAN ADJUSTMENT OF ONE OR MORE OF THE ABOVE NAMELIST
VARIABLES MAY BE NECESSARY. WHAT FOLLOWS IS A ROUGH GUIDE TO WHAT
YOU MIGHT TRY.
1> TIGHTEN SOME OR ALL OF THE VMCFTOLA CONVERGENCE ELEMENTS.
2> INCREASE THE NUMBER OF ITERATIONS IN THE NVMCITER ARRAY.
IF PROBLEMS PERSIST, CONTACT a TRANSP expert.
This code (VMEC6 = Variational Moments Equilibrium Code)
is a descendent of the earlier VMEC [Levgeo=5] code described
elsewhere. It has been modified by Steve Hirshman and Dick Wieland
to be able to handle up-down asymmetric plasmas, as well as the
more mundane up-down symmetric types. At a cost of about a factor of
3 or 4 in CPU execution time of course.
See VMEC[LEVGEO=5] for details on its operation. What's new or
different is presented below.
1. It requires as input :
a> Fourier specification of the plasma boundary
b> enclosed toroidal flux (Phi-tot) <and> Ip
c> pressure profile p(s)
d> iota-bar profile i(s)
Note that this implies that i(s), or q, is "conserved".
The Phi-tot is used as an initial guess in arriving at a solution
that conserves Ip, by varying Phi-tot.
There is a stand-alone version of VMEC6, called VMEC6SA, that can
run using RPLOT 2d ufiles as input. It can be a useful tool for
diagnosing convergence problems in a TRANSP run. More information
on how to setup the namelist file will appear here soon.
There are a number of namelist variables that control various
aspects of its operation. They are described below. [#NYI# means
"not yet implemented"]. Default values, as defined in "port.for",
are shown in parentheses.
VM6FTOLA-[REAL(10)] CONVERGENCE ARRAY
(1) => RELATIVE CONVERGENCE OF THE FINE GRID FSQ - FORCE BALANCE (1.E-9)
(5) => RELATIVE CONVERGENCE OF THE COARSE GRID FSQ - FORCE BALANCE(1.E-6)
##NYI## THE FOLLOWING CONVERGENCE CONDITIONS ARE NOT YET IMPLEMENTED ...
(2) => RELATIVE CONVERGENCE OF BETAP - BETA POLOIDAL (5.E-4)
(3) => RELATIVE CONVERGENCE OF R00 - MAGNETIC AXIS (5.E-4)
(4) => ( >0) RELATIVE CONVERGENCE OF IP - TOROIDAL CURRENT
( <0) ABSOLUTE CONVERGENCE WRT EXPIP (1.E-3)
"RELATIVE CONVERGENCE" MEANS HOW HAS THE
PARTICULAR PARAMETER CHANGED SINCE THE
LAST ITERATION
"ABSOLUTE CONVERGENCE" MEANS HOW CLOSE IS THE
CALCULATED VALUE TO THE VALUE OF IP AT THE
TARGET TIME STEP?
FOR DETAILS ON THE CONVERGENCE ALGORITHM,
CF. VMCCNVRG.FOR
NVM6NINT-[INT] GRID SIZE TO USE IN THE COARSE GRID DESCENT (11)
NVM6NS2 -[INT] GRID SIZE TO USE IN THE FINE GRID DESCENT (31)
NVM6ITER-[INT(10)] ITERATION LIMIT ARRAY
(1) MAX # OF ITERATIONS ALLOWED IN COARSE GRID DESCENT LOOP (500)
(2) MAX # OF ITERATIONS ALLOWED IN FINE GRID DESCENT LOOP (2000)
(9) NVM6NINT to use during STARTUP, or 0, or -1 (0)
(10) NVM6NS2 to use during STARTUP, or 0, or -1 (0)
for NVM6ITER(9) and NVM6ITER(10):
(0 means use the same values as specified for non-startup)
(-1 means use the code defaults: 11 & 31, during startup only)
(positive values give the actual values to use during startup
only; NVM6NINT and NVM6NS2 as given are used for non-startup).
NVMCSTEP-[INT] NUMBER OF TIMESTEPS BETWEEN : (100)
- CONVERGENCE TESTS
- PRINTOUTS
VMCPEXP-[REAL] #NYI#
EXPONENT IN THE <M> CRITERION ADDED TO FORCE (4.0)
BALANCE TO MINIMIZE FOURIER SPECTRUM
NVM6NTH-[INT] #NYI# POLOIDAL GRID SIZE
IF PROBLEMS OCCUR IN VMEC, SUCH AS AN INABILITY TO CONVERGE TO A
SOLUTION, THEN AN ADJUSTMENT OF ONE OR MORE OF THE ABOVE NAMELIST
VARIABLES MAY BE NECESSARY. WHAT FOLLOWS IS A ROUGH GUIDE TO WHAT
YOU MIGHT TRY.
1> TIGHTEN SOME OR ALL OF THE VMCFTOLA CONVERGENCE ELEMENTS.
CHANGE VMCFTOLA[5] FROM 1E-9 TO 1E-11
2> INCREASE THE NUMBER OF ITERATIONS IN THE NVMCITER ARRAY.
IF PROBLEMS PERSIST, CONTACT a TRANSP expert.
BETA ADJUSTMENT. TRANSP normalized pressure (beta) is by default
based on kinetic data. However, Beta is also (indirectly) measured
by magnetics systems and can be input to TRANSP via UFILES as
measured "li/2+beta vs. time" or "diamagnetic beta vs time". If
magnetic and kinetic indicators of beta disagree, it may be desirable
to tie the Beta input to the MHD equilibrium calculations to the
magnetic rather than the kinetic data. The following TRANSP namelist
options exist for this purpose:
XABFAC = anomalous multiplier to apply to Beta before passing it to
the MHD equilibrium code (may be set directly in namelist
NLALAM = .TRUE. to adjust XABFAC as a function of time to make
li/2+beta for MHD consistent with input magnetic data (lamda).
NLABDA = .TRUE. to adjust XABFAC as a function of time to make
beta for MHD consistent with diamagnetic beta data.
XABMIN = minimum allowed XABFAC to constrain feedback adjustment
XABMAX = maximum allowed XABFAC to constrain feedback adjustment
ROTATION BETA ADJUSTMENT: An additional anomaly factor
XUPHIFAC
(default 1.0) can also be used to adjust just the beta
contribution due to plasma toroidal rotation. For a discussion
see "beta.doc" at ftp://ftp.pppl.gov/pub/transp/codata/doc ...
This option has been indefinitely disabled as of 26Mar2008
and will force LEVGEO=11 (TEQ) to be used instead.
(New dmc 14 Aug 2002)
TRANSP now has an option to receive its entire equilibrium from input
data, not computing an internal equilibrium at all.
The program "scrunch2" can extract a time evolving equilibrium via
time dependent contouring analysis of EFIT results that have been
stored in a "standard EFIT MDSplus tree" such as are created in the
NSTX, Cmod and DIII-D experiments in the USA.
NEW DMC Apr 2004: "scrunch2" can also extract and "smooth" the MHD
equilibrium evolution from a prior TRANSP run. This can be a method
to remove or reduce d(geometry)/dt noise in the transport analysis.
Scrunch2 creates the following Ufiles (prefix and path user specified,
prefix = "C" and default filename extensions shown):
_3d Ufile:
Cnnnnn.MMX -- a 3d Ufile containing the full equilibrium evolution,
in scaled Fourier Moments form.
--OR--
Cnnnnn.RFS -- a 3d Ufile, R(t,theta,x) -- explicit flux surface R
Cnnnnn.ZFS -- a 3d Ufile, Z(t,theta,x) -- explicit flux surface Z
(This representation avoids Fourier series truncation error).
_2d Ufiles:
Cnnnnn.QPR -- q(x,t): q profile. Note x = sqrt(phi/philim)
-->important! note x based on Toroidal flux, not Poloidal flux
Cnnnnn.GRB -- g(x,t) = (R*Bt) Tesla*m or Tesla*cm (see below)
Cnnnnn.PRS -- P(x,t) (Pressure profile), pascals
_1d Ufiles:
Cnnnnn.TRF -- total enclosed toroidal flux, Wb, vs. time.
Cnnnnn.PLF -- total enclosed poloidal flux, Wb/rad, vs. time.
When "scrunch2" writes its data, it can write in "TRANSP" mode
(TRANSP units, profiles written time-contiguous), or in its
default "standard" mode which gives the data in MKS
---> "Standard" mode scrunch2 output can be read by TRANSP, but
only if the namelist specifies LFIXUP=2 for automatic units
conversion and time axes swapping. This is recommended, but
will cause problems for Ufile datasets which have units labeling
errors.
SCRUNCH2 results can be used in TRANSP runs with LEVGEO=6,7,8, or 9.
When LEVGEO=6,7, or 9, the VMEC6, ESC or JSOLVER equilibrium solvers
are used and the MMX aor {RFS,ZFS} data specifies the boundary, and the
GRB and PRS Ufiles are passed through for comparison. A comparison of
the Shafranof shift from TRANSP's internal equilibrium and the EFIT-
based MMX or {RFS,ZFS} equilibrium will be generated. The QPR Ufile
can either be passed through for comparison to results from the Poloidal
Field Diffusion equation, or, the current profile can be set directly from
QPR.
By setting LEVGEO=8, one requests that TRANSP not compute an internal
equilibrium at all, but simply use the EFIT results.
Summary of namelist settings to use scrunch2 data:
TRANSP namelist:
LEVGEO=8 ! to use MMX or {RFS,ZFS} for the equilibrium evolution.
! if MMX or {RFS,ZFS} are given but LEVGEO.ne.8, use the full
! equilibrium data just for the boundary.
NRIQPR=5 ! profile inputs given vs. sqrt(phi/philim)
NRIGRB=5 ! i.e. normalized sqrt(TOROIDAL flux)
NRIPRS=5
! warning! some other programs write QPR data vs. POLOIDAL Flux
! NRIQPR=6 will give the WRONG RESULT if used with scrunch2 output.
TRDATA namelist:
LFIXUP=2 ! needed to convert units of "standard" scrunch2 output.
PREMMX,EXTMMX -- Ufile prefix & suffix of MMX data
! MRY or RM0/RMM/YMM data must be turned off!
--OR--
PRERFS,EXTRFS -- Ufile of R(t,theta,x) ! use either MMX or this
PREZFS,EXTZFS -- Ufile of Z(t,theta,x) ! pair, *not* both.
PREQPR,EXTQPR -- (as before) Q profile Ufile pre/suffix
PREGRB,EXTGRB -- (new) (R*Bt) profile Ufile pre/suffix
PREPRS,EXTPRS -- (new) Pressure profile Ufile pre/suffix
PRETRF,EXTTRF -- Total enclosed Toroidal flux vs. time (Ufile)
PREPLF,EXTPLF -- Total enclosed Poloidal flux vs. time (Ufile)
and optionally:
New options in "scrunch2" allow these quantities to be provided:
PREPSI,EXTPSI -- PSI(t,R,Z) external field evolution from EFIT
PRELIM,EXTLIM -- limiter location from EFIT: time invariant
contour (R,Z) expressed as a Z vs. R Ufile.
One final note: TRANSP will evolve a somewhat different pressure
profile than was used by EFIT to prepare the MDSplus tree input
for scrunch2. Also, if the poloidal field diffusion equation is
used, TRANSP will have a different q profile, and in either case
TRANSP gets an internal g (R*Bt) profile from a surface averaged
Grad-Shafranov solution, which will be slightly different than
what EFIT used. Therefore, with LEVGEO=8, TRANSP will definitely
have an equilibrium which is not entirely self-consistent. While
this is generally OK for source/heating codes, it is not OK for
MHD stability codes (but then, TRANSP equilibria are usually not
good enough for these codes even with other LEVGEO options). The
pass-through of g(x,t), q(x,t) and P(x,t) data and total flux
data from EFIT allows a fairly quick assessment of the magnitude
of deviation of the TRANSP profiles and total flux from the ones
used by the EFIT analysis.
The fixed boundary MHD equilibrium code JSOLVER solves the
Grad-Shafranov equation in flux coordinates and takes the pressure
gradient p'(psi)*psimax and the parallel current profiles R j//
defined on a constant poloidal flux psi mesh as input profiles. The
code was originally written by S. Jardin, C. Kessel, J. Menard,
D. Monticello, J. DeLucia and others. More recently (1999), it has
been made portable and dynamically allocatable, thus making it
suitable for implementation into TRANSP. The present version in
TRANSP has been imported from the National Transport Code
Collaboration Library ( http://w3.pppl.gov/NTCC ).
JSOLVER uses the poloidal flux as radial coordinate. This choice
is particularly appropriate for high beta plasmas as the surfaces
end up highly packed on the outer edge where more resolution is
demanded. An interesting feature of JSOLVER is its ability to
double the mesh size after a predefined number of iterations. This
explains why JSOLVER's mesh size is always a power of two.
Note that TRANSP supplies the toroidal flux and the iota-bar (=1/q)
profiles to the equilibrium codes. In order to obtain a JSOLVER
equilibrium solution that is consistent with the TRANSP iota-bar
profile, JSOLVER is executed from within a loop where the geometry
and current are incrementally adjusted. This iterative procedure
controlled by the NITJSO parameter appears to converge after 3-4
iterations for TFTR cases, 5-10 for JET cases but fails sometimes
to converge for NSTX. Note that the consistency error can be monitored
during a run and looks like:
>>jter= 1 Relative error in J//= 0.0600
>>jter= 2 Relative error in J//= 0.0354
>>jter= 3 Relative error in J//= 0.0155
>>jter= 4 Relative error in J//= 0.0090
>>jter= 5 Relative error in J//= 0.0090
A value of Relative error < 0.01 is usually OK.
The equilibrium resolution is determined by 2 parameters MNJSO and
NDOJSO such that both the numbers of radial and poloidal mesh nodes
are ~ 2**(MNJSO+NDOJSO). Here, 2**MNJSO denotes the initial grid
size during a cold equilibrium calculation (1st time through the NITJSO
loop), which is then doubled NDOJSO times. Consider MNJSO = 5 as a
minimum. For difficult cases or when accuracy is required NDSJO =1-2
usually helps. Values of MNJSO > 6 are not advisable. Since JSOLVER
allocates the dynamically the memory, there is no limit in NDOJSO
although every mesh doubling appears to slow down the code by a
factor 5-6. The final accuracy is determined by TOLJSO, which, if
negative, is halved every time the mesh is doubled. An additional
parameter NIMJSO controls the number of internal iterations before
the metric is updated.
Namelist parameters
NITJSO -[INT] NUMBER OF JSOLVER ITERATIONS (3)
MNJSO -[INT] JSOLVER RADIAL & POLOIDAL GRID SIZE ~ 2**MNJSO (6)
NDOJSO -[INT] JSOLVER NUMBER OF TIMES MESH SIZE IS DOUBLED (0)
TOLJSO -[REAL] TARGET ERROR TOLERANCE. (1.E-06)
NIMJSO -[INT] JSOLVER MAX NUMBER OF INTERNAL ITERATIONS (11)
In summary, JSOLVER can be an attractive alternative to VMEC6 when full
control over the accuracy and resolution is required by the user.
Unfortunately the price to pay for higher accuracy is slow execution
so that JSOLVER will probably not become a popular choice for large
runs. Another deficiency of JSOLVER is its observed inability
to handle NSTX data, apparently due to poor or oscillatory convergence
in the NITJSO loop. JSOLVER also appears to experience difficulties
when the geometry presents a sharp X point, a problem intrinsic to
JSOLVER's algorithm which relies on the alignment of ghost points
outside the last surface.
--Alexander Pletzer, 7 Jan 2000
This option has been indefinitely disabled as of 26Mar2008
and will force LEVGEO=11 (TEQ) to be used instead.
TEQ is the MHD equilibrium code used in the Corsica transport code from
LLNL. This LEVGEO option invokes the inverse solver of TEQ for a fixed
boundary solution using the pressure and q profiles as input. The
vacuum R*Btor is used as a boundary condition. After the initial startup,
TEQ is called in a loop which adjusts the q profile near the edge region
in order to match to the total plasma current. The following namelist options
are available for controling TEQ,
NTEQ_NRHO - number of radial points to use internally to TEQ. By default
this is set to the larger of 71 and the 1.5*(number of TRANSP
boundaries). LLNL suggests this should be in the 61-81 range.
NTEQ_NTHETA - number of poloidal points to use in TEQ. Default 127.
NTEQ_CONFIG - there may be multiple TEQ data files which can be used for a given
tokamak. This options selects one of them though typically there
is only one data file in which case this option is ignored.
The default is 0. Nonzero values which are available,
tokamak NTEQ_CONFIG
MAST 0 or 1 single null configuration
MAST 2 up/down symmetric double null configuration
NTEQ_MODE - selects the free parameters matched in the Grad-Shafranov
solution. The default is NTEQ_MODE=5.
1 <J.B>, plasma current
2 Q, plasma current
3 F, plasma current
4 Q, edge F = vacuum R*Btor
5 Q, edge F = vacuum R*Btor with a loop to match plasma current
6 <J.B>, edge F = vacuum R*Btor
TEQ_SMOOTH - half-width in TRANSP's xi coordinate to use for smoothing
the profiles prior to use in TEQ (default 0.)
TEQ_AXSMOOTH - this applies smoothing near the axis using the formula
half-width = |TEQ_AXSMOOTH|*min(1, (ximax-xi)/(ximax-xicut))
where xi is TRANSP's sqrt(normalized toroidal flux) coordinate
and ximax = 2.*|TEQ_AXSMOOTH|, xicut=|TEQ_AXSMOOTH|.
A TEQ_AXSMOOTH=0.15 was found to be needed for a D3D regression test.
If TEQ_AXSMOOTH<0. then the pressure profile will be dehollowed before
smoothing by forcing the pressure profile to have the peak value
all the way to the axis. The default is TEQ_AXSMOOTH=.05
SOFTTEQ - The average Grad-Shafranov error is checked after the TEQ execution
and if it is larger then this value or HARD_GSERROR then it is
considered a failure. (default 0.3)
Useful rplot outputs when using the TEQ option
GSERROR - actual average Grad-Shafranov error. This should be stunningly good
when TEQ successfully runs.
TEQRESID - The resdual computed by TEQ. The target residual is 1.e-6. If the
actual residual is larger then 10. times the target, this output
will be negative indicating a warning. A residual 100. times larger
then the target is considered a failure.
IPCMP - Multigraph comparing the plasma current as measured, used and implied by
the equilibrium
There is some logic to abandon matching of the plasma current if the TEQ residual
becomes too large (warning level -- see TEQRESID) and to switch from matching to
q to matching to current if there is a failure. This logic along with the defaults
may be adjusted over time as experience with TEQ in TRANSP develops (May 2006).
Method of specifying the location of the plasma boundary depends on
the geometry level switch LEVGEO.
for LEVGEO=0 set (in TRANSP namelist)
RMAJOR=plasma major radius, cm. RMINOR=plasma minor radius, cm.
for LEVGEO.LE.2 UFILES of major and minor radius vs. time may be
read (but the data will be time averaged if LEVGEO=0). In the
TRDAT namelist set
PREPOS,EXTPOS - UFILE name for major radius vs. time
PRERMN,EXTRMN - UFILE name for minor radius vs. time
for LEVGEO.ge.3 a set of UFILES containing a time dependent Fourier
moments specification of the boundary location is required. See
section on the TRDAT namelist - UFILES names, moments UFILES.