Master's Thesis - Computer Graphics and Visualization - TU Delft

A Graphical Programming Environment 

for Culgi 

Master’s Thesis 

1189662 

Ruixin Wang 

July 2005

TU Delft 

Faculty EEMCS 

Computer Graphics & CAD CAM 

Leiden University 

Gorlaeus Laboratories 

Soft Condensed Matter Group

Preface 

This project started in September, 2004, and ended in July, 2005. It is conducted at the Computer 

Graphics & CAD/CAM Group at Delft University of Technology and the Soft Condensed Matter 

Group at Leiden University. 

The original motivation of this project is to develop a user interface in which users can do simulations 

easily with the Culgi Library. After the analysis of the users and their characteristics in the first two 

months, we decided to make a graphical programming environment (the Culgi GPE in short) in which 

users can generate Culgi simulation programs by clicking, dragging and dropping. Then in the 

following months, we designed and developed a prototype for the Culgi GPE. Within this prototype, 

users can make a simulation program much easier than in the traditional way. I am happy that the 

customers and the users like this prototype. 

I am very grateful to all of my supervisors: Prof. Hans Fraaije, Frits Post, Gerwin de Haan and Agur 

Sevink. They helped me a lot from the very beginning to the end of this project. What I learned from 

their suggestions are not only on how to design the Culgi GPE, but also on how to think, how to 

analyze, and how to present. I believe that what I learned from my supervisors will make me perform 

better in my future. 

Meanwhile, thanks Charl Botha in the Graphics & CAD CAM Group in TU Delft. He showed me his 

system DeVIDE, and gave some very good suggestions on how to design and how to implement the 

system. Thanks to all the colleagues of Culgi. Their feedback of the prototype made me improve this 

prototype a lot. Thanks to all the friends in the Soft Condensed Matter Group in Leiden University. 

They are always kind when I need help. 

- 1 - 

Ruixin Wang 

20-08-05 

Delft

- 2 -

Abstract 

Culgi stands for Chemistry Unified LanGuage Interface and is a new software package for combined 

research in chemical modeling and property prediction. It provides a powerful library which allows 

integrated modeling of molecular scale and nanoscale for the first time. With the commands from this 

library, users can build a simulation application. But the users of Culgi are chemists, most of whom are 

non-programmers. Programming in the traditional way is not easy and time consuming for them. Thus 

a new tool is needed to help the users in programming with the Culgi Library. 

The Culgi GPE (Culgi Graphical Programming Environment) is an experimental interactive system 

designed and developed to serve this purpose. As a graphical programming environment, it uses 

modules as the basic building blocks. A module is a visual programming element which contains 

several commands from the Culgi Library. Considering the requirements from different levels of users, 

such as novices and skilled users, it exploits several programming models to build a simulation 

program. It also provides a module editor in which users can make new modules themselves. The 

applications made in the Culgi GPE can be exported as Tcl source codes as well. 

- 1 -

- 2 -

Contents 

Abstract........................................................................................................................................ - 1 - 

Chapter 1 Introduction ................................................................................................................. - 1 - 

Chapter 2 Requirement Analysis.................................................................................................. - 5 - 

2.1 General Requirements........................................................................................................ - 5 - 

2.2 Specific requirements......................................................................................................... - 7 - 

Chapter 3 Design Models........................................................................................................... - 13 - 

3.1 The Network Editor.......................................................................................................... - 13 - 

3.2 The Sequence Editor ........................................................................................................ - 15 - 

3.3 The Concept Editor .......................................................................................................... - 17 - 

3.4 Possible solutions and transforms .................................................................................... - 20 - 

3.5 Modules............................................................................................................................ - 20 - 

3.6 Export resulting applications with GUIs.......................................................................... - 24 - 

3.7 Conclusion ....................................................................................................................... - 25 - 

Chapter 4 Implementation of the Culgi GPE ............................................................................. - 27 - 

4.1 System Overview ............................................................................................................. - 27 - 

4.2 Module ............................................................................................................................. - 29 - 

4.3 Module Library ................................................................................................................ - 33 - 

4.4 Kernel............................................................................................................................... - 33 - 

4.5 The user interface............................................................................................................. - 34 - 

Chapter 5 Results and Test......................................................................................................... - 41 - 

5.1 Result ............................................................................................................................... - 41 - 

5.2 Test and Feedback............................................................................................................ - 48 - 

Chapter 6 Conclusion................................................................................................................. - 51 - 

Chapter 7 Bibliography.............................................................................................................. - 53 - 

Appendix A. Class Diagrams ..................................................................................................... - 55 - 

Appendix B. Tables.................................................................................................................... - 59 - 

Appendix C. DPD Simulation.................................................................................................... - 67 - 

- 1 -

- 2 -

Chapter 1 Introduction 

Culgi stands for Chemistry Unified LanGuage Interface. It is a new software package in combined 

research in chemical modeling and property prediction. It supplies a powerful C++ Library, named the 

Culgi Library, which allows integrated modeling of molecular scale and mesoscale for the first time [4]. 

With the functions supplied by the Culgi Library, users can do Molecular Dynamics (MD) simulations, 

Dissipative Particle Dynamics (DPD) simulations, MesoDyn simulations, and a Hybrid simulation of 

DPD and MesoDyn. 

(a) MD (b) DPD 

(c) MesoDyn (d) Hybrid 

Figure 1-1 simulation examples 

Molecular dynamics (MD) simulation numerically solves Newton's equations of motion on an 

atomistic or similar model of a molecular system to obtain information about its time-dependent 

properties [10]. As can be seen from Figure 1-1(a), each sphere in this picture represents an atom. 

Dissipative Particle Dynamics (DPD) is a technique for simulating complex fluids such as surfactant 

solutions and copolymer melts. A development of MD and lattice gas automata, DPD represents 

- 1 -

long-range hydrodynamic forces directly in its equations of motion allowing more realistic modeling of 

the dynamics of phase separation and other processes depending on large length-scale interactions. In 

the DPD methodology, the fundamental particles are "beads" that represent small regions of fluid 

material rather than the atoms and molecules familiar from MD simulations. All degrees of freedom 

smaller than a bead radius are assumed to have been integrated out leaving only coarse-grained 

interactions between beads [11]. As can be seen from Figure 1-1(b), each sphere in this picture 

represents a bead. 

MesoDyn is a new tool for the prediction of mesoscale structures of soft-condensed matter. These are 

the patterns of size 10 to 100 nm which can be found for example in polymer blends, block-copolymer 

systems, surfactant aggregates in detergent materials (e.g. shampoo), latex particles, or drug delivery 

systems [11]. As can be seen from Figure 1-1(c), the big sphere in this picture represents an oil droplet. 

A hybrid simulation is a combination of the DPD simulation and MesoDyn simulation [4]. In Figure 

1-1(d), each small sphere is a bead, and the big sphere is an oil droplet. 

There are two ways for users to build a simulation program using the Culgi Library. First, users can 

develop a program in C++ which includes the Culgi Library. This way is straightforward for 

experienced C++ programmers. But because most users of Culgi are chemists without background in 

programming, building a C++ program for them is too difficult or almost impossible. So this way is 

only welcomed by a few users who know C++. Second, the Culgi Library can be packed into a 

dynamic library file which can be accessed by other more accessible programming languages like Tcl. 

Then, users can compose a script in which Culgi commands are used (See Figure 1-2). This way is 

used much more often than the first way, because some of the Culgi users are familiar with Tcl script. 

Appendix C shows the Tcl source code of the DPD simulation example shown in Figure 1-1(b). As can 

be seen from this example, one hundred lines of source code are needed to make a simple DPD 

simulation program. It is still not very easy for the majority of the users. 

Culgi Library 

by C++ 

Culgi.dll 

+ 

Tcl 

Interpreter 

Scripts 

Figure 1-2. Current way to use Culgi Library 

Thus, a software environment is needed in order to help the users build simulation applications 

efficiently and easily. The assignment for this project is to design and develop a prototype for such an 

environment. 

In the research report of this project [12], we analyzed the users of Culgi and gave out a user-user 

- 2 -

elationship model (see Figure 1-3). In this model, “Culgi Developers” refers to the people who 

develop the Culgi software package; “Application Authors” here mainly refers to industry 

computational chemists (ICCs), who know some in programming and are able to develop small 

programs; and “End Users” here mainly refers to bench chemists (BCs), who don’t know programming 

but need to use simulation applications to do simulation in order to predict possible solutions to a 

special problem. In general, the simulation application to bench chemists should contain a Graphical 

User Interface, in which uses can set the values to some parameters about a simulation. Then the 

application should perform calculations to predict the result. 

Culgi Developers 

Components or functions 

Application Authors (ICCs) 

Applications 

End Users (BCs) 

Figure 1-3. The user-user relationship model 

This user-user relationship model means that the Culgi developers develop the Culgi software package 

for the application authors. Then the application authors build simulation applications with Culgi for 

the end users. Thus ICCs are the Culgi target group, and BCs are Culgi end users. The end users can 

communicate with the application authors and put forward their requirements and suggestions directly. 

Then the application authors should make simulation programs to solve some special problems for end 

users. If the application authors can not solve the problem themselves or they need new functions in 

Culgi Library, they can contact the Culgi developers. The Culgi developers will develop new functions 

according to the suggestions from the application authors. 

Because the Application Authors are not professional programmers, we concluded that we need a 

programming environment to help the application authors to develop simulation applications. This 

system should provide a programming editor which makes programming easy; as well as be able to 

export an end user application with a Graphics User Interface (GUI) for the end users. By studying the 

various concepts in current programming environments, a conclusion is made that the system to be 

designed should be a graphical programming environment in which a program can be built by clicking, 

- 3 -

dragging and dropping. This system is called the Culgi GPE (Graphical Programming Environment). 

In general, the Culgi GPE should integrate the Culgi Library and the Tcl interpreter, and provide a 

user-friendly interface to the application authors. Within the Culgi GPE, users can program 

interactively by dragging-and-dropping, selecting some values, and typing in some parameters. Then, 

users can run their programs specified in this system. Meanwhile, the users’ programs can be exported 

into a Tcl script file including a GUI, which can run without the Culgi GPE. Figure 1-4 shows the 

position of the Culgi GPE in the overview of the whole Culgi package. 

Culgi Library 

by C++ 

Culgi.dll 

+ 

Tcl 

Interpreter 

The Culgi 

GPE 

Users 

Figure 1-4. The Culgi GPE 

Interaction 

Scripts 

In this report, chapter 2 analyzes the functional requirements and non-functional requirements 

particularly. Chapter 3 explains the programming models to build a simulation program. Besides the 

Sequence Editor and the Concept Editor, a model named the Network Editor is also described although 

it is not a successful solution to the Culgi GPE. Chapter 3 also particularly describes the design on 

modules as well. Then chapter 4 introduces the main architecture and implementation of the whole 

system (the detailed introduction about the definitions of class are in Appendix A). Chapter 5 shows the 

result of the implementation and the feedback from users. Finally, Chapter 6 draws some conclusions 

and suggests future work. 

- 4 -

Chapter 2 Requirement Analysis 

This project deals with the design and development of a prototype of the Culgi GPE. This prototype 

supplies a visual programming mechanism to the users who have little experience in programming. The 

purposes of this mechanism are to allow users to build a chemistry simulation program in just a few 

hours; also, to export the source code of the users’ programs automatically. The prototype will 

implement some basic functionality to achieve these goals. 

This chapter defines the functional and nonfunctional requirements of the Culgi GPE. Section 2.1 will 

give an overall description of the requirements and section 2.2 will give a specification requirement 

