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

TABLE-NAME

  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