- EN
- JP
OCTA was developed in the joint project of industries, government and academia carried out in Japan. The official name of the project is "Research and Development of the Platform for Designing High Functional Material ". The project was proposed by the Ministry of International Trade and Industry in 1997, entrusted to NEDO and conducted at Nagoya University from 1998 to 2002 with 11 industries participating the project.
The purpose of this project is to construct a computer simulation system which bridges the micro structural(or molecular) characteristics of materials with the macroscopic characteristics of the materials. The material we focused on is the soft materials which generically refer to polymers, colloids, surfactants and gels.
Understanding how material properties are related to its micro structures has been a central problem in physics, chemistry and material science. It is also a crucial question in the research and development in industries since the understanding of the macro-micro relationship is the base of the technology to control and improve existing materials and/or to create innovative materials.
Our objective was to build a simulation system which aids this activity. As computer is becoming a useful tool in the design of architecture, machines and electrical devices, we wanted to make a similar simulation tool for material engineering. This idea is not new. The word "Computer Aided Material Engineering" has been used for more than 10 years, and it has seen some successes in some areas. However, in soft materials, the idea is not easy to achieve.
The properties of soft materials, say polymers, are not determined by the constituting monomers only: they depend on many other material characteristics, such as molecular weight, molecular weight distribution, branching structure, degree of chain orientation, degree of crystallization, and the states of the crystal-amorphous interfaces. The situation becomes even more complex in the case of polymer blends or composites where the dispersion state and the interfaces between the component phases change the material property drastically.
Such complex problems cannot be handled by a single simulator. Many length scales are involved and many physics are working in the phenomena. This type of problems is now called multi-scale, multi-physics problem, and how to construct a simulation system to deal with such a problem is now becoming a challenge in computational science and engineering.
Ideally, the tool we would like to have to study such materials is a system by which we can "zoom-in" to the materials at any length scale, and see and test the phenomena occurring in the material by computer simulation. We called such system "seamless zooming"system. This represents the image of the ultimate form of the simulator we are aiming at.
How can we realize such simulator? In academia, there have been several proposals for the multi-scale modeling, which typically uses two or more physical models simultaneously in the simulation. Though attractive they are, we did not pursue such study as the top priority of our project activity. There are two reasons. Firstly, the multi-scale modeling is a highly exploratory research theme, and too risky for the project of our size. Secondly, the current multi-scale modeling requires us to select a specific problem for a specific system. This was not possible in our project: we needed a tool for general use.
In this project, we restricted ourselves to produce software which is useful for the current level of modeling soft materials. A characteristic of the soft materials is that the relevant length scale is mesoscopic: it is neither atomistic (less than 1 nm) nor macroscopic (more than 1 mm), but intermediate (between 1nm to 1 mm). Theories of soft materials use mesoscopic modeling, and, in academia, many simulations have been done based on them. However, these simulators are made for the personal use of researchers, and usually unusable for the other people. As a result simulators of similar kinds have been made again and again in many laboratories in the world without being used again. We wanted to change this situation.
We set two objectives for our project. The first objective is to build simulation programs which are typically used in the study of soft materials. We called such simulation programs "engines" since their function is to conduct calculations many many times following the instruction of users.
Clearly, the soft material simulator needs many varieties of engines. We chose to build four engines each based on molecular dynamics, reptation dynamics, Edwards self-consistent field theory, and continuum dynamics. They are:
COGNAC : This engine conducts molecular dynamics calculation for polymer models under various external fields (flow and deformation): it can deal with a large class of molecular models ranging from full atomistic models to coarse grained models such as bead-spring models.
PASTA : This engine calculates the rheological response of entangled polymers using the reptation dynamics and the dual slip-link model of entanglement.
SUSHI : This engine solves the self-consistent field equation of Edwards, and calculates the structure of polymers induced by phase separation or surface effect.
MUFFIN : his is a generic engine solving the partial differential equations appearing in the problem of soft materials. It actually consists of five simulation programs, each dealing with (1)phase separation, (2)electrolyte dynamics, (3)micro-fluidics under electric fields, (4)elastic deformation of solids and (5) deformation and swelling of gels.
(The naming of the above engines follows the project internal rule decided at a beer party that engines must have a name of an object which can be found on any kinds of drinking party.)
Detailed description of the engines will be given in the following manuals.
To integrate the engines described above, we needed some platform on which these engines work together. An important design problem there was how to let different engines work together. This problem turned out to be quite difficult. The first problem we had was how to let engines share information with each other. This problem was already quite difficult.
At first, we wanted to have a framework within which we can express certain common notions like, "monomers", "polymers" or "molecular weight". However this approach turned out to be quite difficult. The engines are based on different physical models, and have different views for the definitions of "polymers". Settling the terminology is difficult, and settling the data structure is even more difficult. After some fierce discussion, we realized that even if we were able to invent some data format, nobody would be happy, and nobody would use it.
We abandoned the idea of defining a common data format. The lesson we learned here is that the integration must be done not by force but by voluntarily collaboration of people. We started to think how we can facilitate such collaboration.
The conclusion we arrived at finally is that we should focus on building a common graphic user interface which can be used by all engines. If all engines have the same user interface, users can use various engines easily. If the user interface has some programming function, user can change the data format of one engine to the other, and can do the zooming by himself. This will eventually make reality of the "seamless zooming". We called such general user interface "platform". With that aim, we developed the software GOURMET (Graphical Open UseR interface for Material design EnvironmenT).
GOURMET is an editor and viewer of the text files which engines use. For the text file to be understood by GOURMET, it must be written in a certain format called User Definable Format (UDF) which will be described in the next section.
If the text file is written in UDF, user can see and edit the data in various forms, process the data by script language, do plotting and display the result in 3D animation. GOURMET also has functions to control engines: user can monitor certain parameters of the engine, stop, change parameters, and restart again.
The basic idea of UDF is to give a name to all data in a file. UDF file consists of two parts, the data definition part and the data part. The data definition part is needed to name the data in the file. When a UDF file is read by GOURMET, all numbers and texts in the file are given their names, and can be quoted by their names. This becomes convenient for the data analysis and data process since any data in the file can be quoted by their names, and can be processed by the script language implemented in GOURMET.
The engine programmer can access the data in the UDF file by their names using the platform library: once an UDF file is open, engine program can read and rewrite any data in the file in any sequence.
In the data definition part, engine programmer can define their own unit system using some basic physical quantities, and can state it for each data in the UDF file. Though engine programmer can use UDF file without using this function, we encourage them to state the unit system they use, and to state the unit of each data. Unit is essential information in physical quantities, and it is essentially needed l in converting the data from one UDF file to the other.
In the UDF file, engine programmers can put comments to each data name. The comments can describe the meaning of the data and/or its role in the program. The comments are used by GOURMET and aid the users who opene the UDF file. In future, this function will be enhanced by, for example, jumping to a certain URL, which can give much more information about the meaning of the data.
For a data set in the UDF file, the user of GOURMET can assign a procedure associated with the data set: for example, for a data of random numbers, they can assign a procedure of calculating their averages, and kick this program. This function can be used to prepare the input file and to analyse the output file.
As you see in the above description, we intentionally took a conservative approach in the software design toward our ultimate goal "seamless zooming". There is no mechanism in the design of GOURMET which forces zooming in a certain way. The activity of zooming is entirely left to the user who uses OCTA for a particular system.
From the view point of computational science and engineering, to design a system which secures the procedure of zooming is very challenging. Such research should be done in future in the collaboration of physicists, chemists and software engineers. At this stage, we have a view that what is currently needed toward our goal of "seamless zooming" is actually a mechanism which facilitates the collaboration of many simulation programs, which essentially means the collaboration of people. We hope that what we created will become a base for such collaboration.
Seamless zooming is a grand challenge. We believe that it is a goal which will be reached eventually. At this stage, we are far from that goal. The engines we developed here are not complete: they should be enhanced further, and new engines must be added. The interface we made needs to be brushed up. For this purpose, we are making all the source code open and allow modifications of the users.
OCTA is Greek "8", which is a 90 degrees rotation of the mathematical symbol of infinity. It symbolizes the infinite possibility brought by the collaboration of various simulators dealing with various length scales from micro cosmos to universe. In Chinese, OCTA is written as "”a", which has a meaning of good luck as it symbolizes the growth as we go down. The Chinese character "”a" may be viewed as a mountain, difficult to climb, but eternally inspiring our challenge.
We very much welcome your feed back to this project.
2002 02 22 Masao Doi