|
Run Management Database |
It is not meant for the kind of resource management we discussed today - instead, it seeks to give end users the ability to find and share code runs. It has generic tables and one code specific table for each application. This general approach might use for a resource management database which has generic and application specific pieces.
The Run Management Database uses a consistent schema so queries are similar from code to code and from tokamak to tokamak. A general run selector widget has been written in IDL for usage in all IDL based analysis/visualization programs.
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). One 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). One 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. One 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 (e.g. TRANSP_DETAILS, EFIT_DETAILS, NIMROD_DETAILS, etc.) Finally there is a set of tables, One 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.
Format =
TABLES
attributes (description: datatype)
K => principal key for table
CODES - (One 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)
TRANSP_DETAILS
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