What is OCTA |
FAQ | OCTA Application Book |
OCTA Publications |
OCTA BBS |
The OCTA Project
1. The objective of the project
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
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.
2. Seamless zooming
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.
3. Design of OCTA
3.1 Simulation engines
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
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
MUFFIN: This 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.
3.2 User interface
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.
3.3 UDF (User Definable Format)
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.
4. What we are aiming at
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.
5. Why "OCTA"
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 "”ª", which has a meaning of good
luck as it symbolizes the growth as we go down. The Chinese character "”ª"
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
What is OCTA |
FAQ | OCTA Application Book |
OCTA Publications |
OCTA BBS |