analysis. 

2.1 General Requirements 

The Culgi GPE is a subset of the whole Culgi Package. It will be an interface between the Culgi library 

and the users, and a bridge between the Culgi Library and Tcl Scripts. As a graphical programming 

environment, it allows users to build a chemistry simulation program in just a few hours. And it can 

export an end user application automatically which consists of the source code of the users’ programs 

as well as the end user GUI. Figure 1-4 shows the overview of the Culgi GPE. This section describes 

the characteristics of the target group, and the hardware and software interface to this system. Then it 

concludes the overall requirements to the system. 

2.1.1 User characteristics 

This section will describe users’ characteristics. The target group of the Culgi GPE consists of 

computational chemists who may work in a large scale or medium scale company. They need to create 

efficient simulation programs that simulate the movements of the molecules according to the properties 

of the modules in a specified environment. And then their simulation programs will be applied to 

concrete chemistry projects or to specific chemical problems. 

In general, the people in the target group have the following characteristics. 

1) They have a good background in chemistry. They are knowledgeable about molecular simulation, 

Dissipative Particle Dynamic simulation and so on. 

2) They are non-programmers and even never write scripts themselves. They use computers and 

software packages to help them do the work much more efficiently. 

3) They need a program to do the simulation, but they do not want to invest much energy and time on 

both programming and learning to programming. What they want is to build a simulation program 

in just a few hours. 

- 5 -

2.1.2 Interface analysis 

This section explains the external requirements of the Culgi GPE, like the hardware interface, software 

interface and the system platform. Table 2-1 shows this information in general. 

Table 2-1 Overall situation of the Culgi GPE 

Item Culgi’s situation 

Platform - Cross platform 

Hardware interface - The Culgi GPE will run in personal computer. 

Software interface - The Culgi Library 

- The Tcl interpreter. 

As shown in Table 2-1 , the Culgi GPE will run on various platforms, at least on Windows and on 

Linux. And it is designed to run on a personal computer, so there are no special requirements in 

hardware. 

The Culgi GPE should have interfaces with the Culgi Library and Tcl interpreter. It should be able to 

load Tcl interpreter into the system, and then load the Cuigi library into the Tcl interpreter. 

Because the Culgi GPE is a bridge of the Culgi Library and Tcl scripts, it is very important to study the 

Culgi Library. The features of the commands in the Culgi library are listed below. 

1. The data types of almost all arguments of the Culgi commands are some primitive types, like string, 

integer or double. Culgi stores most of the data in some special structure which is hidden from the 

users. For example, the command BrownianDynamics, whose functionality is to calculate the next 

positions of the molecules, takes the time of calculation as the only arguments. Those data are 

stored in some global variables, and BrownianDynamics operates on these variables. 

2. The operations in the Culgi commands do not change the arguments. For example, in 

CreateDPDMolecules, an argument that needs to be set is the name of a molecule, whose data type 

should be string. But after this command has been executed, this string is still a string with no 

change in its contents. Only the Culgi system knows that there are some molecules in the system 

now having this name. 

3. The return values of the Culgi commands are void or string. The real data structure that stores the 

data is not returned. 

4. Some commands take the same arguments. The argument in a command some times will be 

referred to in another command. For example, the command CreateDPDMolecule takes the name 

of the module as a parameter. Then some other commands, like AddMoleculesViewable, may refer 

to this parameter in order to get the instance of the molecules. 

5. The general pipeline of a simulation program with Culgi consists of three steps. 

1) Create molecule models by giving the composition of each type of molecules. 

2) Create rendering windows and set the window if a user wants to make the simulation progress 

visible. 

3) Set the properties to the molecules and launch the simulation. 

6. The structures of the simulation programs of Culgi are always a sequence of commands. Almost no 

control structures are used, like “If-else” and “switch”. The only control structure used is a kind of 

- 6 -

loop in which users only need to specify the time of this loop. 

7. The Culgi library is still in development. It is possible that some of the existing commands will be 

replaced or deleted in future. 

2.1.3 Product functions 

From the general description of this product, the users’ characteristics and the interface analysis, the 

Culgi GPE should have following functionalities: 

1) To load Tcl interpreter into the system and be able to access the Culgi Library. 

2) To represent the commands in the Culgi Library in a visual way. Each presentation unit is called a 

module. A module should have properties, contents and interface. The contents of a module should be a 

Tcl script which includes one or more Culgi commands. The interface should be an API that users 

could manipulate. Modules will be the primary building blocks of a program. 

3) To have a module library to manage modules. Modules are used to represent the commands in the 

Culgi Library. But there will be several hundreds of commands in the Culgi Library. So the number of 

modules will be big as well. In this case, a module library to manage these modules is necessary. 

4) To provide interaction between users and modules. Users should be able to create or delete the 

instance of the module, should be able to communicate with the module. 

5) To run the program composed of modules. 

6) Debug users’ programs. 

7) To export the source code of the users’ programs automatically with the end user GUIs. We call 

the export program an end user application. 

8) To have an easy-to-use user interface that should wait for users’ commands and then execute the 

corresponding actions. 

9) To provide Enough help information on not only the function of modules and parameters, but also 

on the interface itself. 

In this section, we give out the overall description of the Culgi GPE. Basing on these general 

requirements to the system, the section 2.2 explains the particular requirements. 

2.2 Specific requirements 

This section describes the functional and non functional requirements in detail. In section 2.1.1 , a 

scenario is described to show how a user uses the Culgi GPE to achieve the goal successfully. Based on 

this scenario, a Use Case Model 1 is defined to specify the features of the system. Then in section 2.2.2, 

a detailed function list is presented. This list is concluded from the use case model. 

1 The UP (Unified Process) defines the Use-Case Model within the Requirements discipline. Primarily, 

this is the set of all written use cases; it is a model of the system's functionality and environment [1]. A 

use case describes a sequence of actions that provide something of measurable value to an actor. An 

actor here refers to a user in the system. 

- 7 -

2.2.1 The use case model 

In this part, a scenario in which a user uses the Culgi GPE to achieve the goal successfully is proposed. 

And then based on this scenario, we will analyze the detailed requirements of The Culgi GPE in the 

next part. 

A user wants to build a Tcl scipt to do chemistry simulation with the Culgi Library. He starts the Culgi 

GPE and opens a new file. Then he sees that there are three parts in the interface, they are menus, 

module library and canvas. He first chooses the right module he wants in the library, and then he needs 

to create the instance of the module in the canvas. Suppose he just does drag and drop, a new instance 

of the module is appeared in the canvas. Then he would set some values to the module according to his 

target. After repeating these steps several times, he has already collected enough modules to do the 

simulation. Then he needs to make sure that the system will run these modules in the right order. After 

defining the running order, he runs the program. Finally he exports Tcl script of this program. 

2.2.2 Use case model 

Based on the scenario, we will define the use case model. The use case model treats the Culgi GPE as a 

black box and describes the interaction between external actors (users) and the Culgi GPE. It is about 

how a user uses the Culgi GPE and what the Culgi GPE will do in response to the user’s request, 

without assuming how the system works internally. 

- 8 -

Primary actor: 

-Simulation Program Authors 

Stakeholders and Interests: 

-Simulation Program Authors: wants to find the right modules in the module library, wants to use 

these modules to build a simulation program, test this simulation program and export a source 

code of this program. 

Preconditions: 

-The simulation problem can be solved by the Culgi Library. 

-The module library contains the right modules. 

Success Guarantee: 

-A Simulation program is built in the Culgi GPE and produces a correct simulation result. 

-A corresponding Tcl script of the simulation program is generated and runs properly. 

Main Success Scenario (Basic Flow): 

1. A user (a simulation program author) runs the Culgi GPE, and wants to create a new 

simulation program. 

2. The user selects a module in the modules library according to the module name. 

3. The user puts this module in the canvas. The Culgi GPE shows the module on the canvas 

4. The user sets the parameters of the module. 

5. The user specifies the logical relationships among modules. 

The user repeats the steps from 3 to 7 until the he or she thinks that the program is finished 

6. The user runs the program. The Culgi GPE will show the running result or a graphics 

window. 

7. The user chooses some parameters of modules show on the canvas, and exports the program 

into Tcl script. 

8. A Tcl program is created by the system with an end-user GUIS, in which the parameters 

checked in last step are open to be set. 

Extensions (Alternative Flows): 

a Whenever users want to save the current program that can be used later, the system should 

supply the functionality like “Save” or “Save as”. 

1a. The user wants to build a simulation program continuing previous work. 

1. He will open a file in Culgi GPE, then the modules and corresponding arguments are 

loaded to the current file. 

2a. There are too many modules in the library. It is hard to find the right one. 

1. Divide the modules into category according to the functionality. 

2b. The user doesn’t find a proper module. He wants to make a new module himself. 

1. The system supplies a module editor in which creating a new module or changing an 

existed module should be easy. 

2. The new module should be loaded into the module library without restarting the 

system. 

- 9 -

3a. If the content or the format of a module is not recognizable by the system, this module 

cannot be put on the canvas. 

1. The user changes the contents of the module by module editor or by other editors and 

save the change. 

2. This time the user can put the module onto the canvas without restarting the system. 

3b. The user puts the module to a place where a module exists. 

1. The system adjusts the position automatically or doesn’t allow this operation. 

3c. The user finds out that the module on the canvas is not the right one, he or she should be 

able to delete it. Or the user wants to copy the existed module. 

1. The basic edit functionality like copy, cut, move and delete is necessary. 

4a. There are a lot of parameters in one module. Only a few are useful in general situation. 

1. Be able to show the most common used parameters in general. 

2. Show all the parameters if the user wants to. 

3. Set default values to some parameters. 

4b. The user wants to know clearly about the contents of this module 

1. Be able to show the source code of the module. 

4c. The user inputs the wrong parameters. 

1. Check the valid type of the parameter. 

2. Check the valid range of the parameter. 

6a. The user runs the program with some necessary parameters missing. 

1. Check the parameters in each module. If some parameters are missing, stop running 

and remind the users to set these parameters. 

6b. The source code of the module is not correct. 

1. Show the error message 

8a. User doesn’t choose any parameters before exporting. 

1. Only Tcl scripts are generated without an interface. 

2.2.3 Functionality list 

Figure 2-1 The use case model 

According to the features of the Culgi GPE specified in the use case model, a particular functional 

requirement list is shown in Table 2-2. 

Table 2-2 A functionality list of the Culgi GPE 

No Requirement Description 

Req01 Module Category -Divided modules into categories. 

Req02 Load the Module -Load the Module Library into the interface. 

Library 

-Show the name of the module and the category this module 

belongs to. 

Req03 Module Editor -Supply a GUI of Module Editor. 

-Be able to show an existing module in this GUI. 

- 10 -

Req04 Select a module in 

the library 

-User can just type in or change some the necessary properties of 

the new module like parameters and source code of the module. 

-To help the users when typing in the source code, some basic 

functionality of text editor are supplied, like syntax highlighting. 

-Get the name and the category of the selected module. 

Req05 Create an instance of -Create an instance of the module according to the name and 

module 

category of this module. 

-Draw the icon of the module in the canvas. 

Req06 Interaction between -Receive the commands from users 

module and users -Show the parameters to the users according to desired 

information level. 

-Receive the arguments typed by users. 

-Check whether the value of a parameter is valid. 

- Check the type 

- Check the range of the parameter 

Req07 Specify the 

-Be able to specify which module should be run before other 

relationship between 

modules 

modules. 

Req08 Run the program -Be able to run Tcl scripts because the source code of modules is 

written in Tcl. 

-Run the module in the right order. 

