- Email: [email protected]
Parameters extraction and scenario verification for the EAST discharge scenario query system
Fusion Engineering and Design 128 (2018) 33–37
Contents lists available at ScienceDirect
Fusion Engineering and Design journal homepage: www.elsevier.com/locate/fusengdes
Parameters extraction and scenario verification for the EAST discharge scenario query system
T
⁎
W.T. Chaia,b, Q.P. Yuana, , B.J. Xiaoa,b, R.R. Zhanga, S.L. Chena a b
Institute of Plasma Physics, Chinese Academy of Sciences, Hefei, Anhui, PR China University of Science and Technology, Hefei, Anhui, PR China
A R T I C L E I N F O
A B S T R A C T
Keywords: EAST Scenario analysis Discharge parameters Web
The discharge scenario query system, designed and deployed since 2014, is an important part of the EAST remote discharge scenario management system (RDSMS) Chai et al. [1]. Parameter analysis and extraction are the key function for classifying and querying scenarios. On EAST, the plasma control system (PCS) can parse the pre-set parameters line-by-line from future shots (taken from pre-set files in PCS server) or from past shots (taken from the MDSplus Manduchi et al. [2,3] tree) through a two-step conversion while the discharge parameters can be taken from the MDSplus tree directly without any conversion. To help with searching through enormous stock of past and future scenarios that are archived at EAST, we take advantage of the parsing procedure of the PCS and MDSplus programming by developing a “Parsing Program” to extract the pre-set and discharge parameters. This paper introduces the storage structure and parsing procedure of pre-set files, going into some detail for the latter. The other parameters, on the other hand, need little explanation as they are taken directly from the MDSplus tree. The pre-set parameters and the data analysis of the completed shot are archived in the MySQL database for future advanced scenario queries. In order to provide a cross platform tool, a remote graphical user interface has been built in form of a dynamic web page to query and evaluate parameters as well as provide scenario verification via auditors. This web-based discharge scenario query system will ultimately lead to improved work efficiency of technicians, researchers, scientists, users in general.
1. Introduction Remote participation and data visualization has become an increasingly important topic for tokamaks over the past few years. A webbased experiment management system (TEXEMS) with an electronic logbook has been established, which allows all users to access TEXTOR data and participate in experiments from their home labs. The system stores discharge describing data and experiment related diagnostic settings and allows to manage program and discharge related data for a later goal-oriented analysis of data [4]. Concurrently, the remote participation using MDSplus [2–3] for Tokamak TCABR has been developed, which preseves control and data acquisition techniques that have been working at a long time, and allow a transparent access to experimental data [5]. In order to try and give remote researchers the same ease and accessibility for participating in experimental data analysis as on-site researchers, experimental data analysis and simulation software has been deployed on the ITER remote experimentation center [6]. To efficiently manage multiple discharge scenarios, a new web-
⁎
based remote discharge scenario management system (RDSMS) is being developed on EAST [1,7]. An important subsystem within the RDSMS is the web-based discharge scenario query system (DSQS), which has already been successfully implemented and will be introduced in this paper. A LAMP (Red Hat Linux, Apache, MySQL, and PHP) platform is used for the server side to construct this system. The EAST LDAP account with user permissions was then ported on it. With these steps complete, the “Parsing Program” that extracts parameters for the scenario database was then written in PHP and C-language and developed on the THINKPHP framework. The main functions of the DSQS are searching scenarios based on specific keywords, restoring scenarios on the WebPCS [8] for setting plasma pre-set targets and control parameters, and applying for scenario verification via email reminder. 2. System structure of web-based discharge scenario query system Fig. 1 shows the DSQS overview for the EAST PCS; the green boxes highlight the main function modules. EAST users can visit this system
Corresponding author. E-mail address: [email protected] (Q.P. Yuan).
https://doi.org/10.1016/j.fusengdes.2018.01.020 Received 22 June 2017; Received in revised form 1 December 2017; Accepted 3 January 2018 Available online 28 January 2018 0920-3796/ © 2018 Elsevier B.V. All rights reserved.
Fusion Engineering and Design 128 (2018) 33–37
W.T. Chai et al.
Fig. 1. Overview of the web-based DSQS.
directly if they are on-site or remotely from the WebPCS “Restore” module for “Prepared” and “Discharge” scenarios query. The scenario verification module has also been constructed and implemented. Here, any user (on-site or remote) can apply for scenario verification by specifying an auditor and submitting the request. This request will generate a confirmation email for the user and a request email for the auditor to deal with the application. When the auditor completes the verification, a final email is sent to the user detailing the result of the verification. The scenario database is a core part of the DSQS and needs certain background parameters to function properly, which are acquired by the “Parsing Program”. The DSQS divides EAST discharge scenarios into two categories: “Prepared Scenario” and “Discharge Scenario”. The former is in the form of pre-set files stored on the public directory of the PCS server; these files include the time-varying pre-set targets and control parameters that are set before each plasma discharge shot. The latter is archived in the MDSplus tree (pcs_east, processed database) after each plasma discharge shot, which includes the pre-set node (same as pre-set files), time-varying discharge signals (plasma related signals), and time-varying wave heating signals (auxiliary heating system related signals). The “Parsing Program” can extract pre-set parameters from “Prepared Scenario” and extract pre-set, discharge, wave heating parameters from “Discharge Scenario”.
parameters can extract from MDSplus tree. However, the time-varying signals instead of strings or single values, e.g. IP, Density, LHW heating, etc., are stored under a specified signal name. In order to query these parameters and return a single value, the “Parsing Program” computes the average value of the effective period and uses this for the scenario parameters base on the interface between MDSplus and C-language. However, the “Pre-set” parameters of these scenarios, as shown in Fig. 2 in dark blue boxes, cannot be acquired directly because of their special storage format; this requires a specially designed conversion algorithm for extraction which is introduced in the next section. 3.2. Extraction of pre-set parameters In the EAST PCS GUI, users can restore (load parameters into the GUI) scenarios “from a prepared setup” or “from MDSplus”, then the program will parse the pre-set parameters line-by-line from the pre-set file or a MDSplus tree named pcs_east through a two-step conversion. The “Parsing Program” was adapted from the EAST PCS parsing procedure to meet the needs of the pre-set targets and control parameters storage format. Fig. 3 shows the two-step conversion process the raw data must undergo each time a scenario is restored. In fact, with the exception of the “Basic” parameters, all of the parameters in the original data source are stored in the form of a continuous block of data. To make the parameters parse-able, the intermediate “pfi42” structure is constructed and then filled with the correct parameter data from the original data source. However, retrieving useful information from this structure is still not easy. That is why the second structure, “rstcom”, is needed. This structure stores parameters in the same order as the PCS GUI, i.e. category, sequence, phase, algorithm are defined and then receive their respective data from the “pfi42” structure after a rather complex read buffer process, according to the header information. To take full advantage of the “rstcom” structure, the “Parsing Program” takes the value of the pre-set parameters from the structure in the same order that the PCS parsing procedure uses. As show in Table 1, PCS setup parameters are store in form of tree structure organized by category, phase and algorithm. The path is determined by first selecting primary ‘sequence’ of a category to find the
3. Scenario parameters 3.1. Introduction of scenario parameters Fig. 2 shows the parameter classification of the “Prepared” and “Discharge” scenarios. As mentioned above, for the “Prepared” scenarios, the pre-set files are stored in the public directory after the “future shot” setup process is completed by the user on the EAST PCS, in particular, the user can populate pre-set files with data from prepared setup files or actual discharges. The name of any pre-set file is composed of the user and title (user_title.wa10) while the descriptions of all pre-setup files are written in a single universal file named “futue_shot.descr” so that the “Basic” parameters are easy to access. For the “Discharge” scenarios, all of the “Basic”, “Discharge” and “Heating” 34
Fusion Engineering and Design 128 (2018) 33–37
W.T. Chai et al.
Fig. 2. Parameter classification of scenario.
Fig. 3. The process of type conversions on EAST PCS.
Table 1 Path to get the value of pre-set parameters. Parameter
Category
PS1 control IP PS1 control = 0 PS1control = 1
System Discharge Shape Isoflux
Shape Density Pulse Change history
Algorithm of phase
Target
System Main Algorithm PS1 Control(w) Limited Plasma Control IPREF(w) Double Null/Elongated/Single Null/Upper Single Null/Single Null IP(w) Snowflake Isoflux Double Null/Elongated/Single Null/Upper Single Null/Single Null Algorithm Snowflake Density Density Feedback Control Density(w) Data Acquisition Collect baseline data Operating setup data Read directly from “rstcom”, the procedure save them as local file, and not load them until necessary.
Value Maximum value of PS1 Control Maximum value of IPREF Maximum value of IP Algorithm name of main phase Maximum value of Density the value of “time to stop(sec):”
Fig. 4. ECRH waveform of 70031.
main ‘phase’. Within the phase, the algorithm is selected and finally, the target value of the parameter is found. The following are examples in Table 1. The label “(w)” in column “Target” means the target is a timevarying waveform, the value of “IP”, “Density” is maximum value of
their target. The discharge shape in the PCS is instantiated in the algorithm name of main phase within the category ‘Isoflux’. The path to ‘pulse’ is different from the above examples. Its value resides in a continuous block of data called ‘Operating setup data’ that 35
Fusion Engineering and Design 128 (2018) 33–37
W.T. Chai et al.
Fig. 5. Sequence chart of scenario verification.
the pointer ‘param_ptr’ (Fig. 3) points to. Hence, we cannot get it directly from ‘rstcom’. The ‘Operating setup data’ is organized as a continuous block, getting the data “time to stop (sec)” requires an intermediate step. We first design a structure called “diagnostic_infra” and is then filled with the data within the continuous block. Finally, from that we can get the value of the “Pulse” parameter as represented by the value of ‘the value of “time to stop (sec):”’. The purpose the parameter “change history” is to compare and contrast two similar shots. Typically, when the “change history” parameter is acquired from “rstcom” directly, it comes as huge quantity of data. Because of this, the system would could not load it quickly into the GUI. To resolve this problem, the restore procedure writes the data to a local file named with the title or shotnum and then a button in the GUI allows the user to load the data if needed.
greater than the threshold, and then compute the average value of the effective period after median-value filtering. 4. Scenario verification The manual scenario verification for “Prepared Scenario” has been built on the DSQS. Fig. 5 shows the main sequence of scenario verification. Users who have an EAST LDAP account can login to this module as ‘Common User’. The system would then list all the discharge scenarios that belong to the user with each scenario having one of four different audit statuses: ‘Pending’, ‘Under Review’, ‘Approved’, ‘Rejected’. Only in the ‘Pending’ state can scenarios be chosen for audit. When applying for scenario verification, users must specify the auditor, then the server will send an email containing the main information and hyperlink of the pending audit scenario to the auditor as well as a confirmation email to the user. There are some users who have been given permission by the administrator to be auditors as well. All of ‘Pending’ scenarios are listed after the auditor logs in, from which the auditor can then choose to audit, make comments, evaluate, and assign a new status. After that, the scenario owner will receive an email with the audit results.
3.3. Extraction of heating parameters The processed database shown in Fig. 1 is built based on an MDSplus event mechanism, which includes auxiliary heating parameters, profile of the diagnostic system, etc. The heating parameters are analysed data that has been converted from raw data using physical constraints. The raw data that we focus on come from the following diagnostic systems: lower hybrid waves (LHW), ion cyclotron range of frequencies (ICRF), electron cyclotron resonance heating (ECRH), and neutral beam injector (NBI). The value we want to archive in the scenario database is a single fixed power value that is representative of the waveform to make querying possible. A procedure to get this value has been designed and is introduced below. The heating wave often contains noise and singular points like signal ‘pecrh1i’ as show in Fig. 4 (ECRH signal of shot 70031). In order to get the effective value of ECRH, we first set the threshold for each signal so as to get the effective period, i.e. all of the amplitude remains
5. Function realizations Fig. 6 shows the GUI implementation of scenarios query function, in “prepared scenario” module (Fig. 6(a)) and “actual discharge scenario” module (Fig. 6(b)), we can search scenarios according to any keywords by “basic search” and specify detailed keywords by “advanced search”, and we can sort scenarios by any parameters. The brief information list of search result will available and more information will display if you click any site of a scenario. 36
Fusion Engineering and Design 128 (2018) 33–37
W.T. Chai et al.
management system, the discharge scenario query system with audit module has been implemented and is currently in use. By adapting EAST PCS code, MDSplus command, and PHP technology, the scenario parameters have been extracted and stored into a scenario database. In the future, we can combine discharge simulation tools to carry out scenario evaluation and verification. Acknowledgements This work was supported by the National Magnetic Confinement Fusion Research Program of China under Grant No. 2014GB103000 and the National Natural Science Foundation of China under Grant No. 11705239. The authors would like to thank all of the colleagues of the Computer Application Division at the Institute of Plasma Physics, Chinese Academy of Sciences, for their contributions. References [1] W.T. Chai, B.J. Xiao, Q.P. Yuan, R.R. Zhang, The design of remote discharge scenario management system on EAST, Fusion Eng. Des. 112 (2016) 1049–1054. [2] http://www.mdsplus.org. [3] G. Manduchi, T.W. Fredian, J.A. Stillerman, MDSplus evolution continues, Fusion Eng. Des. 87 (2012) 2095–2099. [4] A. Krämer-Flecken, B. Landgraf, J.G. Krom, Experiment management system—a way towards a transparent Tokamak, Fusion Eng. Des. 83 (2008) 375–381. [5] W.P. de Sá, Tokamak TCABR: acquisition system, data analysis, and remote participation using MDSplus, Fusion Eng. Des. 87 (2012) 2199–2202. [6] T. Ozeki, S. Clement-Lorenzo, N. Nakajima, Progress on ITER remote experimentation centre, Fusion Eng. Des. 112 (2016) 1055–1058. [7] Q.P. Yuan, B.J. Xiao, R.R. Zhang, W.T. Chai, J. Liu, R. Xiao, Z.C. Zhou, X.F. Pei, The design of remote participation platform for EAST plasma control, Fusion Eng. Des. 112 (2016) 1045–1048. [8] R.R. Zhang, B.J. Xiao, Q.P. Yuan, F. Yang, Y. Zhang, R.D. Johnson, B.G. Penaflor, The web-based user interface for EAST plasma control system, Fusion Eng. Des. 89 (2014) 558–562.
Fig. 6. Function realization of scenarios query function (a) Webpage of prepared scenarios (b) Webpage of actual discharge scenarios.
6. Conclusion As an important part of EAST remote discharge scenario
37
Contents lists available at ScienceDirect
Fusion Engineering and Design journal homepage: www.elsevier.com/locate/fusengdes
Parameters extraction and scenario verification for the EAST discharge scenario query system
T
⁎
W.T. Chaia,b, Q.P. Yuana, , B.J. Xiaoa,b, R.R. Zhanga, S.L. Chena a b
Institute of Plasma Physics, Chinese Academy of Sciences, Hefei, Anhui, PR China University of Science and Technology, Hefei, Anhui, PR China
A R T I C L E I N F O
A B S T R A C T
Keywords: EAST Scenario analysis Discharge parameters Web
The discharge scenario query system, designed and deployed since 2014, is an important part of the EAST remote discharge scenario management system (RDSMS) Chai et al. [1]. Parameter analysis and extraction are the key function for classifying and querying scenarios. On EAST, the plasma control system (PCS) can parse the pre-set parameters line-by-line from future shots (taken from pre-set files in PCS server) or from past shots (taken from the MDSplus Manduchi et al. [2,3] tree) through a two-step conversion while the discharge parameters can be taken from the MDSplus tree directly without any conversion. To help with searching through enormous stock of past and future scenarios that are archived at EAST, we take advantage of the parsing procedure of the PCS and MDSplus programming by developing a “Parsing Program” to extract the pre-set and discharge parameters. This paper introduces the storage structure and parsing procedure of pre-set files, going into some detail for the latter. The other parameters, on the other hand, need little explanation as they are taken directly from the MDSplus tree. The pre-set parameters and the data analysis of the completed shot are archived in the MySQL database for future advanced scenario queries. In order to provide a cross platform tool, a remote graphical user interface has been built in form of a dynamic web page to query and evaluate parameters as well as provide scenario verification via auditors. This web-based discharge scenario query system will ultimately lead to improved work efficiency of technicians, researchers, scientists, users in general.
1. Introduction Remote participation and data visualization has become an increasingly important topic for tokamaks over the past few years. A webbased experiment management system (TEXEMS) with an electronic logbook has been established, which allows all users to access TEXTOR data and participate in experiments from their home labs. The system stores discharge describing data and experiment related diagnostic settings and allows to manage program and discharge related data for a later goal-oriented analysis of data [4]. Concurrently, the remote participation using MDSplus [2–3] for Tokamak TCABR has been developed, which preseves control and data acquisition techniques that have been working at a long time, and allow a transparent access to experimental data [5]. In order to try and give remote researchers the same ease and accessibility for participating in experimental data analysis as on-site researchers, experimental data analysis and simulation software has been deployed on the ITER remote experimentation center [6]. To efficiently manage multiple discharge scenarios, a new web-
⁎
based remote discharge scenario management system (RDSMS) is being developed on EAST [1,7]. An important subsystem within the RDSMS is the web-based discharge scenario query system (DSQS), which has already been successfully implemented and will be introduced in this paper. A LAMP (Red Hat Linux, Apache, MySQL, and PHP) platform is used for the server side to construct this system. The EAST LDAP account with user permissions was then ported on it. With these steps complete, the “Parsing Program” that extracts parameters for the scenario database was then written in PHP and C-language and developed on the THINKPHP framework. The main functions of the DSQS are searching scenarios based on specific keywords, restoring scenarios on the WebPCS [8] for setting plasma pre-set targets and control parameters, and applying for scenario verification via email reminder. 2. System structure of web-based discharge scenario query system Fig. 1 shows the DSQS overview for the EAST PCS; the green boxes highlight the main function modules. EAST users can visit this system
Corresponding author. E-mail address: [email protected] (Q.P. Yuan).
https://doi.org/10.1016/j.fusengdes.2018.01.020 Received 22 June 2017; Received in revised form 1 December 2017; Accepted 3 January 2018 Available online 28 January 2018 0920-3796/ © 2018 Elsevier B.V. All rights reserved.
Fusion Engineering and Design 128 (2018) 33–37
W.T. Chai et al.
Fig. 1. Overview of the web-based DSQS.
directly if they are on-site or remotely from the WebPCS “Restore” module for “Prepared” and “Discharge” scenarios query. The scenario verification module has also been constructed and implemented. Here, any user (on-site or remote) can apply for scenario verification by specifying an auditor and submitting the request. This request will generate a confirmation email for the user and a request email for the auditor to deal with the application. When the auditor completes the verification, a final email is sent to the user detailing the result of the verification. The scenario database is a core part of the DSQS and needs certain background parameters to function properly, which are acquired by the “Parsing Program”. The DSQS divides EAST discharge scenarios into two categories: “Prepared Scenario” and “Discharge Scenario”. The former is in the form of pre-set files stored on the public directory of the PCS server; these files include the time-varying pre-set targets and control parameters that are set before each plasma discharge shot. The latter is archived in the MDSplus tree (pcs_east, processed database) after each plasma discharge shot, which includes the pre-set node (same as pre-set files), time-varying discharge signals (plasma related signals), and time-varying wave heating signals (auxiliary heating system related signals). The “Parsing Program” can extract pre-set parameters from “Prepared Scenario” and extract pre-set, discharge, wave heating parameters from “Discharge Scenario”.
parameters can extract from MDSplus tree. However, the time-varying signals instead of strings or single values, e.g. IP, Density, LHW heating, etc., are stored under a specified signal name. In order to query these parameters and return a single value, the “Parsing Program” computes the average value of the effective period and uses this for the scenario parameters base on the interface between MDSplus and C-language. However, the “Pre-set” parameters of these scenarios, as shown in Fig. 2 in dark blue boxes, cannot be acquired directly because of their special storage format; this requires a specially designed conversion algorithm for extraction which is introduced in the next section. 3.2. Extraction of pre-set parameters In the EAST PCS GUI, users can restore (load parameters into the GUI) scenarios “from a prepared setup” or “from MDSplus”, then the program will parse the pre-set parameters line-by-line from the pre-set file or a MDSplus tree named pcs_east through a two-step conversion. The “Parsing Program” was adapted from the EAST PCS parsing procedure to meet the needs of the pre-set targets and control parameters storage format. Fig. 3 shows the two-step conversion process the raw data must undergo each time a scenario is restored. In fact, with the exception of the “Basic” parameters, all of the parameters in the original data source are stored in the form of a continuous block of data. To make the parameters parse-able, the intermediate “pfi42” structure is constructed and then filled with the correct parameter data from the original data source. However, retrieving useful information from this structure is still not easy. That is why the second structure, “rstcom”, is needed. This structure stores parameters in the same order as the PCS GUI, i.e. category, sequence, phase, algorithm are defined and then receive their respective data from the “pfi42” structure after a rather complex read buffer process, according to the header information. To take full advantage of the “rstcom” structure, the “Parsing Program” takes the value of the pre-set parameters from the structure in the same order that the PCS parsing procedure uses. As show in Table 1, PCS setup parameters are store in form of tree structure organized by category, phase and algorithm. The path is determined by first selecting primary ‘sequence’ of a category to find the
3. Scenario parameters 3.1. Introduction of scenario parameters Fig. 2 shows the parameter classification of the “Prepared” and “Discharge” scenarios. As mentioned above, for the “Prepared” scenarios, the pre-set files are stored in the public directory after the “future shot” setup process is completed by the user on the EAST PCS, in particular, the user can populate pre-set files with data from prepared setup files or actual discharges. The name of any pre-set file is composed of the user and title (user_title.wa10) while the descriptions of all pre-setup files are written in a single universal file named “futue_shot.descr” so that the “Basic” parameters are easy to access. For the “Discharge” scenarios, all of the “Basic”, “Discharge” and “Heating” 34
Fusion Engineering and Design 128 (2018) 33–37
W.T. Chai et al.
Fig. 2. Parameter classification of scenario.
Fig. 3. The process of type conversions on EAST PCS.
Table 1 Path to get the value of pre-set parameters. Parameter
Category
PS1 control IP PS1 control = 0 PS1control = 1
System Discharge Shape Isoflux
Shape Density Pulse Change history
Algorithm of phase
Target
System Main Algorithm PS1 Control(w) Limited Plasma Control IPREF(w) Double Null/Elongated/Single Null/Upper Single Null/Single Null IP(w) Snowflake Isoflux Double Null/Elongated/Single Null/Upper Single Null/Single Null Algorithm Snowflake Density Density Feedback Control Density(w) Data Acquisition Collect baseline data Operating setup data Read directly from “rstcom”, the procedure save them as local file, and not load them until necessary.
Value Maximum value of PS1 Control Maximum value of IPREF Maximum value of IP Algorithm name of main phase Maximum value of Density the value of “time to stop(sec):”
Fig. 4. ECRH waveform of 70031.
main ‘phase’. Within the phase, the algorithm is selected and finally, the target value of the parameter is found. The following are examples in Table 1. The label “(w)” in column “Target” means the target is a timevarying waveform, the value of “IP”, “Density” is maximum value of
their target. The discharge shape in the PCS is instantiated in the algorithm name of main phase within the category ‘Isoflux’. The path to ‘pulse’ is different from the above examples. Its value resides in a continuous block of data called ‘Operating setup data’ that 35
Fusion Engineering and Design 128 (2018) 33–37
W.T. Chai et al.
Fig. 5. Sequence chart of scenario verification.
the pointer ‘param_ptr’ (Fig. 3) points to. Hence, we cannot get it directly from ‘rstcom’. The ‘Operating setup data’ is organized as a continuous block, getting the data “time to stop (sec)” requires an intermediate step. We first design a structure called “diagnostic_infra” and is then filled with the data within the continuous block. Finally, from that we can get the value of the “Pulse” parameter as represented by the value of ‘the value of “time to stop (sec):”’. The purpose the parameter “change history” is to compare and contrast two similar shots. Typically, when the “change history” parameter is acquired from “rstcom” directly, it comes as huge quantity of data. Because of this, the system would could not load it quickly into the GUI. To resolve this problem, the restore procedure writes the data to a local file named with the title or shotnum and then a button in the GUI allows the user to load the data if needed.
greater than the threshold, and then compute the average value of the effective period after median-value filtering. 4. Scenario verification The manual scenario verification for “Prepared Scenario” has been built on the DSQS. Fig. 5 shows the main sequence of scenario verification. Users who have an EAST LDAP account can login to this module as ‘Common User’. The system would then list all the discharge scenarios that belong to the user with each scenario having one of four different audit statuses: ‘Pending’, ‘Under Review’, ‘Approved’, ‘Rejected’. Only in the ‘Pending’ state can scenarios be chosen for audit. When applying for scenario verification, users must specify the auditor, then the server will send an email containing the main information and hyperlink of the pending audit scenario to the auditor as well as a confirmation email to the user. There are some users who have been given permission by the administrator to be auditors as well. All of ‘Pending’ scenarios are listed after the auditor logs in, from which the auditor can then choose to audit, make comments, evaluate, and assign a new status. After that, the scenario owner will receive an email with the audit results.
3.3. Extraction of heating parameters The processed database shown in Fig. 1 is built based on an MDSplus event mechanism, which includes auxiliary heating parameters, profile of the diagnostic system, etc. The heating parameters are analysed data that has been converted from raw data using physical constraints. The raw data that we focus on come from the following diagnostic systems: lower hybrid waves (LHW), ion cyclotron range of frequencies (ICRF), electron cyclotron resonance heating (ECRH), and neutral beam injector (NBI). The value we want to archive in the scenario database is a single fixed power value that is representative of the waveform to make querying possible. A procedure to get this value has been designed and is introduced below. The heating wave often contains noise and singular points like signal ‘pecrh1i’ as show in Fig. 4 (ECRH signal of shot 70031). In order to get the effective value of ECRH, we first set the threshold for each signal so as to get the effective period, i.e. all of the amplitude remains
5. Function realizations Fig. 6 shows the GUI implementation of scenarios query function, in “prepared scenario” module (Fig. 6(a)) and “actual discharge scenario” module (Fig. 6(b)), we can search scenarios according to any keywords by “basic search” and specify detailed keywords by “advanced search”, and we can sort scenarios by any parameters. The brief information list of search result will available and more information will display if you click any site of a scenario. 36
Fusion Engineering and Design 128 (2018) 33–37
W.T. Chai et al.
management system, the discharge scenario query system with audit module has been implemented and is currently in use. By adapting EAST PCS code, MDSplus command, and PHP technology, the scenario parameters have been extracted and stored into a scenario database. In the future, we can combine discharge simulation tools to carry out scenario evaluation and verification. Acknowledgements This work was supported by the National Magnetic Confinement Fusion Research Program of China under Grant No. 2014GB103000 and the National Natural Science Foundation of China under Grant No. 11705239. The authors would like to thank all of the colleagues of the Computer Application Division at the Institute of Plasma Physics, Chinese Academy of Sciences, for their contributions. References [1] W.T. Chai, B.J. Xiao, Q.P. Yuan, R.R. Zhang, The design of remote discharge scenario management system on EAST, Fusion Eng. Des. 112 (2016) 1049–1054. [2] http://www.mdsplus.org. [3] G. Manduchi, T.W. Fredian, J.A. Stillerman, MDSplus evolution continues, Fusion Eng. Des. 87 (2012) 2095–2099. [4] A. Krämer-Flecken, B. Landgraf, J.G. Krom, Experiment management system—a way towards a transparent Tokamak, Fusion Eng. Des. 83 (2008) 375–381. [5] W.P. de Sá, Tokamak TCABR: acquisition system, data analysis, and remote participation using MDSplus, Fusion Eng. Des. 87 (2012) 2199–2202. [6] T. Ozeki, S. Clement-Lorenzo, N. Nakajima, Progress on ITER remote experimentation centre, Fusion Eng. Des. 112 (2016) 1055–1058. [7] Q.P. Yuan, B.J. Xiao, R.R. Zhang, W.T. Chai, J. Liu, R. Xiao, Z.C. Zhou, X.F. Pei, The design of remote participation platform for EAST plasma control, Fusion Eng. Des. 112 (2016) 1045–1048. [8] R.R. Zhang, B.J. Xiao, Q.P. Yuan, F. Yang, Y. Zhang, R.D. Johnson, B.G. Penaflor, The web-based user interface for EAST plasma control system, Fusion Eng. Des. 89 (2014) 558–562.
Fig. 6. Function realization of scenarios query function (a) Webpage of prepared scenarios (b) Webpage of actual discharge scenarios.
6. Conclusion As an important part of EAST remote discharge scenario
37