PROGRESS ON A NEW DISRUPTION DATABASE

Transcription

1 PROGRESS ON A NEW DISRUPTION DATABASE E.J. Strait with J. Wesley, A. Hyatt, D. Schissel Presented at ITPA Topical Group on MHD, Disruptions and Control Lisbon, Portugal, Nov. 8-10, 2004

2 ITPA DISRUPTION DATABASE General Atomics and the DIII-D Team plan to host and administer an ITPA Disruption Database Database coordinator: John Wesley DIII-D contact person: Al Hyatt Contact for the GA Data Acquisition and Analysis Group: Dave Schissel John and Al will coordinate the definition of the database and its use for fusion research Dave and the DAAG staff will support the database and the necessary input/output interfaces for users A prototype database has been created Next steps for full implementation should be discussed by this group.

3 OBJECTIVES OF A DISRUPTION DATABASE Develop disruption science Develop empirical scalings for disruption parameters Validate disruption models over a range of machine sizes and operating regimes Extrapolate disruption parameters to ITER Provide confidence in design limits (EM forces, heat deposition) Identify range of outcomes, worst-case limits Provide input to detection and mitigation scenarios Specific issues include Current quench time scale Thermal quench time scale and energy distribution

4 Guidelines for the Operation of the Physics Databases under the ITPA Framework 1) There should be a named representative (RO) from each machine who is responsible for the submission of data to each of the databases. The ROs should be encouraged to attend the meetings of the database working group and are responsible for clearance of their data and database publications from the working group within their own laboratories. The working group, which will be nominated by the Topic Group, will consist of the data representatives from each machine and database analysts (e.g. modellers, statistical experts etc) where appropriate. 2) At the initial meeting of the working group the content of the database should be discussed and the group should go through the entire variable list, confirming that a given variable measures the same quantity in each machine, and give an error in the measurement for each variable in each machine. Variable names and the database format should be chosen to be the same as other related ITPA databases to simplify merging. 3) There should be two versions of the database, a publicly available version and a working version available only to the working group. 4) The group should appoint a database manager who will be responsible for maintaining both the working and public versions of the database and making them available to members of the working group and the public respectively. This should also include variable descriptions, errors and any relevant references. The database managers should be officially recognised by the ITPA CC. 5) Prior to the public release of the working version of the database, there should be a joint publication by the entire group describing the database and the group s analysis based on it. No other publications or presentations based on the working version of the database by any individuals are permitted, except with the explicit agreement of all of the topic group members. Analysis and publication based on the public version of the database by anyone interested is encouraged with proper reference to the initial paper describing the database, or if only a few discharges from a given device are used then the original publication describing the discharges should be referenced. It is recommended that public release of the database should take place, as frequently as practical, and certainly following a major extension of the database. Recognising that the time from the completion of a pulse to its appearance in a publicly released database could be up to two years, being made up of approximately, one year for the laboratory to release the data and a further year to appear in the publicly released database. 6) In situations where there is an overlap of database content with another group e.g. ELMy H-mode and pedestal databases, the named data suppliers for each database should be encouraged to provide data from a common set of pulses and times to both databases, so that a broad analysis of issues such as global confinement, pedestal scaling and ELM loss can be completed. Any publication should be cleared by both topic groups. 7) Working group meetings should be held at approximately 6 month intervals. J.G. Cordey Y. Kamada 20 February, 2002

5 THE DISRUPTION DATABASE WILL FOLLOW ITPA GUIDELINES FOR PHYSICS DATABASES 1. There should be a named representative (RO) from each machine who is responsible for the submission of data to each of the databases 2. At the initial meeting of the working group the content of the database should be discussed 3. There should be two versions of the database, a publicly available version and a working version available only to the working group. 4. The group should appoint a database manager who will be responsible for maintaining the working and public versions of the database 5. Prior to the public release of the working version of the database, there should be a joint publication by the entire group 6. In situations where there is an overlap of content with another group, the data suppliers should be encouraged to provide data from a common set of pulses and times to both databases 7. Working group meetings should be held at ~ 6 month intervals.

6 WE PROPOSE THAT CONTRIBUTORS SUBMIT DATA DIRECTLY TO THE DATABASE Each contributing institution loads data into a central server Access control allows contributors to create or modify only their own data Contributed data is in a common format (SQL, MDSplus) Contributors are responsible to maintain and validate their own data Members of the database working group have read-only access to all data Database manager: Maintains the hardware and backup for the data on the central server Sets up and enforces security and access control Maintains an list and on-line documentation Assists users in developing routines to read and write data to and from the database In developing the organization and rules for this database, we should take advantage of experience gained from the confinement and profile databases.

7 DATABASE STRUCTURE & MANAGEMENT l Scalar quantities stored in relational database Extensible, flexible: quantities, names, definitions, relationships Supports relational queries (e.g. find all shots where betan is greater than 3 and IP greater than 2MA) l Vector data (e.g. time series, profiles, equilibria) stored in MDSplus Open source, worldwide fusion community usage, significant support Extensible, flexible : quantities, names, definitions, relationships Stores contextual information along with data Supports many data types (e.g. video, high dimensional data) l Secure access to both Internet access available via username & password for relational DB and host based (user@host.jet.uk) for MDSplus Supports fine grain access control (subsets of data)