Req09 Generate the Tcl -Generate the correct Tcl Scripts which can run without The Culgi 

Scripts 

GPE. 

-Allow the users to choose the parameters that will be shown in 

the End User GUI. 

-Be able to change the name of the parameters. 

2.2.4 Nonfunctional requirements 

Ease of Use: Almost from the beginning to the end of the requirement analysis, we mainly focus on 

ease of use. But it is hard to define what ease of use is. A non-programmer would like an interface in 

which he can program just by clicking, dragging and typing some simple parameters; a user who does 

not know Culgi would expect an interface which can show him the basic functions of Culgi and the 

basic steps to make a simulation program; while a user who has some programming background and is 

familiar with Culgi would like to have more flexibility in programming. So ease of use has different 

meanings in various situations. To maintain a wide range of users, we need to provide multi views on 

programming to show different information in different situation. 

Extensible: Culgi Library is still in development. Changing in the internal structure or adding more 

functionality is still possible in the Culgi Library. Thus the Culgi GPE should keep independent from 

the Culgi Library. 

- 11 -

This chapter mainly analyzes the functional and non-functional requirements of the Culgi GPE. It 

specified the overall requirements on the software interface, the running platform and so on. It also 

analyzes the particular functional requirements by a use case model. This prototype should be designed 

and implemented to satisfy these requirements. The next chapter explains the design models of the 

Culgi GPE. 

- 12 -

Chapter 3 Design Models 

In chapter 2, the requirements of the Culgi GPE were analyzed. These requirements are based on the 

initial demands from the customers. To realize these requirements and keep a wide range of users, three 

models were proposed and were partly implemented. They are the Network Editor, the Sequence Editor 

and the Concept Editor. The Concept Editor is designed for novices of Culgi, and the Sequence Editor 

is designed for the skilled users. The Network Editor is initially designed for the skilled users, but it is 

not a good solution to the Culgi GPE because it is not suitable to the features of the Culgi Library very 

well. 

This chapter presents a description of each model about the process of users building their simulation 

program in the system. It also particularly describes the design on modules. The details of 

implementation are in Chapter 4. 

3.1 The Network Editor 

3.1.1 Description 

The Network Editors (Dataflow editors) nowadays are popular in data analysis, data visualization, 

image processing, and molecular simulation. The Network Editors consist of a set of small to medium 

sized software components (it is also called ‘module’ in Chapter 2) that encapsulate different 

functionalities. These components can be connected to each other to build a dataflow network. “The 

application built by this kind of editor is actually a network of components that exchange data via a set 

of self-defined inputs and outputs.”[2] 

Open DX, AVS/Express, DeViDE[5] are examples of data flow editors. Moreover, network editors also 

exist in the field of Molecular simulation. ViPEr[6] of molecular Graphics Laboratory in Scripps 

Research Institute of California and Pipeline Pilot[3] from the company Scitegic are examples. 

3.1.2 Application to Culgi Library 

However, applying the Network Editor Model to Culgi Library is not straightforward. As mentioned in 

Chapter 2, Culgi keeps the large amount of data as “global” and most of the Culgi commands do not 

have return values. Thus the process of building a Culgi simulation program is just searching the right 

commands and setting the parameters. These features are inconsistent with the concepts of Network 

Editors. So it is impossible to apply the Network Editor concept to the Culgi Library directly. 

But perhaps we can change the network editor a little. We know that another important feature of the 

- 13 -

Culgi commands is that some commands use the same arguments as we mentioned in Chapter 2. For 

example, the command CreateDPDMolecule takes the name of the module as a parameter. Then some 

other commands, like AddMoleculesViewable, may refer to this parameter in order to get the instance of 

the molecules. Thus, instead of passing data from one module to another module, we can pass 

parameters from one module to other modules. So this would be a parameter-passing network, not a 

dataflow network. 

The practice showed that this model is feasible. The picture (a) in Figure 3-1 shows a network as the 

result of this model applied to Culgi Commands. Picture (b) shows the result of running. In this 

example, two kinds of molecules are created, and then are added to the box, which is a cubic space for 

simulation. Finally, the output of the module Box is input to the module Viewer. Viewer will create a 

window and show these molecules and the border of the box. 

(a) 

(b) 

Figure 3-1 Result of Culgi GPE Network Editor 

(This result was generated in 1 st , march 2005, beginning in the implementation phase.) 

But this model has a serious drawback. The picture (c) is also a program made in the Culgi GPE 

Network Editor. And the functionality of this application is the same as the program in picture (a). It 

- 14 - 

(c)

also generates the same result as (a). The only difference is that the content of modules in (c) is 

different from the ones in (b). But in the case of (b), it is difficult to understand what this application 

does and what the running order is. 

Thus, if the network model is applied, the content of modules must be designed very carefully. A 

module writer must think carefully about what will be the input, what will be the output, and what is 

the role of this module in the whole application and so on. 

3.1.3 Evaluation 

Although the Network Editors have been frequently used, it does not suit to the Culgi situation, because 

there is no data flow in the Cuigi library. The main draw backs are listed below. 

1) Instead of data, parameters are exchanged between modules. This is inconsistent with the original 

idea of Network Editors. Thus it is difficult to understand what the program means. 

2) The running order is not easy to define. Some modules do not need to refer to some parameters 

defined by other modules. Thus there will be some isolated modules on the canvas. There will be 

confusion about which one should be run first and what is the relationship between these isolated 

modules and the network. 

3) Some limitations exist when a new module is made. The module authors should consider carefully 

about the input parameters and output of a module. In the case that the input parameters do not need to 

refer to the output of another module and the output of this module is not referred to by other modules, 

this module will be isolated in the network. It reduces the flexibility when the Culgi users making the 

new modules they like. 

3.2 The Sequence Editor 


Similar to the Network Editor, the Sequence Editor also takes modules as the primitive building blocks. 

In contrast to the Network Editor, in this model there are no connections between modules. Thus, the 

program cannot be presented as a dataflow chart anymore. Instead, it will be presented as a sequence. 

The running order of modules on the canvas is just from the beginning of the sequence to the end. 

In this model, the canvas will be divided into rows by drawing a number of lines. Users can place no 

more than one module instance in one row. As a result, users can only build an application which looks 

like a sequence. Then, when running the application, the modules in this application will be executed 

one by one from the module that lies in the top in the sequence to one that lies in the bottom. 

- 15 -

3.2.2 Application to the Culgi Library 

Picture F3-2 shows an application built in the Sequence Model. This application creates two 

DPDMolecules, and places them in the box randomly. Then it creates a window and makes all the 

molecules and box viewable in the window. 

From the requirements analysis, we know that some control structures like if-else or switch are not 

necessary in Culgi simulation programs. Only a loop structure in which users can specify the loop 

times are needed. So this model will also supply two special control modules, named as “LoopStart” 

and “LoopEnd”. In “LoopStart”, users can set loop to be executed N times. And “loopEnd” is just a 

sign which tells the system that this is the end position in this loop. Then the system knows that the 

modules between “loopStart” and “loopEnd” should be run N times. 


Running 

(a) (b) 

Figure 3-2 Result of Culgi GPE Sequence Editor 

Compared to the Network Editor, the Sequence Editor is much more suitable to the Culgi Library. It is 

much more flexible than network model when a new module is built. This is convenient for users or 

customers to create their own modules as they want. This model is very simple so it is clear and easy to 

understand. 

But to build a program in the Sequence Editor, users have to know the basic pipeline of Culgi 

Simulation programs. This general pipeline is explained in Chapter 2. Because this model does not 

show the pipeline, users need to learn the general steps of the simulation programs. 

- 16 -

3.3 The Concept Editor 


The Concept Editor will guide the users in “concept” level to do programming. “Concept” here refers 

to the architecture of a program. In general, architecture of a program means the components of this 

program and the interaction among these components. The concept editor will show the predefined 

architecture of a program to users and guide the user to fill some necessary components in a proper 

position. 

This 

model is not suited to a general purpose programming environment. Because the system can not 

predict the architecture of a program a user wants to build. But the Culgi GPE is designed for the users 

to make simulation program with the Culgi Library. As we mentioned in Chapter 2, the Culgi 

simulation program in general contains three steps: 1) create molecules, 2) create windows to show the 

molecules, 3) set the properties of molecules and start the simulation. And for each step, there are 

several modules which appear in almost all the simulation programs (we call these modules as the 

“necessary modules” in this step). So it is possible to integrate the architectures of the Culgi simulation 

programs into the system. Because the three components in this architecture are linear sequence, we 

will call it the pipeline of a program. 

3.3.2 Application to the Culgi Library 

Simulation programs which are composed of Culgi Commands can be divided into several types, such 

as “DPD Simulation”, “MesoDyn Simulation”, “MD Simulation” and “Hybrid Simulation”. Although 

the simulation programs of Culgi have common architectures, differences still exist among various 

kinds of simulation programs. For example, the architecture of “DPD simulation” programs is different 

from the one “Mesodyn simulation” programs. The difference is that in each step of those three, the 

“necessary modules” are different. So to integrate a general architecture is not a good solution. 

Instead, 

we can make the special structure to each kind of simulation programs as a template. Take 

“DPD Simulation” as an example, the program doing DPD simulation includes three parts; they are 1) 

‘Build Box’ (Create a cube space for simulation, and add molecules into this box), 2) ‘Set Viewer’ (set 

the properties of the graphics window, and add the modules the users want to see in the window), and 3) 

‘DPD simulation’(set the simulation properties including the properties of molecules and the properties 

of the simulation process ). In each of these three parts, there must be some modules which are needed 

in every DPD simulation program. So the template of “DPD Simulation” programs will show the three 

parts to the users and integrate the necessary modules in these three parts by default. 

To 

show the template and to integrate the necessary modules in each component of the template are two 

- 17 -

asic purposes of the concept model. The realization of this model could be described in the following 

steps. 

1) Show the key components in the template to the users when they just initialize the file. As shown 

in Figure 3-3(a), a structure of DPD simulation is present. The three key steps are “Box”, 

“Viewer”, and “Simulation”. 

2) If the step block is opened, for 

example, Box, we will see two layers of areas contained in this 

block. The gray layer is for the default modules. As shown in Figure 3-3 (b), a default module 

named ‘box’ is shown. So a cubic space is created by the system. 

3) Users can put the modules to the area for the new modules. In this 

instance, only modules which 

can create molecules are needed here. So only these modules are allowed to this area. Figure 3-3 

(c) show a module is created in the blue layer. One hand, when a user opens this step block, the 

system will only show the proper modules to this step. On the other hand, in case users get a 

wrong module for some reasons, this wrong module will not be accept by the system. 

4) By adding new modules at each step, the program is finished. Figure 3-3 (d) shows the 

result 

expected. 


The advantage of the concept model is that it makes the programming work much easier than both 

network model and the sequence model especially for novices. This is represented in two points. 

1) A novice does not know the general structure of a Culgi simulation program. To develop a program 

with the Culgi Library in the Culgi GPE or not, he has to learn the necessary steps of a program 

first. The concept model will show a predefined structure of a simulation program. Thus the novice 

knows what the necessary components are. 

2) The necessary modules are integrated in the component 

itself. So it improves the efficiency of 

programming. 

3) The logic errors made 

by users are reduced as the logic is built into the system. 

However 

since the structure for a certain type of simulation programs are integrated into the system, 

this system is not flexible enough to build various simulation programs. For example, in general, users 

want to see the simulation process, so they need to create a window to display the simulation process. 

But in the case that a user does not want to see the simulation process, there is no need to create a 

window. In this case, the original template is not suitable. The solution is that we make it possible for 

