- Email: [email protected]
Development of a flexible visualization tool
Fusion Engineering and Design 60 (2002) 367– 371 www.elsevier.com/locate/fusengdes
Development of a flexible visualization tool M. Emoto *, K. Shibata, K. Watanabe, S. Ohdachi, K. Ida, S. Sudo National Institute for Fusion Science, 322 -6 Oroshi, Toki-shi, Gifu-ken 509 -5292, Japan
Abstract User-friendly visualization tools are indispensable for quick recognition of experimental data. One such tool, the dwscope component of the MDS-Plus system, is widely used to visualize the data that MDS-Plus acquires. However, the National Institute for Fusion Science does not use MDS-Plus, so our researchers on the Large Helical Device (LHD) project cannot use dwscope without modification. Therefore, we developed a new visualization tool, NIFScope. The user interface of NIFScope is based on JavaScope, which is a Java version of dwscope, but NIFScope has its own unique characteristics, including the following: (1) the GUI toolkit is GTK + ; (2) Ruby is the equation evaluator; and (3) data loaders are provided as Ruby modules. With these features, NIFScope becomes a multi-purpose and flexible visualization tool. For example, because GTK + is a multi-platform open source GUI toolkit, NIFScope can run on both MS-Windows and UNIX, and it can be delivered freely. The second characteristic enables users to plot various equations besides experimental data. Furthermore, Ruby is an object-oriented script language and is widely used on the Internet, allowing it to serve not only as an equation evaluator but also as an ordinal programming language. This means users can easily add new data loaders for their own data formats. © 2002 Elsevier Science B.V. All rights reserved. Keywords: Visualization; Ruby; GTK +
1. Introduction The Kaiseki Server System, or Analyzed Data Server System, provides researchers in NIFS with a unified retrieval method for the various types of physical data [1]. To view and analyze data, on the other hand, most researchers at NIFS use their own programs. This makes it difficult for visitors to NIFS and co-researchers outside the NIFS to visualize the data. There-
* Corresponding author. Tel.: +81-572-58-2242; fax: + 81572-58-2624. E-mail address: [email protected] (M. Emoto).
fore, user-friendly visualization tools are needed for such users. Many visualization tools have been built for nuclear fusion research [2,3]. Among them, dwscope is one of the most widely used. Dwscope would be the best candidate for use at NIFS because its interface is user-friendly. However, there are several reasons why it could not be adopted for NIFS: dwscope depends on the MDSplus system and is based on Motif. Because our LHD project has its own system for serving analyzed data, MDSplus is not used. For this reason, a UNIX environment would be necessary if dwscope were to be used —whereas MS-Windows is the prevailing operating system at NIFS.
0920-3796/02/$ - see front matter © 2002 Elsevier Science B.V. All rights reserved. PII: S 0 9 2 0 - 3 7 9 6 ( 0 2 ) 0 0 0 3 4 - 0
368
M. Emoto et al. / Fusion Engineering and Design 60 (2002) 367–371
Consequently, we developed our own visualization tool, NIFScope. When we set out to design our visualization tool, we outlined several requirements: 1. It must support both MS-Windows and UNIX. 2. It must be distributed freely, without requiring any commercial products. 3. It must visualize not only actual data, but also equations. 4. It must support not only the analyzed data server, but other file formats too. The first and second requirements are for the benefit of co-researchers outside NIFS. The first is intended to support various computers as widely as possible. The second is to eliminate the need to buy commercial software. The third and fourth require-
ments are meant to allow this application to reach a wider group of users. To meet these requirements, three tools were chosen: Cygwin, GTK+ [4], and Ruby [5]. The characteristics of these tools are discussed in a later section.
2. Overview Fig. 1 shows NIFScope running on MS Windows 2000, over-wrapping the original data and the calculated value at once. The drawing pane can be divided into nine areas. The graph can be navigated and zoomed into or out of by moving the mouse, as in dwscope.
Fig. 1. NIFScope running on MS-Windows 2000.
M. Emoto et al. / Fusion Engineering and Design 60 (2002) 367–371
2.1. GTK + NIFScope’s user-friendly GUI was chosen as the GUI of the dwscope. Although the original dwscope uses the Motif interface, we adopted GTK + (short for GIMP Tool Kit). As its name suggests, this toolkit was originally developed for GIMP, which is open-source photo retouch software. However, GTK+ is now widely used for GNOME. The reasons we chose GTK + were: (1) GTK + is open-source ware; and (2) it is independent of any specific operating system. GTK + is distributed freely under the GNU Lesser Generic Public License (LGPL). The fully functional Motif, on the other hand, was not distributed freely when we started to develop NIFScope. GTK + is basically independent of the native window layer, and it provides the same user interfaces across different operating systems. Presently, GTK+ supports both UNIX and MS-Windows environments. However, because user interfaces of dwscope are written in UIL, which is a user interface definition language for Motif, it is difficult to translate UIL into GTK +. Therefore, NIFScope is based on JavaScope [6], the Java implementation of dwscope. Because the grammar of Java is similar to that of C+ + , it is easier to migrate from Java source code to C+ + than from UIL to C+ + . The reason why NIFScope was not written in Java directly is that use of a Java application requires the user to have Java Virtual Machine (JVM) to be installed, which would be a cumbersome task for users. Another reason for choosing C + + is that a macro language is needed to incorporate into NIFScope. As mentioned in a later section, Ruby was chosen as the macro language, and Ruby interfaces are supplied only for C language.
2.2. Cygwin Cygwin provides various UNIX-like commands for an MS-Windows environment. The main component of Cygwin is cygwin.dll, a dynamic library. Cygwin.dll emulates UNIX’s system-call under MS-Windows. With this library, non-GUI applications for UNIX can be com-
369
piled on MS-Windows without any modification, or with less modification than using the MS-Windows native library directly. NIFScope uses cygwin.dll to support MS-Windows, and the same source tree is used for the Linux operating system.
2.3. Ruby In order to produce more-analytical graphs, a visualization tool must recognize the equations the user types. To evaluate equations, we had two options: (1) to make our own macro language, or (2) to incorporate an existing language. The first option would provide the advantages of compactness and optimization. However, building our own language would also impose a maintenance cost on programmers. On the other hand, incorporating an existing language would make the application larger, but would also allow it to be separated from other components. Because of the maintenance costs, we decided on the second option, and chose Ruby as the language to incorporate. Ruby is an object-oriented script language, and it is widely used to write CGI and other text processing programs because of its concise but powerful text-processing feature. Because the analyzed data are served as text files, the text-processing feature of Ruby is useful. Furthermore, because most of the functions, such as creating objects and evaluating Ruby code, are provided by the C Library, Ruby is easily incorporated into other programs. Ruby is a pure object-oriented language, and everything is implemented as an object. Because the programs written in object-oriented languages create more temporary objects during the runtime than do other programs, they must have garbage collectors to clean unused memory blocks. The Ruby garbage collector has unique characteristics. When returning from a subroutine, the garbage collector looks up the stacks to find any objects referred from no other objects. If it finds any, it cleans them up to free their memory. Because this mechanism can be used from a native program incorporating the Ruby interpreter, the program does not take any responsibility to release the memory of unused objects.
370
M. Emoto et al. / Fusion Engineering and Design 60 (2002) 367–371
Fig. 2. Static relations of DataLoader interface and Data class.
Ruby’s operator overloading feature was another reason to choose this language. Operator overloading allows an operator to change its treatment for each object. This is important for scientific calculations. For example, an operator ‘ ’ is used to multiply two objects, but the multiplication procedures are different among float, complex, matrix, and so on. In NIFS, PV-Wave and IDL are widely used to visualize data. They each implement the production operator, ‘ ’, in a different way. They treat the multiplication of two matrixes C= A B as, Ci,j =Ai,j Bi,j instead of as an ordinal matrix product operation. NIFScope supports such operations for PV-Wave users. In order to realize such operations, the NArray class, which is derived from the Array class, is defined. Because the NArray class implements basic arithmetic operators, it can be used the way that other basic types, like integer or float, are used. With this overloading technique, users can write an expression like x y This is more natural than writing x.multiply(y) Some object-oriented languages, such as C+ + and CLOS, support operator overloading, but they are not as easy to use as Ruby. When
overloading the product operator for a new class, these languages require that all procedures for production between the new class and existing types must be written. However, using Ruby’s ‘coerce’ method, Ruby can change an existing type into another type dynamically, and the programmers do not need to write code for each type.
2.4. Loadable module To support various data types, the components that depend on the system are provided as modules and are separated from other components. By this design, NIFScope can allow users’ own data formats to be visualized. The module is a set of related classes and methods, and is loaded dynamically. The module can be written in either C or in Ruby. The modules written in C are compiled into dynamic link objects, while the modules written in Ruby are interpreted at run-time. C modules are superior to Ruby modules in speed, but Ruby modules are more readable and easier to maintain than those written in C. Therefore, the modules for existing data are provided as Ruby modules. At present, NIFScope provides the data loaders for both the Analyzed Data Server and the Raw Data Server [7], but it is easy to support other data systems. Because of the dynamical loading mechanism, the new loader can be used without modifying other components. The static class relations of the modules are shown in Fig. 2. Each DataLoader
M. Emoto et al. / Fusion Engineering and Design 60 (2002) 367–371
module – –for example, KaisekiLoader for Kaiseki data and LABCOMLoader for LABCOM data– – implements the Loader module’s ‘load’ and ‘list’ methods. The ‘load’ method loads experimental data and returns Data objects; the ‘list’ method shows the hierarchical structure of the data archive.
371
didates. For instance, Tool Command Language (TCL) and python are widely used as glue languages. Compared to these languages, Ruby is easy to learn because its object-oriented feature is naturally integrated into traditional procedure languages. At the next step, we plan to use Ruby for other programs to make them customizable.
3. Discussion and conclusion We have demonstrated the NIFScope and its flexibility. NIFScope uses GTK+ to support both MS-Windows and UNIX, and it uses Ruby modules to make it independent of data server systems. The application must support a variety of circumstances. Because advances in computers arrive quite a lot faster than advances in diagnostics technology, the application must be modularized and flexible to support new systems. Implementing a macro language into the application makes the application flexible, and it enables users to customize and extend the application more easily. Though NIFScope chose Ruby as such a language, there were other can-
References [1] S. Ohdachi, et al., Annual Report of National Institute for Fusion Science April 1999 –March 2000, p. 164. [2] Stillerman et al., MDSplus data acquisition system, Rev. Sci. Instrum. 68 (1997) 939 – 942. [3] J. Schachter, et al., Data analysis software tools for enhanced collaboration at the DIII-D National Fusion Facility, Fus. Eng. Des. 48 (2000) 91 – 98. [4] http://www.gtk.org/ [5] http://www.ruby-lang.org/en/ [6] G. Manduchi, The Java interface of MdsPlus: towards unified approach for local and remote data access, Fus. Eng. Des. 48 (2000) 163 – 170. [7] H. Nakanishi, et al., Distributed processing and network of data acquisition and diagnostics control for large helical device (LHD), Fus. Eng. Des. 43 (1999) 293 – 300.
Development of a flexible visualization tool M. Emoto *, K. Shibata, K. Watanabe, S. Ohdachi, K. Ida, S. Sudo National Institute for Fusion Science, 322 -6 Oroshi, Toki-shi, Gifu-ken 509 -5292, Japan
Abstract User-friendly visualization tools are indispensable for quick recognition of experimental data. One such tool, the dwscope component of the MDS-Plus system, is widely used to visualize the data that MDS-Plus acquires. However, the National Institute for Fusion Science does not use MDS-Plus, so our researchers on the Large Helical Device (LHD) project cannot use dwscope without modification. Therefore, we developed a new visualization tool, NIFScope. The user interface of NIFScope is based on JavaScope, which is a Java version of dwscope, but NIFScope has its own unique characteristics, including the following: (1) the GUI toolkit is GTK + ; (2) Ruby is the equation evaluator; and (3) data loaders are provided as Ruby modules. With these features, NIFScope becomes a multi-purpose and flexible visualization tool. For example, because GTK + is a multi-platform open source GUI toolkit, NIFScope can run on both MS-Windows and UNIX, and it can be delivered freely. The second characteristic enables users to plot various equations besides experimental data. Furthermore, Ruby is an object-oriented script language and is widely used on the Internet, allowing it to serve not only as an equation evaluator but also as an ordinal programming language. This means users can easily add new data loaders for their own data formats. © 2002 Elsevier Science B.V. All rights reserved. Keywords: Visualization; Ruby; GTK +
1. Introduction The Kaiseki Server System, or Analyzed Data Server System, provides researchers in NIFS with a unified retrieval method for the various types of physical data [1]. To view and analyze data, on the other hand, most researchers at NIFS use their own programs. This makes it difficult for visitors to NIFS and co-researchers outside the NIFS to visualize the data. There-
* Corresponding author. Tel.: +81-572-58-2242; fax: + 81572-58-2624. E-mail address: [email protected] (M. Emoto).
fore, user-friendly visualization tools are needed for such users. Many visualization tools have been built for nuclear fusion research [2,3]. Among them, dwscope is one of the most widely used. Dwscope would be the best candidate for use at NIFS because its interface is user-friendly. However, there are several reasons why it could not be adopted for NIFS: dwscope depends on the MDSplus system and is based on Motif. Because our LHD project has its own system for serving analyzed data, MDSplus is not used. For this reason, a UNIX environment would be necessary if dwscope were to be used —whereas MS-Windows is the prevailing operating system at NIFS.
0920-3796/02/$ - see front matter © 2002 Elsevier Science B.V. All rights reserved. PII: S 0 9 2 0 - 3 7 9 6 ( 0 2 ) 0 0 0 3 4 - 0
368
M. Emoto et al. / Fusion Engineering and Design 60 (2002) 367–371
Consequently, we developed our own visualization tool, NIFScope. When we set out to design our visualization tool, we outlined several requirements: 1. It must support both MS-Windows and UNIX. 2. It must be distributed freely, without requiring any commercial products. 3. It must visualize not only actual data, but also equations. 4. It must support not only the analyzed data server, but other file formats too. The first and second requirements are for the benefit of co-researchers outside NIFS. The first is intended to support various computers as widely as possible. The second is to eliminate the need to buy commercial software. The third and fourth require-
ments are meant to allow this application to reach a wider group of users. To meet these requirements, three tools were chosen: Cygwin, GTK+ [4], and Ruby [5]. The characteristics of these tools are discussed in a later section.
2. Overview Fig. 1 shows NIFScope running on MS Windows 2000, over-wrapping the original data and the calculated value at once. The drawing pane can be divided into nine areas. The graph can be navigated and zoomed into or out of by moving the mouse, as in dwscope.
Fig. 1. NIFScope running on MS-Windows 2000.
M. Emoto et al. / Fusion Engineering and Design 60 (2002) 367–371
2.1. GTK + NIFScope’s user-friendly GUI was chosen as the GUI of the dwscope. Although the original dwscope uses the Motif interface, we adopted GTK + (short for GIMP Tool Kit). As its name suggests, this toolkit was originally developed for GIMP, which is open-source photo retouch software. However, GTK+ is now widely used for GNOME. The reasons we chose GTK + were: (1) GTK + is open-source ware; and (2) it is independent of any specific operating system. GTK + is distributed freely under the GNU Lesser Generic Public License (LGPL). The fully functional Motif, on the other hand, was not distributed freely when we started to develop NIFScope. GTK + is basically independent of the native window layer, and it provides the same user interfaces across different operating systems. Presently, GTK+ supports both UNIX and MS-Windows environments. However, because user interfaces of dwscope are written in UIL, which is a user interface definition language for Motif, it is difficult to translate UIL into GTK +. Therefore, NIFScope is based on JavaScope [6], the Java implementation of dwscope. Because the grammar of Java is similar to that of C+ + , it is easier to migrate from Java source code to C+ + than from UIL to C+ + . The reason why NIFScope was not written in Java directly is that use of a Java application requires the user to have Java Virtual Machine (JVM) to be installed, which would be a cumbersome task for users. Another reason for choosing C + + is that a macro language is needed to incorporate into NIFScope. As mentioned in a later section, Ruby was chosen as the macro language, and Ruby interfaces are supplied only for C language.
2.2. Cygwin Cygwin provides various UNIX-like commands for an MS-Windows environment. The main component of Cygwin is cygwin.dll, a dynamic library. Cygwin.dll emulates UNIX’s system-call under MS-Windows. With this library, non-GUI applications for UNIX can be com-
369
piled on MS-Windows without any modification, or with less modification than using the MS-Windows native library directly. NIFScope uses cygwin.dll to support MS-Windows, and the same source tree is used for the Linux operating system.
2.3. Ruby In order to produce more-analytical graphs, a visualization tool must recognize the equations the user types. To evaluate equations, we had two options: (1) to make our own macro language, or (2) to incorporate an existing language. The first option would provide the advantages of compactness and optimization. However, building our own language would also impose a maintenance cost on programmers. On the other hand, incorporating an existing language would make the application larger, but would also allow it to be separated from other components. Because of the maintenance costs, we decided on the second option, and chose Ruby as the language to incorporate. Ruby is an object-oriented script language, and it is widely used to write CGI and other text processing programs because of its concise but powerful text-processing feature. Because the analyzed data are served as text files, the text-processing feature of Ruby is useful. Furthermore, because most of the functions, such as creating objects and evaluating Ruby code, are provided by the C Library, Ruby is easily incorporated into other programs. Ruby is a pure object-oriented language, and everything is implemented as an object. Because the programs written in object-oriented languages create more temporary objects during the runtime than do other programs, they must have garbage collectors to clean unused memory blocks. The Ruby garbage collector has unique characteristics. When returning from a subroutine, the garbage collector looks up the stacks to find any objects referred from no other objects. If it finds any, it cleans them up to free their memory. Because this mechanism can be used from a native program incorporating the Ruby interpreter, the program does not take any responsibility to release the memory of unused objects.
370
M. Emoto et al. / Fusion Engineering and Design 60 (2002) 367–371
Fig. 2. Static relations of DataLoader interface and Data class.
Ruby’s operator overloading feature was another reason to choose this language. Operator overloading allows an operator to change its treatment for each object. This is important for scientific calculations. For example, an operator ‘ ’ is used to multiply two objects, but the multiplication procedures are different among float, complex, matrix, and so on. In NIFS, PV-Wave and IDL are widely used to visualize data. They each implement the production operator, ‘ ’, in a different way. They treat the multiplication of two matrixes C= A B as, Ci,j =Ai,j Bi,j instead of as an ordinal matrix product operation. NIFScope supports such operations for PV-Wave users. In order to realize such operations, the NArray class, which is derived from the Array class, is defined. Because the NArray class implements basic arithmetic operators, it can be used the way that other basic types, like integer or float, are used. With this overloading technique, users can write an expression like x y This is more natural than writing x.multiply(y) Some object-oriented languages, such as C+ + and CLOS, support operator overloading, but they are not as easy to use as Ruby. When
overloading the product operator for a new class, these languages require that all procedures for production between the new class and existing types must be written. However, using Ruby’s ‘coerce’ method, Ruby can change an existing type into another type dynamically, and the programmers do not need to write code for each type.
2.4. Loadable module To support various data types, the components that depend on the system are provided as modules and are separated from other components. By this design, NIFScope can allow users’ own data formats to be visualized. The module is a set of related classes and methods, and is loaded dynamically. The module can be written in either C or in Ruby. The modules written in C are compiled into dynamic link objects, while the modules written in Ruby are interpreted at run-time. C modules are superior to Ruby modules in speed, but Ruby modules are more readable and easier to maintain than those written in C. Therefore, the modules for existing data are provided as Ruby modules. At present, NIFScope provides the data loaders for both the Analyzed Data Server and the Raw Data Server [7], but it is easy to support other data systems. Because of the dynamical loading mechanism, the new loader can be used without modifying other components. The static class relations of the modules are shown in Fig. 2. Each DataLoader
M. Emoto et al. / Fusion Engineering and Design 60 (2002) 367–371
module – –for example, KaisekiLoader for Kaiseki data and LABCOMLoader for LABCOM data– – implements the Loader module’s ‘load’ and ‘list’ methods. The ‘load’ method loads experimental data and returns Data objects; the ‘list’ method shows the hierarchical structure of the data archive.
371
didates. For instance, Tool Command Language (TCL) and python are widely used as glue languages. Compared to these languages, Ruby is easy to learn because its object-oriented feature is naturally integrated into traditional procedure languages. At the next step, we plan to use Ruby for other programs to make them customizable.
3. Discussion and conclusion We have demonstrated the NIFScope and its flexibility. NIFScope uses GTK+ to support both MS-Windows and UNIX, and it uses Ruby modules to make it independent of data server systems. The application must support a variety of circumstances. Because advances in computers arrive quite a lot faster than advances in diagnostics technology, the application must be modularized and flexible to support new systems. Implementing a macro language into the application makes the application flexible, and it enables users to customize and extend the application more easily. Though NIFScope chose Ruby as such a language, there were other can-
References [1] S. Ohdachi, et al., Annual Report of National Institute for Fusion Science April 1999 –March 2000, p. 164. [2] Stillerman et al., MDSplus data acquisition system, Rev. Sci. Instrum. 68 (1997) 939 – 942. [3] J. Schachter, et al., Data analysis software tools for enhanced collaboration at the DIII-D National Fusion Facility, Fus. Eng. Des. 48 (2000) 91 – 98. [4] http://www.gtk.org/ [5] http://www.ruby-lang.org/en/ [6] G. Manduchi, The Java interface of MdsPlus: towards unified approach for local and remote data access, Fus. Eng. Des. 48 (2000) 163 – 170. [7] H. Nakanishi, et al., Distributed processing and network of data acquisition and diagnostics control for large helical device (LHD), Fus. Eng. Des. 43 (1999) 293 – 300.