Contents |
Initial Ideas for Improving the Data Analysis Environment
INTERNAL CORRESPONDENCE
DATE: September 17,1997
FROM: Dave Schissel
TO: DIII-D Data Analysis Programming Group
My experience this summer with the three computer committees afforded me the opportunity to work with both the GA staff and our MIT and PPPL collaborators to better understand the computational needs of the DIII-D organization and how those needs can be satisfied. Drawing on both the detailed work of the three committees and my own analysis, this memo summarizes my draft implementation strategy for creating an enhanced DIII-D data analysis environment. I ask that each of you consider the following, delete or add ideas where appropriate, and be prepared to discuss this strategy soon after my return on October 2. This is the first step in helping us set priorities and work assignments.
The mission statement for the new DIII-D Data Analysis Group should be to increase the data analysis throughput and the data retrieval rate of the DIII-D organization. I believe that, by utilizing an analysis/computer/physics team approach, this mission can be accomplished in two years by creating 1) a unified access to DIII-D raw and analyzed data, 2) rapid access to all of that data, 3) a relational/object-relational database for advanced querying capability, and 4) enhanced computational tools including streamlined analysis, automation where possible, GUI systems, and detailed documentation with easy to use help. Below, I outline how this data environment can be created and some issues that still need to be addressed. Work in all four areas should be started simultaneously; I make no effort to assign relative priorities.
Unified Data Access
Adoption of the MIT MDSplus data system will allow unified access to both raw-shot data as well as analyzed data. This organization system will allow for more rapid data retrieval by the DIII-D group and will help to eliminate the "every man for himself" thinking that has existed in the past. Additionally, central logical storage should ease computer administration issues of McHarg's group. Users will see an immediate benefit in both access to analyzed data (e.g. EFIT, UEDGE) as well as enhanced capability to the 4D tool. Additionally, the MDSplus system easily handles the future of our physics analysis, time-dependent and detailed profile data analysis, and modeling. It must be noted that not all analyzed data will be stored in the relational database described below. For that reason, to be able to allow all users access to all analyzed data, some form of unified data access must be adopted by the DIII-D organization.
The MDSplus system can be ported to UNIX and fully implemented at DIII-D in one year with approximately 2 FTEs worth of support. Given the broad interest in the fusion community for utilizing MDSplus on a variety of experiments, the DIII-D organization should make every effort to have our collaborators (LLNL, MIT, PPPL) supply the majority of the 2 FTE support. This transition will be a two step process. Step One, completed in six months, is the implementation of an Open/VMS MDSplus server with UNIX write capability. Step Two is the transition to a DEC/UX server. The phased implementation of MDSplus will be accomplished with a minimal perturbation on the analysis tasks of the DIII-D organization. The advantages to implementing MDSplus are;
_ a proven system that is used on a number of fusion experiments around the world and a system that will incorporate the existing PTDATA structure.
_ planned adoption of the system at PPPL and LLNL thereby creating a strong collaborator base to work on the system that will ease the GA staff workload required for the UNIX port.
_ our existing tool, 4D, is immediately enhanced since unified data access means access to both raw and analyzed data. There will no longer be the need to have a different display tool for each analysis code. Realize that analyzed data includes the broad range of our physics results such as both transport and stability theory, transport power balance, and divertor data analysis and modeling.
_ unified data access means that there will be better sharing of analyzed results since there will be a common storage strategy.
Data Available On-Line
Data available on-line means that the user no longer needs to know whether a piece of data resides on a local magnetic hard drive or on an off-line storage system. The concept of "restoring a shot to disk" disappears. Instead, an interactive request is made for data (e.g. via 4D), and if that data is on mass storage, the retrieval time is fast enough that the user would be willing to interactively wait (such a system is presently used on CMOD). This storage philosophy adds an incentive for use of the MDSplus system since an individual's disk usage will be separate from MDSplus storage. The entire DIII-D organization will see an immediate benefit from this rapid data retrieval system since quick and easy access to old data allows the group to utilize old data. This is in contrast to the present environment where large scale analysis of old data is not feasible due to the long retrieval times. This type of mass storage system can be created with approximately 0.5 FTE implementation support but will require an initial capital outlay of around $75k. An additional benefit to this storage system is that it will be easy to go back in time and populate the "broad and shallow" relational database with the previous 50,000 DIII-D shots.
The initial step that McHarg's group has taken to acquire a shot server with a 100GB hard disk capacity represents an excellent first step. For the next step, a mass off-line storage system, we need to rely on their expertise to find a system that will fit within our existing hardware operating environment. Future storage capacity requirements and maximum allowable access time must be determined by the DIII-D organization's data analysis requirements. Storage capacity needs are presently being calculated. Trade-offs on retrieval time versus cost will need to be addressed once more detailed solutions have been obtained.
Relational and Object-Relational Databases
A new relational database for the DIII-D organization will be created by combining the attributes of the different public physics datasets (e.g. core and divertor) with those of the private user topical datasets. The new database system will speed up the group's data retrieval capabilities by having a unified source. This new system will have a set of easy-to-use tools that will allow the user community to easily create and join their own datasets to the large DIII-D relational database thereby eliminating the need to have private datasets. The new relational database should be implemented in a two-step strategy over a two year period. Step One is to create a traditional relational database within the first year and will require a dedicated person. At least three new databases will be;
_ a broad and shallow database with at least one record for each past and future DIII-D shot (this task must be coupled with the mass on-line storage system).
_ a "good shot like" database of processed data with attributes that cover the entire range of physics presently performed on DIII-D. This database can be loaded directly from the existing public and private datasets as well as from the MDSplus data system.
_ an electronic notebook for any user to enter variable length text comments on any shot. Since this will be stored in a relational system, queries can be made on the comments.
During the second year, the pros and cons of expanding the existing system to object-relational can be investigated. A prototype object-relational extension to the newly created relational database can be tested and the benefits discussed with the user community to see if a full scale implementation is warranted. Such a system could incorporate profiles, images, and time series that can be queried in a relational sense. This new vision of the future will take the DIII-D organization towards handling time-dependent and detailed profile analysis as opposed to the old single time-slice storage system. Creation and maintenance of the relational database will require a full-time database administrator.
To be able to implement this database strategy in our UNIX environment, a new relational/object-relational database software package must be purchased. Such a purchase should be implemented in a staged fashion with the initial purchase being the relational component and then, if desired, the object-relational component. To give the DIII-D organization maximum flexibility we should avoid purchasing relational database software that does not have an object-relational upgrade path. Software costs vary dramatically depending on what type of system is purchased but the maximum envisioned cost would be approximately $100k. In addition to purchasing the software, a new CPU must be obtained to act as our database engine. The DIII-D organization's relational database needs are still being defined, with the help of the entire computer/physics/analysis team, and represents the majority of the work needed to implement a new relational database.
Computational Tools
Enhancements to analysis tools will concentrate on increasing the data throughput of the DIII-D organization by eliminating analysis bottlenecks, by automating existing codes where possible, and by adoption of graphical interfaces to speed up human interaction with existing codes. At least 3 FTEs would be required to implement the tool strategy over a two year period. Analysis bottlenecks need to be addressed in the following areas:
_ CER analysis should be routinely stored in the MDSplus system from both neural net and CERQUICK analysis. This will allow the organization to use "rough" ion temperature profiles for initial analysis and better pinpoint which profiles need full CER analysis.
_ Is there an identified path to speeding up the full CER analysis? Would a detailed physics benchmark of CERQUICK and full CER help?
_ The kinetic EFIT bottleneck would be eliminated if 4D could produce a beam pressure profile. This upgrade to 4D will allow a kinetic EFIT to be rapidly performed within one analysis tool. In addition to kinetic EFITs, the MDSplus system should routinely store time dependent MSE EFITs.
As already stated, the adoption of MDSplus will bring with it the benefit of an enhanced 4D. The need to no longer support different programs that graphically display analyzed data from EFIT, ONETWO, MLT, DEGAS, UEDGE, GATO, etc., as well as raw data, will ease the FTE requirement for code maintenance. Such GUI enhanced tool tasks include;
_ a clean GUI interface with documentation that will run EFIT, ONETWO, and TRANSP. With the correct implementation it is reasonable to expect anyone in the DIII-D organization to be able to correctly operate these codes and store their results in the MDSplus environment. Eventually, the tool that launches the code can be merged with the code that displays the results. Are there other codes that can be moved into this environment?
_ the tool 4D must be upgraded to completely replace the old ENERGY code. Additionally, can 4D be upgraded to also replace REVIEW? In our present environment it is hard to justify supporting two similar codes.
_ the completion of the tool HPA which allows for time-dependent perturbation analysis. The large number of perturbation sources (RF, edge pellets, gas puff, etc.) on DIII-D require an easy method for analysis.
_ is it reasonable to create GUI interfaces to modeling codes (e.g. MLT, UEDGE) and stability codes (e.g. GATO) so that they may be run by the entire DIII-D organization?
_ a GUI interface to the object-relational database that makes it easy to add data to the database and query what is there. This interface will allow easy transitions into the main MDSplus data repository. Additionally, a user will be able to easily create their own table and join it to any of the existing databases.
Some additional tool tasks include;
_ that existing tools will have to be converted to write into and read from the new MDSplus system.
_ adding on-line help to all GUI tools which can be implemented via the Web. From within each tool a simple HTML viewer can be used for help. Additionally, users can browse the Fusion Group Web site for the same information. This strategy simplifies documentation by making one central repository with multiple access paths.
_ establishing a common library for tools written by users to facilitate sharing of resources.
_ the issue of using thicker or smarter tools. One way to alleviate the load on our present CPU systems and networks is to offload some of the existing workload. For example, does it make sense to give off-site collaborators a new tool and have them use their own resources rather than a new Hydra account and have them use our resources?
Computer and Network Infrastructure
It is already recognized that our existing CPU power and network speed will not be sufficient to support the plans outlined in this memo. Again, we must rely on the expertise of McHarg's group to help us accomplish our goals. Additionally, it makes no sense to implement a system which puts an unrealistic administration and maintenance burden on McHarg's group. Some specific thoughts on this issue are;
_ the planned Hydra upgrade will yield about a factor of 4 increase in CPU power. In the immediate term, the DIII-D organization will most likely need an additional factor of 4 increase. How can this be done in a cost effective manner? In our HP/UX environment, are there machine and system software standards that can be imposed that are not too restrictive from the analysis side but which allow an easy to administer multi-workstation environment thereby yielding a cost-effective CPU upgrade? This may involve retiring old machines that are not worth the headache of administrating.
_ that in the old "every man for himself" environment, a large number of workstations have been purchased for individual use. These machines should be opened up to the entire user community by creating a network of workstations with broader access thereby increasing the DIII-D organization's total CPU power.
_ that we need to identify the "power users" who will benefit from a factor of 10 increase in network speed (10Mb/s to 100 Mb/s) and implement a network upgrade strategy that will help these users. Anyone using the tools described in this memo would be considered a power user.
_ can we drop existing software licenses and use that money saved to increase our existing CPU power? An example is dropping DISSPLA. What is the FTE cost in moving to a new software system and is the money saved worth the conversion time?
.