users to create new templates. 

- 18 -

(a) 

Step1 Build 

Box 

Step2 Create 

Viewer 

Step3 DPD 

Simulation 

A New Module 

Create By users 

(c) (d) 

Figure 3-3 Concept Editor Model of the Culgi GPE 

- 19 - 

Default 

Modules 

Canvas for 

new modules 

(b)

3.4 Possible solutions and transforms 

In the previous sections, three programming models are suggested. In summary, because there is no 

pipeline in the Culgi Library, the network model is not a good solution to the Culgi library. Compared 

to the Network Editor, the Sequence Editor is much more suitable to the features of the Culgi Library. 

So the sequence model could be a solution of the Culgi GPE. But for the novices who don’t know the 

general architecture of the simulation programs of Culgi, programming in the sequence editor is not 

very easy. They have to spend several hours to learn the structures the simulation programs. Thus, a 

concept model is designed to the novices. The Concept Editor is easy to learn for novices. But it cannot 

replace the Sequence Editor since the Sequence Editor is much more flexible than it and suitable to the 

skilled users. 

Since the Sequence Editor and the Concept Editor have their own advantages, and suit to different 

kinds of users, the solution to the Culgi GPE could be the combination of these two models. The 

novices of Culgi can program in the concept model. And the skilled users of Culgi can choose the 

sequence model to make programs which is out of the scope of the templates in concept model. 

One problem is here that since two models are supported at the same time, what the relationship 

between them is. One option is that these two models are separated. If a user’s application is edited in 

one model, it cannot be edited in the other model. In this option, the two models do not have any 

relationship with each other. The whole system does not look like one but two different systems. There 

must be even one file format for each model to save the user’s program. 

Another option is that these two models can be transformed into each other. In this option, a program 

edited in a model can also be transformed to other model and then edited there. If so, a user can have 

two views of an application. The concept model will show him the view at the architecture level, while 

the sequence model can show him the view at the detailed level. And the whole system just has one 

general format to save the user’s application. Thus, it would be the solution to this problem that to 

make transforms between these two models. 

3.5 Modules 

Modules are primitive components of the simulation programs in the Culgi GPE. All of the three 

models mentioned in the previous sections are based on modules. From the requirements list of Chapter 

2, we can see that in the Culgi GPE a module should have three properties: 1) the contents of a module 

should be several lines of Tcl code; 2) a module should have a visual interface so that users can 

manipulate it; 3) A module should have some arguments which will be passed to the Tcl code of this 

module. So in the user interface of a module, it should also be possible to show the parameters and 

receive the input values from users. The design of a module should satisfy these basic requirements. 

- 20 -

3.5.1 Multi view of modules 

In the general dataflow editors, the interface of a module has two information detail levels. One is an 

icon with the name of this module. And the other one is a separate window or an icon expanded from 

the original one with several widgets to show the parameters of this module. In general, the second 

level appears when the users want to input the parameters of a module. This design can satisfy the basic 

requirements. 

As described in Chapter 2, multi views in programming should be provided in this system in order to 

satisfy a wide range of users. In our design, we have four information detail level views. Their 

functions of these four views are explained below. 

- View 1 is an icon with the name of a module; 

- View 2 is an expanded icon showing the name and the most frequently used parameters; 

- View 3 is an expanded icon showing the name and all the parameters; 

- View 4 is an also an expanded icon showing the name, the parameters, and the source codes this 

module. 

View 2 and View4 are new in our design. Figure 3-4 shows an example of these four information detail 

level views. View 2 is designed because some parameters in a module are not frequently used. There is 

no need to show them every time users input the parameters. The advantage to have View 2 is that it 

saves users’ time in searching the parameters, since the most frequently used parameters are shown in a 

shorter list compared to a complete parameter list. For the novices, a shorter list is easier to learn and 

manipulate. View 4 is designed to show the whole information of the module. It helps the users who 

know programming to understand more on the functionality of this module. And it shows a good 

example for the users who want to create new modules. 

- 21 -

(a) View 1 

(b) View 2 

(c) View 3 

(d) View 4 

Figure 3-4 Four information detail level views of a module 

- 22 -

3.5.2 Various widgets to display a module’s parameters 

In the design of the Culgi GPE, we use different types of widgets to display different parameters in a 

module. The purpose is to reduce the user’s errors. This design is explained in three aspects. 

. 

1) Using different widgets for different parameter types. 

The widget type used for a parameter is determined by the data type of this parameter. There are three 

advantages. First, the widget type of a parameter could hint the users what kind of value is expected in 

this parameter. So the users’ understanding could be increased. Second, each widget type can have its 

own bound checking function. When users make errors when typing, the system will warn the users by 

showing the background in different color (pink in this prototype) or by some sound. This could reduce 

some errors such as the value is out of range or the value is not of the expected type. Third, some 

widget type itself can reduce typos. For example, the widget combobox generally used in single 

selection is used when the data type of the parameter is “enum”. So the users can choose one valid 

selection by clicking instead of typing in. 

2) Use selection other than typing in some cases 

One feature of the Culgi commands is that some commands take the same arguments, as pointed out as 

one feature of the Culgi library in Chapter 2. So it is possible that the value of a parameter in a module 

refers to the value of a parameter in another module. It will be handy if users can select the value of this 

parameter instead of typing in (because the value has been defined in another module). Selection can 

not only reduce typing errors, but also hint the users that what should the value be in this parameter. 

Figure 3-5 shows two types of selection. As shown in Figure 3-5 (a), the value of parameter 

DPDMolecules in module AddDPDMoleculesViewable, determines which molecules will be shown on 

the screen. It needs the values from Parameter Name of CreateDPDMolecules. Users can choose one, 

both or none of these two types of molecules to be visible. So the system just supplies checkbox for 

multi selection widget. But Figure 3-5 (b) is a different case. It is a single selection Case. That is to say, 

users can and only can select one. So the system just supplies a widget for single selection. 

3) keep consistent automatically 

Suppose, in the case of Figure 3-5 a user selected box1 first. Then the user changed the value ‘box1’ 

into another value like ‘box3’ in module ‘Box’. If the user forget to change the corresponding value in 

Module CreateDPDMolecules, an error would happened when the program starts running. 

Thus the system should keep the name consistent automatically. That is to say, the system will make 

sure that if the definition is changed, the reference will also be changed. This mechanism is hidden for 

users. 

- 23 -

(a) (b) 

Figure 3-5 Examples of selection 

3.6 Export resulting applications with GUIs 

An application generated with the Culgi GPE is a Tcl file of the program made by a user and an End 

User GUI. As described in Chapter 1, to export end user applications is one of the general requirements 

to the Culgi GPE. The end user application is used by end users. By inserting the value to some 

parameters as shown in the GUI, and then starting the simulation, the end users can get a simulation 

result for those values. To export a Tcl source code file from a user’s program is not difficult. The main 

problem is how to create an end user application with a GUI. 

In the literature study, two ways are suggested to deal with this problem. One is to integrate an interface 

builder into the Culgi GPE, so the application authors can make the layout of a GUI themselves. The 

other one is to create the end user GUI automatically by the system. Since the application authors are 

non-programmers and the GUI layout is not a very big issue for the end users, the second solution is 

chosen as a conclusion in the literature study. In the following paragraph, we will introduce the design 

of an automatic GUI creation mechanism. 

1) Several templates of the layout of GUI are provided. So the users (application authors) can choose 

the one they like. In each template, a button “Run” must be placed. 

2) A Checkbox is placed in front of each parameter of each module in a users program, If a checkbox 

is checked, the corresponding parameter will appear in the end user GUI. 

3) The source code of each module in a user’s program will be exported, and organized to execute in 

- 24 -

a correct order. These source codes are associated with the “Run” button. So if the button “Run” is 

clicked, the simulation process is started. 

For the users, the process of export of an application is also very easy. First, one just checks the 

parameters which he or she wants to display in the End User GUI, as can be seen in Figure 3-6(a). 

Second, one just click ‘Export’ in menu File. Then the system should ask the user to choose one of the 

templates, as well as the directory one wants to export. Then an end application with a GUI is 

generated (see Figure 3-6(b)). 

3.7 Conclusion 

(a) 

(b) 

Figure 3-6 End User GUIs 

This chapter mainly explains the design of the Culgi GPE. It introduces three programming models, 

which are the network model, the sequence model and the concept model. These models are about how 

a program can be built. For each model, we described how the model works, explains the way of 

application to Culgi, and evaluates the advantages and disadvantages. Because the network model is 

not suitable to the Culgi library, it is not selected as a solution. And the sequence model and the concept 

- 25 -

model suit to skilled users and novices separately, the combination of these two models is selected as 

the solution of the Culgi GPE. 

Then in section 3.5, we mainly introduced the design on modules. In design of the interface of the 

module, we use four information detail level views to show a module while the general data flow 

editors have two. The new ones we designed mainly help users to improve the programming efficiency. 

And then we use different widgets in display the parameters of a module and we also make the system 

to keep consistency of the input. The widgets will help users select or type in right values to a 

parameter. 

The design not only satisfies the functionality list in Chapter 2, but also aims at making the whole 

system easy to learn and easy to use. In the next chapter, some implementation details are presented. 

- 26 -

Chapter 4 Implementation of the Culgi 

GPE 

Chapter 3 suggests three models: the network editor, the sequence editor, and the concept editor. It also 

points out that the combination of sequence editor and concept editor will be the solution of the Culgi 

GPE. This chapter will mainly introduce the implementation of the solution. Although the network 

editor is not a solution to the Culgi GPE, in the prototype we also implemented the prototype to this 

model in the very beginning. This chapter will also introduce this model very shortly. 

This chapter first shows the architecture of the whole system, and then explains each component in this 

architecture. 

4.1 System Overview 

The Culgi GPE will be a part of the Culgi Package. Its main functionality can be described as a bridge 

for users between Culgi Library and Tcl scripts. This section will give an overview of the 

implementation of the prototype. It first introduces the implementation language, and then shows the 

architecture of the whole system. 

Before implementation, several considerations should be kept in mind. These considerations from the 

requirements analysis are 1) the system should be platform independent; 2) external software 

component are the Tcl 8.4 interpreter and Culgi.dll. 

4.1.1 Programming languages 

Python is chosen as the implementation language. Python [7] is an interpreted, interactive, 

object-oriented programming language. It is selected for the following reasons. 

1) As a functional scripts language, Python does not have compile-link cycle. 

2) It is cross platform. 

3) The Python 2.4 core includes Tcl8.4.dll. Thus it is very easy to run Tcl scripts in Python 

environment. 

4) It is possible to load modules dynamically. That is to say, if a module in the module library is 

modified when the system (the Culgi GPE) is running, a user does not need to restart the system to 

accept the changes. 

5) It is very easy to create an interface because Tkinter and Tix are integrated inside. Tkinter and Tix 

can be used to build a graphical interface. 

- 27 -

4.1.2 Architecture 

The whole system consists of four components: the user interface, the kernel, modules, and the module 

library, as shown in Figure F4-1(a). The main functions of each component are explained below. 

• A module is a building block of a program. Each module is declared in a specification file. 

• The module Library is a library that contains all modules’ specification files. 

• The kernel is the core of Culgi GPE. The main tasks of the Culgi GPE are done in the kernel. The 

kernel receives the commands from interface and operates on the modules including create a 

module instance, delete a module instance, run a user’s programs and so on. 

• The user interface is the GUI of the whole system. It shows all the commands, functionalities, the 

useful entities in a visual way for the users. Meanwhile, it waits for the events from users, and then 

