Ideas for Code Run Management Schema
M. Greenwald
started 6/9/99 last updated 3/14/00
We want to use a consistent schema so queries are similar
from code to code and from machine to machine. We will be writing a general run
selector widget.
I've made a first stab at the set of tables that we might
use. For n different codes we would
have n+5 tables in the schema.
CODES, is just a list of codes for which 1 or more runs
exist. The table would be used to drive
menus or queries.
PLASMAS, has an entry for every run of every code and has a
small amount of information on the code and the plasma for which it was
written. A unique identifier (index) is
established for every run. This will
help with joins, inheritence issues, etc.
The table includes a comment about the shot and a separate comment about
the run. This table would be used to
find shots where particular codes have been run and/or particular
characteristics.
RUN_TYPES, is used to store definitions of
run types (designations). 1 entry for
each defined run_type. These are
usually specific to individual codes and/or users. The table allows other users to understand the meaning of these
designations. They could also be used to
drive a menu of choices in an application which sets up runs. (Example; kinetic
EFITs vs magnetic or MSE EFITs). The table would be used to drive menus or
queries.
INHERITANCE, stores the information needed to
reconstruct run histories where data or control parameters are passed from one
run to the next (a common procedure).
1 or more entries for every run of every code where data or controls
have been inherited from another code run. For example, if the a number of runs
were based on a single set of data, each of these "child runs" would
have entries pointing to that same "parent run". A run could inherit data from one run and
control parameters (namelist) from another. (Shot comments are inherited
through data, run comments through the namelist.) A simple application could reconstruct the complete histories by
iteration and present the user with all relevant comments, changes, data source
and preparation info, etc.
INHERITANCE_TYPES, stores a short list of allowed
inheritance types for the inheritance table.
1 entry for each defined inheritence type. To start with these would be "data" and
"controls". The table would
be used to drive menus or queries.
CODE_DETAILS (TRANSP_DETAILS, EFIT, HYPED, GS2, PEST, ONETWO....) Finally there is a set of tables, 1 per code
with an entry for every run of that code.
It contains details on the control parameters (different for every
code).
In addition, views are defined, one for each code, which
join PLASMAS to CODE_DETAILS. For
example the view TRANSP joins PLASMA with TRANSP_DETAILS.
Table specs
(Initial details for tests with TRANSP runs database)
(Format for info below is
attributes
(description: datatype)
K => principal key for table
CODES - (1 entry
per code)
K code_name (name of code: text, 16 characters)
comment (short
description of code: text, 128 characters)
username (userid of person responsible for local code
implementation:
text, 32
characters)
code_date (date
that code was first implemented in schema: date)
PLASMAS - (1 entry for each run of any code)
idx (unique
identifier/index for each run of any code: long integer)
K experiment (name
of machine/server: text, 20 characters)
shot (machine shot
number: long integer)
shot_comment
(description of plasma: text, 256 characters)
K code_name (name of code: text, 15 characters) foreign
key of CODES
run_type (user
defined designations to help sort groups of runs:
text, 32
characters) foreign key of RUN_TYPES
K run_id (used optionally to track multiple runs,
temporary runs,
non-shot
related runs, etc. exact use defined by code
specific
applications: long integer)
tree (MDSplus tree
name: text, 16 characters)
full_pathname
(mdsplus(or other) path which with shot will
uniquely point to data from code run:
text, 128 characters)
run_comment (user
defined: text, 256 characters)
date_run (date
when code was run: date)
run_by (userid for person who ran the code: text,
32 characters)
deleted (0/1, run data may be deleted, but not
database entry -
allows
inheritance to function: tinyint)
goodness (defined
by users of specific codes. main purpose
is to
allow "best" run for each shot to be identified: integer)
start_time (for
time dependent codes: real)
stop_time (for time dependent codes: real)
ip (plasma current
(MA): real)
bt (toroidal field
(T): real)
nel (line averaged
density (10^20): real)
ptot (total input
power (MW): real)
(+ Other desired
shot data - note: should not duplicate
existing run
summary tables.)
RUN_TYPES (1 entry per run type)
K code_name (name of code: text, 16 characters) foreign
key of CODES
K run_type (user
defined designations to help sort groups of runs:
text, 32
characters)
comment (brief
definition of each run_type: text, 128 characters)
username - (userid
of person registering run_type: text, 32 characters)
date_entered (date
when run_type was registerd: date)
INHERITANCE (1 or more entries for every run
of every code that has
inherited data or control parameters from another run)
K idx (unique
identifier of code run: long integer)
primary key
plasma_idx (id of
run for which this inheritance information applies
long
integer, foreign key of plasmas
parent_plasma_idx
(id of run from which data or parameters were
inherited:long integer) foreign key of plasmas
inheritence_type
(one of the registered inheritence types:
text, 16 characters) foreign key of INHERITANCE_TYPES
comment (text, 64
characters)
(plasma_idx and
inheritance_type form a unique key for this table)
INHERITANCE_TYPES (1 entry per inheritance type)
K inheritence_type
(designates which component was inherited from
other runs, initially "data" or "controls":
text, 16 characters)
comment (meaning
of each inheritance type: text, 128 characters)
username - (userid
of person registering inheritance_type: text, 32
characters)
date_entered (date
that inheritance type was defined: date)
K idx (long integer) foreign key of PLASMAS
exe_build_date
(date)
date_began (date)
date_pasted (date)
locked (integer)
run_flag (integer)
queue_entry (text, 16 characters)
log_flag (integer)
old_transp (integer)
start_time (real) foreign key of PLASMAS
stop_time (real) foreign key of PLASMAS
ftime_act (real)
levgeo (integer
levgeo2 (integer)
nmoments (integer)
h_use (integer)
h_nmodel (integer)
d_use (integer)
d_nmodel (integer)
li_use (integer)
li_nmodel (integer)
xzimp (integer)
zeff_pc (text, 2 characters)
zeff_md (text, 8 characters)
resistivity (text, 4 characters)
nlvsur (integer)
nefld (integer)
nlsaw (integer)
tifdbk (text, 8 characters)
nkimod (integer)
nlicrf (integer)
frmini (real)
npel (integer)
nlxkie (text, 4 characters)
GS2_DETAILS
- 1 entry for each GS2 run
as above
EFIT_DETAILS - 1 entry for each EFIT run
as above
PEST_DETAILS - 1 entry for each PEST run
as above
ONETWO_DETAILS - 1 entry for each ONETWO run
as above