Here is a design spec for our run management database. This is now
in use for tracking the runs of several codes at the various fusion
labs.
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.
- Martin
.................................
Ideas for Code Run Management
-----------------------------
M. Greenwald
started 6/9/99 last updated 9/20/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 =
TABLES
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)
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
===============================================================================
This message was sent to the SciDAC National Fusion Collaboratory (NFC)
workers list nfc-workers. Visit the Collaboratory at
<http://www.fusiongrid.org/>.
To unsubscribe from this list, please send a message to
majordomo@fusion.gat.com with the following text in the *body* of the
message: unsubscribe nfc-workers
David P. Schissel: <schissel@fusion.gat.com> <http://fusion.gat.com/~schissel/>
This archive was generated by hypermail 2.1.1 : Thu Feb 07 2002 - 15:40:41 PST