responds to the events by passing the corresponding commands to the kernel. 

Users 

The Culgi GPE 

User 

Interface 

Tcl 

Interpreter 

Module 

Library 

Kernel Module 

(a) 

(b) 

Figure 4-1 Diagram of the high-level architecture of the Culgi GPE 

Culgi.D 

LL 

From this architecture, the whole system can be divided into three packages, as can be seen from figure 

F4-1(b).When the whole system is running; the user interface is waiting for actions from the user. If the 

action is a defined event, the user interface will call the corresponding operation. Most operations can 

not be done only at the interface level. The user interface will pass a command to the kernel. The kernel 

has the connection with the Tcl Interpreter, the module as well as the module library. It will pass a 

command to a specific component. 

With this architecture, the whole system can be extended to another library if modules are made on that 

- 28 -

library. Meanwhile, the interface part can be changed without changes in the functions of the kernel and 

the module. That is to say, a whole new interface can be designed for the system freely without the 

consideration on the internal structure of the kernel. The rest of this chapter introduces these four 

components individually. 

4.2 Module 

This section introduces Component Module in the architecture. It first introduces the basic components 

and functions of a module in section 4.2.1. Then it shows the module specification in 4.2.2. 

4.2.1 Module implementation 

A module is a primitive building block, consisting of a user program. It has two main properties. One is 

that the content of this module contains several lines or only one line of Tcl script. This script usually 

needs arguments as input, and returns a value as the output. The other property is that it must have a 

GUI so that users can see the module and can manipulate it. That is to say, this GUI will not only be a 

visible widget but also be able to interact with users. 

To support these two properties, a module should be designed to have four components: input 

parameters, output, the source code container, and the GUI, as shown in Figure 4-2. The input 

parameters record the arguments of the source code in this module; the output records the return value 

after the execution of the source code in this module; the source code container keeps the source code; 

and the GUI is an interface with which users can manipulate this module. Meanwhile operations on 

these parts are also needed for users to control the module, such as setting the values of the parameters 

and executing the source code of this module. 

Input parameters 

Output 

Source Code 

GUI 

A Module 

Figure 4-2 Necessary parts of a module 

Vary in different 

modules 

Same in different 

modules 

In different modules, only the contents of the input parameters, the output and the source code 

container should be different from each other (because the source codes of modules are different); the 

GUIs for each module and the operations on these components should be the same. For example, the 

operation of executing the source code of a module is independent to the content of the source code. 

- 29 -

Thus the Culgi-GPE defined a class named Node as the base class to all the modules. Class Node 

contains those four components as the data members, as well as the functions operating on these 

components. As described in Chapter 3, one important feature of the modules in the Culgi GPE is that 

each module has four information detail level views. This feature is also implemented in this class. The 

functionalities of this class are listed below: 

• Initialize: Set the basic properties of a module, including the name, the descriptions of the inputs 

and outputs and source code 

• Execution of source code: Pass the values of these input parameters to the function, execute this 

function and record the output. 

• Build Icons: Build the icons to a module. The icon is designed as a gray rectangle with the name 

of this module in the center. And some buttons in the left which are used to show the different 

views of this module. 

• Show views: Show the information level view according if a view button is clicked. 

• Receive the input values: Check the validation of the user’s input. It has the functionality of type 

checking and range checking. If the user’s input is not the required type or the value is out of the 

required range, the system will not accept this value and show an error background color of the 

entry widget. And if it is valid, the system will accept this value. 

Each module is a subclass of Class Node. A module class is used to record the unique information in 

this module, such as the name of the module, the input parameters description, the output description 

and the source code. Thus to specify a module is not complicated. In section 4.3.3, module 

specification is explained in detail. 

4.2.2 Define Input and Output 

In addition to the basic functions mentioned in 4.2.1 the modules in the Culgi GPE also have features 

such as the different widgets are assigned to different type of parameters, and the value of the same 

parameter in various modules should be kept consistent. These features are all about the input 

parameters of a module. Thus, the input parameters of a module should be able to satisfy the following 

requirements. 

1. For each parameter, the most basic properties need to be specified. The basic properties include 

‘name’ and ‘value’. 

2. The data type of a parameter is needed, so that the system can show a corresponding widget to the 

parameter with the information on the data type. For example, if the data type of an input 

parameter is “String”, the Entry widget should be given to this parameter. If the data type is 

“Enum”, a ComboBox (a widget kind usually used in the case of single selection) should be given 

to it. The method used to check the validation to the users’ input can be linked to each type of 

widget. 

3. The range of a parameter is also necessary. The system can use information to check whether the 

user’s input value is out of the range. 

4. Information about reference is needed for some parameters. As described in 3.5.2 , the value of a 

parameter in one module may refer to the value of a parameter in another module (See Figure 3-5). 

- 30 -

For example, in Figure 3-5(b), the parameter box (called the reference parameter) of the module 

CreateDPDMolecules (called the reference module) is a reference of the parameter box (called the 

definition parameter) of the module box (called the definition module). In order to make the 

system know the relationship between these two parameters, the information about reference 

which includes the definition module and the definition parameter is needed for the reference 

parameter. 

5. To keep the consistence between the source parameters and the reference parameters, the input 

parameter should also record the information about which source parameter it refers now or which 

reference parameters refers to it. If the value of a source parameter is changed, the system will 

change the value to the reference parameters. 

Class InputParameters is used to define the input parameters. The detailed implementation is shown in 

Table B-7 in Appendix B. 

The definition of a module’s output is much easier. In general, output should refer to the return value of 

a function whose body is the source code of one module. But in Culgi, seldom commands have return 

value. So in fact, the modules of Culgi do not need to have output. However, when we applied the 

Network Editor to the Culgi Library, the output of a module is needed to record some parameters from 

the inputs. These parameters probably will be used by other modules. For an output, the basic 

properties like “name” and “value” are needed. “Data type” is also needed, which is useful in checking 

the validation of connection from one module’s output to another module’s input. 

4.2.3 Module Specification 

Since a node class contains everything a module needs, the module class itself seems to be very easy. 

Figure 4-3 shows an example of a specification of a module written in Python. In this example, we can 

see that only the name, input parameters and source code are needed in this file. (In the network model, 

output description is also useful.) 

Module Name 

Input Parameters 

Tcl source code 

Figure 4-3 An example of a node specification 

- 31 -

A new module can be created by specify a file in the format given in Figure 4-3. The users who are 

familiar with programming would like to create the new modules. But to write a specification file in a 

text editor is inconvenient for users because they have to know the format and then make sure there are 

no typos. In order to make it easy, a Module Editor (a module specification wizard) is developed for the 

users. 

(a) 

(c) 

Figure 4-4 The Module Editor 

- 32 - 

(b)

The 

Module Editor is a tool for creation or modification of a module specification. It provides a GUI to 

the users. This GUI will help the users fill information in right positions and then stores all the 

information in the format of a module specification file. Figure 4-4(a) shows the interface of this 

module editor. This interface contains four parts from the top to the bottom. The first part is used to 

show or fill in the name and the categories of this module. The second part is used to show the input 

parameters. The uses can modify an existing parameter by clicking the parameter. A window including 

the information of this parameter is shown (see Figure 4-4(b)). The users can also add new parameters 

and delete parameters. The third part is used to show the outputs. There is no output in this example. 

The fourth part is used to show and edit the source code. In the left side, there is a tree to show both the 

Tcl keywords and Culgi commands. And the right side is a text editor to edit the source code. This text 

editor imports some components from Python2.3 IDE. So it has the text editor features like coloring the 

keywords and auto indent. Figure 4-4(c) shows an module specification file generated by the Module 

Editor. 

4.3 Module Library 

In Culgi-GPE, all modules’ specifications are stored in a folder named CMLib (Culgi Modules 

Library).In this folder, several subfolders exists. Each subfolder is a category. To tell the system this 

folder is a Culgi category, the folder name will be string “Culgi” plus the category name. For example, 

in CMLib, there is a folder named CulgiPalette, then in the Culgi GPE, there will be a category named 

Palette. Thus, a new category can be added simply by creating a new folder with name “Culgi***”. 

Files 

in the category folder are supposed to be modules. But not all files in the folder are the module 

specification files. For example, in each folder, there will be a file named syslib.def , which records all 

the modules in this folder; it is not a module file. Only a file with a name which begins with “Culgi” 

and ends with “.py” is a module. 

The 

scanning of all modules and all categories are done by the system. That is to say, when a user adds 

a new module file in the subfolders of CMLib, this module will appear in the Culgi GPE dynamically 

without user to restart the whole system. 

4.4 Kernel 

The kernel in fact is a processor between interface and nodes. It receives commands from the Interface 

Part and does some relevant actions and passes the most detailed operation commands to the Module 

Part. The main functionalities are listed below: 

• Initialization: Load Tcl Interpreter and Culgi.dll 

into the system. These external software 

packages are used when executing the user’s program. 

• Scan the Module Library: Scan all subfolders in Folder CMLib, and the files in each subfolder. 

And then record the name of modules in File syslib.def of each subfolder. 

• Create a module instance: Create a module object according to the module name given by the 

- 33 -

users. The creation includes checking the validation of the module specification, initializing the 

parameters of this module and drawing the icons of this module. This creation supports dynamic 

changes. If a module specification is changed or a new module specification is created during the 

run time of the system, the users can see the modification immediately without restarting the whole 

Culgi-GPE system. 

• Delete module: Delete 

a module in all data structures which record some information about this 

module. Destroy this module. 

• Run a user’s program: Run the modules 

one by one in a specified order. 

4.5 The user interface 

Chapter 3 suggests three models, which are the network editor, the sequence editor, and the concept 

editor. It also points out that the combination of sequence editor and concept editor will be the solution 

for the Culgi GPE. Those two models both take modules as the basic building blocks, but different in 

the processes of user programming. This difference lies in the user interface. This section mainly 

introduces the implementation of the user interface part. It particularly describes the implementation on 

the sequence editor and the concept editor. Although the network model is not chosen as the solution, 

its prototype was also implemented in the beginning of this project. So this chapter introduces a little 

on implementation of the network model as well. 

The 

architecture of the user interface consists of two parts. One is the component Culgi-GPE. It mainly 

creates the interface for the whole system. The other one is component Model-Interface, which mainly 

creates the special widgets for different model, and satisfies the particular requirements for different 

model when executing the operations from users. This component has a class InterfaceBase as the base 

class of the three model classes: class SequenceInterface, class NetworkInterface and class 

ConceptInterface. 

The 

separation of the layout and the functions from the interface brings the advantage that a new layout 

can be designed and applied to the system easily. It is also easy to add new models of programming 

without change the layout of the interface. 

The 

function to export the end user applications is also implemented in component “Model-Interface”. 

Since the implementation about the mechanism described in section 3.6 is not difficult, we will not 

explain it in detail. 

In the rest of this section, component Culgi-GPE, SequenceInterface, ConceptInterface and 

Networkinterface are described separately. 

4.5.1 The Component “Culgi-GPE” 

The role of component Culgi GPE is to build a framework of the user interface. This frame work 

includes menus, a widget for showing categories, a widget for showing modules, as well as a canvas. 

Meanwhile, this component also defines the actions of events, and binds these events to the 

- 34 -

corresponding operations. Figure 4-5 is the interface created by this class. 

Menu Bar 

4.5.2 The Sequence View 

Module Category 

Modules Library Canvas 

Figure 4-5 User interface of the Culgi GPE 

Class SequenceInterface is used to implement the sequence model. In the sequence model, the canvas 

is divided into a number of rows, and each row only allows one module instance. This feature brings 