8 DATA ACCESS AVAILABLE FROM MANY LANGUAGES/PLATFORMS l MDSplus access ( Built in secure client/server access from many languages/platforms Open source, worldwide usage, significant support l Microsoft SQL Server Password protected access No cost client access from many platforms including MDSplus Wide spread usage in fusion community, significant support l Data access speed only limited by client network bandwidth Database can be mirrored at database administrator level if required

9 VERSATILE DATA ANALYSIS OPTIONS l IDL based visualization applications Large set of tools available from the experimental community A specific tool could be written if required l Web access Graphical and tabular l Commercial analysis programs (e.g. IDL, Matlab, SAS, JMP, Excel) SQL data access standard MDSplus access possible with C external call (e.g. IDL, Matlab) l Data client API allows user written tools For visualization and analysis Large selection of applications from the experimental community

10 EXAMPLE IDL BASED MDSPLUS VISUALIZATION APPLICATIONS Used extensively in Experimental community

11 IDL BASED VISUALIZATION OF RELATIONAL DATABASE DATA

12 A PROTOTYPE DATABASE HAS BEEN CREATED A beginning, primarily for demonstration Limited set of parameters Contains DIII-D data only (so far) Illustrates storage of varied types of data Identification data (shot number, type of disruption, ) Scalar data (Bt, Ip, maximum beta, ): ~3800 DIII-D shots Vector data Time histories (Ip, SXR, ) Profiles (ne, Te, ) Results of analysis(energy balance in disruption, ): ~40 DIII-D shots Initial web-based graphical interface is implemented

13 Data items in prototype data base Pointname Type Units Description Shot number integer LDISR logical marker for true disr or termination TEND7A scalar Sec Fault system 7A trigger TENDIP scalar Sec IP minimum fault trigger FFAULT Text First fault detected (IPMIN,FPS,etc) MAXTIME scalar Sec Time of maximum betan in flattop TPRE scalar Sec appx 20 msec before disruption T10 scalar Sec Time Ip reaches 10% of IP(TPRE) T90 scalar Sec Time Ip reaches 90% of IP(TPRE) T79 scalar Sec Fault system 79 trigger TSTART scalar Sec start time of disr energy analysis (pre-disr) TEND scalar Sec end time of disr energy anaalysis (post-disr) BETANMAX scalar max betan in flattop at MAXTIME BETATMAX scalar % betat at max betan at MAXTIME BTMAX scalar T B field at max betan at MAXTIME IPMAX scalar A IP at max betan (flattop IP) at MAXTIME AMINORMAX scalar M minor radius at max betan at MAXTIME KAPPAMAX scalar elongation at maax betan at MAXTIME LIMAX scalar internal inductance at max betan DENSR0MAX scalar el/m^3 R0 chord line averaged density at max betan at MAXTIME DENSV2MAX scalar el/m^3 V2 chord line averaged density at max betan at MAXTIME

14 Q95MAX scalar Q95 (safety factor) at mav betan at MAXTIME Q0MAX scalar Q0 on axis at max betan at MAXTIME QMINMAX scalar Qmin at maax betan at MAXTIME IPTIPP time hist. A PCS plasma current target waveform IPPROBESF time hist. A Fast IP signal (appx 100 ms data) SX90RM1F10 time hist. V(arb) Fast SXR central chord, for TQ analysis Thomson ne profile el/m^3/e19 Plasma density profile n(r) at MAXTIME and TPRE Thomson Te profile kev Plasma electron temperature profile Te(r) at MAXTIME and TPRE W_IR60 time hist. MW Total power dumped to divertor floor, 60 degree camera W_IR165 time hist. MW Same as above but 165 degree camera W_THERMAL scalar MJ Thermal energy before and after disr at TSTART, TEND W_MAGNETIC scalar MJ Magnetic energy inside limiter before and after disr at TSTART, TEND W_NB_DEL scalar MJ energy added from TSRAT to TEND by NBI W_POYNT_DEL scalar MJ magnetic energy inflow to chamber from TSRAT to TEND W_IR60_DEL scalar MJ total energy dumped to divertor floor from TSRAT to TEND. 60 degree camera W_IR165_DEL scalar MJ Same as above but 165 degree camera data W_RADIATED_DEL scalar MJ total energy radiated (bolometers) from TSRAT to TEND W_DOUBLECOUNT scalar MJ Radiated energy to divertor floor. This is already contained in W_IR165_DEL, etc.

15

16

17

18 NEXT STEPS (FOR DISCUSSION) Is a disruption database still desirable? If so At this meeting: Agree on the general approach Identify a contact person at each tokamak laboratory Following this meeting: Discuss by the initial database format Agree on an initial set of variables to be contributed by all or most participants Set up and test interfaces for data uploading and data viewing Participants contribute a limited quantity of data Next meeting of this ITPA topical group should include a working group meeting on details of the disruption database: Content (what additional variables to include) Definitions (each variable needs a precise, agreed definition) Data quality and quantity (what level of data validation is needed before entry) Access to data (who can read it, who can publish it?)