some new requirements to the system: 

1) When a module is expanded or collapsed, 

the height of the row that this module lies in must be 

changed. For example, the appearance of a module is changed from view1 to view2, the height of 

the row should increase at the same time. 

2) When a module is expanded, collapsed, or deleted, the position of the rows below this module 

should be changed as well. 

3) If a user creates a new module 

in the row where another module already exists, the system should 

cancel the creation and inform the user about the rule of the sequence editor. 

- 35 -

4) The row which is focused by the cursor should be highlighted. It is useful when 

a user pastes a 

module, because the highlighted row shows him which row is active now. 

4.5.3 The Concept View 

The basic idea of the concept model of the Culgi GPE is to provide several templates of different kinds 

of simulation programs to users. This prototype implements “DPD simulation” template for the users. 

As described in section 3.3 , a template contains a pipeline for some kind of simulation program. And 

each step in the pipeline integrates the necessary modules, which are the modules that appear in almost 

all the DPD simulation programs. This template shows not only the basic steps on building a simulation 

program to the users, but also the necessary modules in each step. It leaves the space in each step for 

users to fill in the right modules in the right position (see Figure 3-3). 

The 

first problem of implementation is about how to present a step in a pipeline. A new component, 

Macro Node, is designed to present a step. In principle, the Macro Node is a composite module which 

contains several primitive modules. And in the concept module, the Macro Node should support the 

following features. 

• It should contain a list of default primitive modules. The modules in this list are the necessary 

modules of each step. For each Macro Node, this list cannot be changed by users. 

• It should contain a list of user’s modules. The users can add modules and delete modules 

in this 

list. 

• The operations 

like add modules, delete modules should be implemented. 

• At least two views are needed to show a Macro Node. One is just to show the 

name of this module. 

The other can show all modules inside. Particularly, the second view should clearly show which 

modules are default modules, and which modules are user’s modules. Figure 4-6 shows the 

interface of a macro module. 

• In the second view, the borders of the macro module should enlarge or shrink if the appearance of 

primitive modules changes. 

(a) View1 (b) View2 

Figure 4-6 The interface of a macro node 

- 36 -

The second problem is about how to represent a pipeline. In fact the pipeline is just a sequence of 

macro modules. For example, the DPD simulation program of Culgi could be divided into three parts, 

which are ‘build box’, ‘view’, and ‘simulation’. So the DPD template just create three Macro Nodes, 

which are box (corresponding to build box), view, and simulation. 

Class ConceptInterface is used to implement the Concept Model. It has two important data member, 

which are supernodes and runConceptNodes. Member superNodes is a list of Macro nodes. In different 

templates, superNodes should be different. In DPD simulation, Macro nodes are box, view, simulation. 

Member runConceptNodes is a dictionary. The keys of this dictionary are the steps in the pipeline of 

the simulation program. And the value of each key is a list of modules. When the program runs, the 

system will execute the lists of modules according to the order of the keys. But for the modules that 

belong to the same key, the order will be random. For example, if the record in this data member is 

self.runConceptNodes = { 

'1palette':[ node1, ], 

'2createMolecules':[ node3,node2 ], 

'3graphics':[ 

node4], 

'4calculator':[ node5 ], 

'5calculation':[ node8, node6, node7] , 

'6LaunchSimulation':[ node9] , 

} 

The 

order would be “node1, node3, node2, node4, node5, node8, node6, node7, node9”. But the order 

like “node1, node2, node3, node4, node5, node6, node7, node8, node9” is also valid. 

4.5.4 The Network Model 

In the network model, the mechanism of the creation of a connection between two modules is needed. 

This is implemented by a class connection, and class input ports and output ports. Appendix A shows 

the architecture of the implementation 

of the Network Model. Because dataflow editors are quite 

popular nowadays, we will not explain the implementation 

in detail. 

4.5.5 Transformations between 

different models 

Transformation means that an application made in one model is displayed 

correctly in another model. 

And with transformations, users can have different levels of view to an application. 

Table 4-1 2 . The transforms among different models 

From 

To 

Network Model Sequence Model Concept Model 

Network Model -- Yes possible 

Sequence Model possible -- possible 

2 In Table 4-1, “--” means no transforms; “Yes” means this transform has been implemented; and 

“Possible” means this transform is possible to implement, but not implemented yet. 

- 37 -

Concept Model possible Yes -- 

Table 4-1 shows the possibility in technique to implement the transformations among models. It is not 

necessary to implement the transformations from or to the network model, because the network model 

is not a solution to the Culgi GPE now. However, this table includes the network model just to show the 

possibility 

of the technique. 

From Table 4-1, we can see that the transformations 

from 

the network 

model t o sequence model, 

and 

from the Concept Model to sequence model has been implemented. The i mplementation of these 

transformations 

is relatively easy. The modules in one application are always executed one by one no 

matter in which model. So the execution orders of the network model and the concept model can 

be 

used in transformations to the sequence 

model. 

The 

transformation from the sequence model to the network model is possible as well. Although it 

seems 

that there are no relationships between each two modules in the sequence view from the 

appearance, the relationship is kept inside the modules. As described in section 4.2 , some parameters 

of modules keep binding to the reference parameter of another module. So this information can use in 

transformation from the sequence model to the network model. 

The 

most difficult part is the transformation from the sequence model to the concept model. In this 

transformation, the ordered modules have to be intelligently placed inside a template of the concept 

model. The problems here are how to recognize the template to which the module sequence belongs 

and how to describe the transformation from each module to a new location in the template. To solve 

this, there are several approaches to the problems: 

• 

Define an external rule base for regenerating a template. With this rule base, the system can 

analyze a sequence of modules and then judge what kind of simulation this sequence does and 

which template this sequence belongs to. If the module sequence is a valid simulation program, the 

system should be able to choose a template in the concept model for it. While if it is not a valid 

program, the system should be able to warn the user that this simulation program is not valid and 

show the invalid parts in the sequence. The difficulty of this approach is in how to define a 

complete and reasonable rule base. 

• Make the templates in the concept model intelligent to put each module of the sequence in the 

correct location. It means that the templates know which module in the sequence should belong to 

which step in this template and the relations of this module with other modules. This approach is 

useful when the system knows which template the 

module sequence belongs to. 

• Make modules themselves aware of their location and ordering in the template structure. For 

example, the module AddDPDMolecules should belong to the template step of Create Molecules 

(the first step described in the general structure in Chapter 2), so this module should contain the 

information about this step. But because one module is possible to appear in different templates or 

in different steps in one template, the external rule base is still needed to analyze the whole module 

- 38 -

sequence. 

From these approaches, we can see that the implementation of the transformation from the sequence 

mod el to the concept model is only possible with a substantial change to the concept – both a rule base 

for 

regenerating the template and explicit template. 

The transformations between the network model and the concept model are also possible. Since all of 

them can transform to or from the sequence model, at least the sequence model can become the bridge. 

But in fact, the one from the concept model to the network model directly is also possible, 

because in 

the 

concept model the modules also keep the information on the relationships to other modules. 

In summary, 

this chapter mainly introduced the implementation of the Culgi GPE. It described the 

architecture 

of the whole system first. This architecture consists of four components: the modules, the 

module 

library, the kernel, and the user interface. Then it introduced the design and the functions of 

each component. It particularly described deign of modules, the sequence model and the concept 

module. Finally, it 

analyzed the possibility of transformation among different models. 

- 39 -

- 40 -

Chapter 5 Results and Test 

The previous two chapters introduced the design and the implementation to the Culgi GPE. This 

chapter will show the results of this project. This chapter consists of two parts. First, it shows the 

prototype of Culgi GPE as it is used for a practical application. It explains how to start the system, how 

to build the application, and how to run the application and then how to export an End User application 

with a GUI. And the other part is a short test report that includes the feedbacks from users. 

5.1 Result 

5.1.1 Interface 

By double-clicking Culgi-GPE.py, we can start the Culgi GPE prototype system. The interface of this 

prototype will appear in the screen, as shown in Figure F5-1. The system will open in the default 

working mode, the Sequence Editor. 

As can been seen from Figure 5-1, this interface consists of four parts, Menu Bar, Module Category, 

Module Library and Canvas. The explanation of these parts is listed below. 

Menu Bar: Menu Bar contains the operations commands like new, save, open, copy, run and so on. 

These commands are divided into 5 categories. They are File, Edit, Library, View, Run and Help. 

Among these categories, View is used to change the working mode. For example, if you click on the 

item “Sequence View” in category View, the current work mode will be changed into the Sequence 

View. 

Module Category: Modules of the Culgi GPE are divided into categories. If you click one category, 

the corresponding modules are shown in the Modules Library. If you click All, all modules are listed in 

the modules Library. The default category is ALL. That is to say, in initialization, all the modules are 

loaded in the Module Library. 

Module library: Modules are shown in module library. If you click one of them, a module is selected. 

Canvas: The canvas is used to build the program. Figure 5-1 showed the canvas of the Sequence View. 

- 41 -

Menu Bar 

Module Library 

5.1.2 Module 

1) Create a module instance in Canvas 

Module Categories 

Figure 5-1 Initial interface 

Canvas 

Step 1: In the module categories, click one category you are interested in. Then you will see the 

modules in this category being shown in the module library. 

Step 2: In the module library, click the module you are interested in. Then this module is selected. 

Step 3: Click on the canvas where you want to put the module. (See Figure 5-2, and Figure 5-3). 

- 42 -

(a) Before click. (b) After an item in category list is clicked 

Figure 5-2 Step 1 in create a module 

Step 2) click a module 

Figure 5-3 Step 2 and Step 3 in create a module instance 

Click an item 

Step 3) click on canvas 

A new module instance is 

created 

There 

are several buttons on the left side of a module interface. Figure 5-4 shows the names of these 

buttons. If a button is clicked, the system will show an information level view of a module. More 

information on the information level views is given in chapter 3. For example, if button “Show View1” 

is clicked, View1 will be shown (see Figure 3-4). The zoomIn button will show a higher information 

level than the current one, while the zoomOut button will show a lower information level. 

- 43 -

Zoom In Zoom Out 

Show View1 

Show View2 

Show View3 

Show View4 Module Name 

5.1.3 Build a program 

Figure 5-4 Instruction of Module Interface 

The previous section shows how to create a module in the sequence view. A simulation application can 

be built by creating a sequence of modules. Figure 5-5 shows an example of “Hybrid simulation” built 

in the sequence model. In this example three kinds of molecules are created: “water”, “oil” and 

“surfactant”. Among these molecules, “oil” molecules are concentrated in a sphere. (It is a drop of oil). 

The red area in Figure 5-5(b) refers to this oil droplet. “Water” molecules are distributing in the other 

area out of the oil drop. And then 100 surfactant molecules are added to this environment (see the white 

and blue molecules in Figure 5-5(b)). Then the properties of each kind of molecule and the 

relationships among these molecules are specified. The properties about this environment such as the 

temperature are set as well. At the end, the parameter simulationstep is set. 

Figure 

5-5(a) shows a part of this application. Clicking the “run” item in the menu, the program will be 

executed. Figure 5-5(b) shows the initial state of the simulation. Figure 5-5(c) is a visual display 

generated during of the simulation. And Figure 5-5(d) is the end result of the simulation. As can be seen 

from these images, the surfactants first distribute randomly in the whole area. Then they move to the oil 

gradually, and finally all of them surround the oil droplet. 

In the concept model, the creation of an instance of a module is almost the same as in the sequence 

model. The only difference is that only some kinds of modules are allowed to a certain area. For 

example, if the space is used to place the modules from SetViewer, the modules which are not belong to 

this category like DPDCalculator cannot be put in this space. 

Figure 

5-6 and Figure 5-7 show a DPD simulation program built in the concept model. First, when a 

DPD template is initialized, the system will show the general steps as can be seen in Figure 5-6(a). 

Then the first step “box1”(shown in Figure 5-6(b)), two instances of module createDPDMolecules are 

created. These two modules are used to add two molecules, Water and Oil. In the second step 

View1( Figure 5-7(a)), an instance of module AddDPDMoleucleViewable is created. In this module, 

only molecules Oil are chosen. So in the simulation window, only modules Oil will be displayed. Then, 

in the third step, Simulation1 (Figure 5-7(b)), an instance of the module Setbeadsinteractions and an 

- 44 -

instance of the module setDPDEnvironment is created to set some properties for simulation. Figure 

5-7(c) and Figure 5-7(d) show the simulation process. We can see that the molecules Oil will 

concentrate. 

(a) A user’s program in Sequence Model 

(b) Start simulation (c) One step in simulation (d) End of simulation 

Figure 5-5 An example of “Hybrid Simulation” in Sequence Model 

- 45 -

(a) Pipeline view of a DPD simulation program 

(b) Add two DPD Molecules into a box: “water”, “Oil” 

Figure 5-6 an example of “DPD simulation” in concept model -1 

- 46 -

(a) Make only “Oil” visible 

(b) Set simulation parameters 

Figure 5-7 an example of “DPD simulation” in concept model -2 

- 47 - 

(c) Start of the simulation 

(d) Step #100 in the simulation

5.1.4 Export an end user application 

Chapter 3 has already introduced how to export an end user application and showed a picture. So 

this chapter will not repeat this part. 

5.2 Test and Feedback 

A rapid prototyping approach is taken in the whole developing process. The first version of the 

prototype had been developed in about a month. In that version the sequence model and the network 

model are implemented. Then in the following several months, the prototype is continually improved 

by showing it to customers, analyzing customers’ feedbacks, and developing. Finally this prototype is 

given to 6 users to do testing. The features of these 6 people and the tasks are shown in Table 5-1. 

Table 5-1 Testing 

Test Job Familiar Familiar Type Tasks Working 

subjects 

with the with the 

platform 

Culgi Culgi 

Library? GPE? 

A PhD student in No No novice DPD Windows 

Mathematics 

Simulation XP 

B Post Doc in No No novice DPD Windows 

Computational 

chemist. 

Simulation XP 

C A student in No No novice DPD Windows 

Chemistry 

Simulation XP and 

and Hybrid Windows 

Simulation NT 

D Post Doc in Yes No novice Hybrid Linux 

Computational 

Simulation And 

chemistry. 

Windows 

XP 

E Post Doc in Yes Yes experienced Not specified Windows 

Computational 

chemist. 

user 

XP 

F The writer of the Yes Yes experienced Not specified Windows 

Culgi Library 

user 

XP 

The test was held for three hours after a short introduction about how to use the Culgi GPE. The test 

subjects worked on their own PC at the same time. After one hour, several of them had finished a DPD 

simulation program. And at the end of the testing, all the subjects who have assignment finished their 

programs. Meanwhile, all the subjects also gave their opinions and feedback. In the rest of this section, 

some important feedback which will affect the next step of work are given out. 

- 48 -

Feedbacks from the novices of Culgi 

1) When the test subjects program in the sequence model for the first time, they don’t know which 

modules are necessary to their task and how the ordering of the modules should be. They want to 

get more help information on the general steps of the simulation program in the sequence model. 

This problem happened because as novices of Culgi, they had no idea about how to build a 

simulation program with Culgi. That’s why the concept model is designed. As described in 

chapter 2, each kind of simulation program of Culgi has its own general structure. To build a valid 

simulation program with the Culgi Library, these structures should be followed. The Concept 

Model is designed to show the pipeline. Another solution to this problem is to add some 

constraints on modules. For example, if Module A has to be before Module B, the module B 

should not be created if module A has not been created yet. But this solution is not applied 

because it is too complicated to enumerate all possibilities of on the constraints on modules. 

2) The test subjects like the concept model because it provides templates to certain kinds of 

programs. In this prototype, the template of “DPD simulation” programs is provided. In future, 

other templates like “Mesodyn simulation” and “Hybrid simulation” should be provided. 

3) About the names of the parameters of a module, the subjects have different opinions. For example, 

the properties to a molecule or a bead. This is because in the different research areas, there are 

various names to one property. This problem could be solved because with the Module Editor, 

users can modify an existing module and save it as a user’s new module. For different users in 

different fields, they can have their own modules. 

4) The subjects also gave out some suggestions in default value of some parameters in the modules. 

For example, a property which describes the interaction between two molecules, named “A”, has 

the default value 25. But the users thought that this default value should change according to the 

type of the modules. For example, this value of between two kinds of molecules should be 80, so 

the default value in this case should be appeared as 80. This requirement cannot be solved in the 

Culgi GPE level, because the Culgi GPE is just an interface on the Culgi Library. All the default 

values to the properties are from the values of the Culgi Library. 

Feedbacks from the skilled users of Culgi 

1) The subjects like that each module has just one line of source code, because they are familiar with 

commands in the Culgi Library. The advantage is that modules with one line of code can bring 

them the same flexibility as in the text editor. In addition, compared to the modules with several 

lines of code, modules with one line of code are something they were already familiar with. This 

problem can be easily solved by the Module Editor (See 4.2.3 ). Users can make new modules as 

they like with this tool. 

2) They also like the concept model because it improves the programming efficiency if the template 

of the target program is given. More templates should be provided in the future. 

- 49 -

- 50 -

Chapter 6 Conclusion 

The goal of this project was to design and develop a prototype to the system based on the Culgi Library. 

Because the most Culgi users are non-programmers, this system is intended to help them build 

simulation programs easily and efficiently. Through the user analysis and the requirement analysis, we 

decided that a graphical programming environment (Culgi GPE in short) should be designed. With in 

the Culgi GPE, the users can build simulation programs easily, run the programs to see the simulation 

process and get the simulation result, and also export the Tcl source codes with an end user GUIs. 

In order to make the Culgi GPE suitable for a wide range of users, it is suggested that the system 

should provides multi views of a user’s program for different kinds of users. For the skilled users, the 

Network Editor and the Sequence Editor are suggested. The Network Editor comes from the data flow 

editors like “AVS/Express” or “OpenDX”. But it is not suitable to the Culgi Library because there is no 

data flow in the Culgi Library. In the Sequence Editor, a simulation program is made like a sequence of 

modules. It keeps the advantage from the Network Editor that users can program by clicking, dragging 

and dropping. And it is suitable to the features of the Culgi library. So the Sequence Editor is chosen 

for the skilled users. For novices, the concept editor is designed. The concept editor provides several 

predefined-structures for different kinds of simulation programs of Culgi. So novices can do 

programming in this model easily. 

In addition to these programming models, this prototype focuses on the interaction between a 

programming element and users. The prototype supplies four level views of information to each 

module, which makes users possible to get different kinds of information in different situation. 

Meanwhile, the prototype uses different widgets for different types of parameters to reduce the typos 

and checks the validation of the inputs from users. 

The architecture of this prototype makes the system easily extensible. It can be applied to another 

library if some modules are made on that library. Meanwhile, it supports dynamic changes. If a module 

specification is changed or a new module specification is created, the users can see the modification 

immediately without restarting the Culgi-GPE system. 

To make the current prototype become the first release of the Culgi GPE, some improvements should 

be done. More templates in the concept model are needed; more modules should be made, and the 

transform from the sequence model to the concept model should be implemented. In addition to these 

improvements, the Culgi GPE can be developed in the future in the following directions. 

Design and Develop a Shared Module Library in the internet. It is used to maintain and extend the 

Culgi Library. All the Culgi developers and the users can share this library. The developers of 

Culgi can continually add new modules to this library, whenever they developed new commands 

in the Culgi library. Users can also upload their own modules to this Shard Module Library. This 

library should divide the modules in the different versions of the Culgi Library, and check the 

- 51 -

validity of each module uploaded as well. 

Add a debug tool to the Culgi GPE. At this moment, if errors exist in a user’s program, it can only 

be found when the program is running. The errors will be complained about by the Tcl interpreter. 

The debug tool will check the validation of a user’s program before it is running. It will check not 

only the validation of the input parameters, but also the logic of a user’s program. 

Make the Sequence Editor intelligent. It means to develop a mechanism to predict the users’ 

intention and give out several suggestions to users about the next step. For example, if a module 

“A” is created by a user, the system will guess the types of simulation programs the user wants to 

build. If the system predicts that this user will do simulation programs in “TypeA” and “TypeB”, 

it will show the user the modules needed in “TypeA” and “TypeB” separately. And if the system 

finds that there is contradiction in the user’s previous work, it will give out warnings and point out 

the contradicting part. 

We can also make this system into a general purpose programming environment that can be 

applied to other libraries very easily. This general purpose programming environment can pack the 

commands of a library into modules automatically. And it also supports if-else, switch, and loop 

structures. If there is a new library, like a library for mathematics, or for physics, this 

programming environment can be applied to it automatically. 

The Culgi GPE will be designed and developed continually after this prototype. We hope that several 

years later, all computational chemists can build simulation programs with this system. 

- 52 -

Chapter 7 Bibliography 

[1] Craig Larman, “Applying UML and Patterns: An Introduction to Object-Oriented Analysis and 

Design and Iterative Development, Third Edition”. Prentice Hall PTR, 2004 

[2] Alexandru C.Telea. Visualisation and Simulation with Object-Oriented Networks. PhD thesis, 

Technische Universiteit Eindhoven, 2000. 

[3] “pipeline pilot, an introduction”, SciTegic, 2003 

http://www.scitegic.com/products_services/pipeline_pilot.htm 

[4] A.V.Kyrylyuk, F.H.Case and J.G.E.M.Fraaije, Property Prediction and Hybrid Modeling for 

Combinatorial Materials, QSAR & Combinatorial Science, Volume 24, Issue 1 , Pages 131 – 137, 

March 2005 

[5] C. P. Botha, “Techniques and Software Architectures for Medical Visualisation and Image 

Processing”, PhD thesis, Delft University of Technology, 2005. 

[6] Michel F. Sanner, Daniel. Stoffler and Arthur J. Olson, ViPEr, a Visual Programming Environment 

for Python. In Proceedings of the 10 th International Python Conference, February 2002. 

[7] Mark Lutz, David Ascher, “Learning Python, Second Edition”, O’REILLY, December 2003 

[8] IEEE Std 830-1998: “IEEE Recommended Practice for Software Requirements Specifications”. 

IEEE. 1998 

[10] J. M. Haile, “Molecular Dynamics Simulation: Elementry Methods”, Wiley-Interscience, March, 

1997 

[11] Molecular Simulations, Inc , “Cerius 2 Property Prediction”, June 2000. 

http://www.scripps.edu/rc/softwaredocs/msi/cerius45/proppred/C2PropPred3.9TOC.doc.html 

[12] Ruixin Wang, “Programming Environments For A Molecular Simulation System”, literature 

research report of the master’s thesis, December, 2004. 

- 53 -

- 54 -

Appendix A. Class Diagrams 

Figure A-1 The over Class Diagram the Culgi GPE 

- 55 -

Figure A-2 Class Diagram of class CulgiGPE and Class interface Base 

Figure A-3 Class Diggram of the Concept Model 

- 56 -

Figure A-4 Class Diagram of “SequenceInterface” 

Figure A-5 Class diagram of the Network Model 

- 57 -

Figure A-6 Class Diagram of Package Kernel 

Figure A-7 Class Diagram of Package Module 

- 58 -

Appendix B. Tables 

Table B-1 Functionalities of Class Culgi GPE 

Functions Functionalities 

BuildInterface build the windows interface of the whole system. 

-create Menus and bind to the event 

-create the widget for showing categories 

-create the widget for showing modules, 

-create the canvas. 

applyKeyBindings Bind general hot keys to the event. General hot keys are defined in a file 

‘FBindings.py’ 

Bindings Bind all the events to the corresponding operations. 

Show Sequence -check if the current view is sequence view. If no, save the current file and 

change the current view into sequence view. 

Show Network -check if the current view is network view. If no, save the current file and 

change the current view into network view. 

Show concept -check if the current view is concept view. If no, save the current file and change 

the current view into concept view. 

__init__ Call function build interface, applyKeyBindings, and bindings. 

Create a default instance of sequenceInterface. 

- 59 -

Table B-2 Functions of Class InterfaceBase 


__init__( ) -Initial the Data Members. 

-Create an instance Kernel 

loadCategory() -Read the folders name in CMLib. 

-Show them in the widget of categories list. 

loadLibrary() -Read the data in file ‘syslib.def’ of the current category. 

-S how them in the widget of modules list. 

scanLibrary() -Call kernel.scanLibrary 

-Call LoadCategory 

-Call LoadLibrary 

findWidget find the ID of the widget that is single clicked. 

singleClick -call findWidget to get the ID of the widget that is single clicked. 

-according to the type of this Widget, call the corresponding functions. For 

example, showView1, showView2, …… 

CreateNode() -Call Kernel.CreateNode() 

DeleteModule() -Call Kernel.DeleteNode() 

showView1() -Call Kernel.showView1() 

showView2() -Call Kernel.showView2() 

showView3 -Call Kernel.showView3() 

showView4 -Call Kernel.showView4() 

zoomIn -Call Kernel.zoomIn() 

zoomOut -Call Kernel.zoomOut() 

Save -save a file 

Open -open a file 

Copy Copy the name of the node and the values of the parameters. 

Paste -paste the node in the given position 

- 60 -

Table B-3 Functionalities of Class ConceptInterface 


__init__( ) -Create three macro nodes, ‘box’, ‘view’, ‘simulation’ 

-Add them to Data Member supperNodes 

LoadCategory -be called when the users open a macro node. 

-load the categories that would be useful in this macro node are loaded 

CreateModule() -Check whether the position is a valid. Because the modules in the concept 

strategy should be placed to the certain area. For example, the modules which 

are needed when building the box can only be able to added to the area belong 

to supper nodes box. 

-Call CreateModule in Supper Class BaseInterface 

-Add this new module to the corresponding supperNode 

-Call macronode.updatePosition 

-Add the module to Data Member runConceptNodes 

DeleteModule() -Call deleteModule in BaseInterface 

-Delete this new module to the corresponding supperNode 

-Add the module to Data Member runConceptNodes 

showView1 -Call showview1 in Supper Class BaseInterface 

-Call macroNode.updatePosition 







zoomIn -Call zoomIn in Supper Class BaseInterface 

-Check the property of current Module. 

-If it is primitive module, call macroNode.updatePosition 

-Else, it should be a macro node. Reload the categories, whose modules should 

be valid in this macroNode. 

zoomOut -Check the property of current Module. 

-If it is primitive module, call macroNode.updatePosition 

Run -Make a list of modules. The order of these modules are is made according to 

the order in runConceptNodes 

destructor -call destructor in Supper Class BaseInterface. 

-return a list of modules with the order in runConceptNodes. 

-This is used when transform from the Concept Editor to the Network Editor 

- 61 -

Table B-4 Functionalities of Class “SequenceInterface” 


__init__( ) Draw lines on the canvas. The space between two lines is a row. The initial 

heights of rows are equal to each other. 

CreateModule() -Calculate the position where a module should stay according to the current 

mouse position. 

-Call CreateModule in Supper Class BaseInterface 

-Change the record in Data Member sequenceEditor. 

DeleteModule() -Call deleteModule in BaseInterface 

-Call adjustAllposition to make the rows have correct height 

-Change the record in Data Member sequenceEditor 









zoomIn -Call zoomIn in Supper Class BaseInterface 


zoomOut -Call zoomOut in Supper Class BaseInterface 

Draw 

HighlightRectangle 


-highlightRectangle is used to show where the user focuses on now. This 

rectangle will occupy the whole the row when this row is clicked. 

adjustAllposition -Because the size of the module API is varied when the module show different 

level information. This is function is to make sure that the modules are not 

overlapped each other, and the rows have right heights. 

Copy -Call copy in Supper Class BaseInterface 

Paste -Call paste in supper Class BaseInterface 


Move -Move the module following the position of mouse. 

-when the mouse is released, check whether is position is allowed or not. 

-if yes, place the module in the new position. 


-adjust Data Member sequenceEditor 

Save -data in sequenceEditor are saved. 

Open -according to the data in the save file, create all modules in the right place 

- 62 -

Table B-5 Functionalities of class Kernel. 


__init__ -Create an instance of TCL interpreter, named it as Root. 

-Load Culgi.DLL to the Tcl interpreter 

-Create a instance of class Manager 

ScanLibrary() -Scan all subfolders in Folder CMLib, and the files in each subfolder. 

-Create or rewrite files which are named “syslib.def” in folder CMLib and all 

subfolders. 

Create Node() -Call buildNode() 

-The File “syslib.def” in CMLib will record all the modules. 

-The “syslib.def” in a subfolder will record all the modules in this category. 

-Call buildNodeIcon() 

buildNode() -Import a module into the Python system according to the name passed from 

interface part. 

-If the module has already in Python system, delete the original one in the 

Python system, and reload again. By doing this, user can reload a module after 

modified this module without restarting the system. 

-Compile the module 

-Create an instance of this module. 

-Kernel will add the instance to the Manager as well. 

buildNodeIcon() -Call node.buildIcon() to create the interface of the node 

DeleteNode() -Delete all the icons of the module instance. 

-Remove it from Manager. 

-Destroy it. 

showView1 -Call node.showView1() 




zoomIn -Call node.zoomIn() 

zoomOut -Call node.zoomOut() 

Run the program -Run the whole user program according to some special order. The order is 

determined according to the different strategy 

- 63 -

Table B-6 Functionalities in class Node 

Functions Functionality 

Initialization -Set the basic properties of a module, including the name, the descriptions of the 

inputs and outputs and source code 

Set Parameters -According to the input descriptions, create Parameters instance. 

Set functions -Check the source code. 

-If no error happens, pack the source code into a function 

Run Node -Read value from each parameter. 

-Check whether each of the parameters have a value. 

Build Icons 

-Pass the values of these parameters to the function, execute this function and 

recode the output. 

-Build the icon of the module. 

Show View1 -Show the interface of a module with only the name of this module. 

Show View2 -Show the parameters used frequently 

Show View3 -Show all the parameters 

Show View4 -Show the source code of this module. 

Show Parameter -This function is called by Show View3 and Show view2. 

-The widget to show this parameter is decided by data type of this parameter. 

- 64 -

Table B-7 Properties of input parameters 

Properties Explanation Valid value Default Empty 

Name The name of this input 

parameter. 

Data type Data type of this 

parameter 

Value Default value of this 

parameter 

Description The explanation about 

this parameter. 

Value scope Define the value scope of 

this parameter 

Reference Define the source* of this 

parameter. 

Reference Define the kinds of source 

type of this parameter. 

Port Define whether this 

parameter is a port or not. 

It is only useful in 

network view. 

Default Define whether the 

parameter have default 

value 

A string started by letter No 

Can be chosen in { string, numeric, 

default 

No no 

integer, real, enum, alphabetic, } default 

The value will be checked according to 

its data type 

“” yes 

Any value “” yes 

This one is only useful when the data 

type is integer or numeric, real 

“” yes 

“module”.”parameter” “” yes 

0 or 1. “0”means that this parameter 

only have one source. 

“1”means that this parameter have 

multi source. 

0 or 1. 

0: it is not a port 

1: it is a port 

0 or 1. 

0: no default value. 

1: has default value 

- 65 - 

no 

0 yes 

0 yes 

1 yes

- 66 -

Appendix C. DPD Simulation 

# DPD Simulation for a system of water-oil-surfactant 

# System does not contain any electrostatics. 

# Get hold of the Culgi Instance 

load CulgiTcl 

set c [Culgi_GetInstance] 

# Get to the palette. Create a Hybrid simulation box 

# as well as, DPD water, oil and surfactant molecules 

set p [$c GetPaletteCmds] 

$p CreateBox MyBox HYBRID 5 5 5 

$p CreateDPDMolecule oil OO 

$p CreateDPDMolecule water W 

# Add desired number of DPD molecules to our Box 

# We are going with a density of 3.0. So we have 

# a total of 625 beads in the system 

$p AddDPDMoleculesToBox MyBox water 501 

$p AddDPDMoleculesToBox MyBox oil 62 

# Adding of the molecules to the box does not build the 

# molecules, since building would require knowledge of parameters 

# like bond lengths, etc. Get hold of the DPD Calculator and use default 

# parameters to build the molecules 

set cal [$c GetDPDCalculatorCmds] 

$cal SetSystem MyBox 

$cal BuildMolecules 

# Alternatively one can also just ask the Box itself to Build the Molecules 

#set param [$c GetParametersCmds] 

#set Box [$p GetHybridBoxCmds MyBox] 

#$Box BuildDPDMolecules $param 

# Now get hold of a Graphics object, and view our Box 

set g [$c GetGraphicsCmds] 

$g SetPosition 50 50 

$g SetSize 600 600 

$g SetCameraAzimuth 20 

$g SetCameraElevation 20 

$g AddViewable MyBox 

$g AddViewable MyBox oil 

- 67 -

$g SetInputText MyBox:oil 

$g Render 

# Meaning of the three add viewable commands above: 

# The first asks to add the Box itself to the graphics 

# The second asks to add the surfactant molecules in the box to be added 

to graphics 

# The second asks to add the oil molecules in the box to be added to graphics 

# If you do not like any of the default bead colors you can change as follows 

# $Box SetBeadColors B Red 

# $g UpdateViewables 

# Assign repulsive Bead-bead interaction parameters 

# If parameters for A-B is defined, B-A is not required 

# as they would be considered same. 

$cal SetA W W 25 

$cal SetA W O 80 

$cal SetA O O 25 

# Alternatively it is also possible to set the interaction 

# parameters through the CulgiBeadParametersCmds 

# Set up the DPD simulation 

$cal SetTimeStep 0.05 

$cal SetTemperature 1.0 

# We want to save Instantaeous system energy during simulation 

# A file named MyBox_Energy.ctf would be generated due to this 

$cal SetEnergySaveFrequency 10 

# We want to add live graphics update during simulation 

$cal AddSystemGraphics $g 

$cal SetGraphicsUpdateFrequency 50 

# We want to save coordinates during simulation for further analysis 

# A file named MyBox.cda would be generated due to this 

$cal SetCoordinateSaveFrequency 50 

# Launch the simulation. Comprehensive Simulation results would be 

# written out in the MyBox.out file 

$cal RunDPD 1000 

set plot [$c GetXYPlotCmds] 

$plot SetPosition 50 50 

- 68 -

$plot SetSize 400 400 

$plot Load MyBox_Energy.ctf 

$plot Render 

- 69 -

Master's Thesis - Computer Graphics and Visualization - TU Delft

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?