OBJECT-ORIENTED SIMULATION OF FLUIDS

OBJECT-ORIENTED SIMULATION OF FLUIDS USING SOFTWARE AGENTS Andrés Díaz Pace 1, Federico Trilnik1 , Marcelo Campo1 and Alejandro Clausse2* 1

Universidad Nacional del Centro 7000 Tandil, Argentina

2

Comisión Nacional de Energía Atómica and Universidad Nacional del Centro 7000 Tandil, Argentina *

Member of CONICET, Argentina

ABSTRACT Object-oriented frameworks are suitable tools to support simulation models of different kinds of collective processes. Software objects, called agents, can perform autonomous tasks, perceiving and reacting to external stimuli, resembling in their way the behavior of fluid particles interacting with the sorrounding environment. In this article, the multiagent framework BUBBLE, implemented in Java language, is applied to recreate bubbly fluid flows.

Key Words: simulation, object-oriented programming, bubbly flow.

I. INTRODUCTION Many problems of practical importance involving sets of a large number of individuals seem to resist analysis along classical mathematical lines. The inherent complexity of these collective systems is usually treated by means of differential equations relating macroscopic average magnitudes, such as mean rates, information flows, etc. In these models, the passage to the infinitesimal limit (while preserving the microscopic structure by means of constitutive laws) is justified, but the concomitant loss of detail is seldom recovered in terms of numerical simplicity; one intractable problem having been translated imperfectly into another, almost as intractable as the first. With the spreading of the software agent paradigm [1] as a byproduct of the object orientation programming [2], new tools to tackle collective phenomena became available to the simulation community. Complex processes can be simulated as an assembly of finite entities that interact according to simple rules based on heuristic considerations [3]. The interaction rules, generally associated with some spatial environment, may or may not bear resemblance to the actual real laws governing the phenomenon at hand. However, in some cases the statistical averages tend to the solution of partial differential equations known to govern the colective. Actually numerical experiments have shown that many complex systems exhibit certain regularities in their global behavior, thus rising hope that quantitative laws may be formulated to encompass disparate phenomena: earthquakes, stock markets, ants colonies, biological systems, and fluids. In this article we show how to apply software agents to simulate complex cooperative processes. We present a multiagent framework that is more general than other previous tools in some respects: (1) continuous composition architectures are introduced, resembling the natural hierarchy often observed in cooperative assemblies; (2) agents communicate with others using events, and they change dynamically their behaviors or roles accordingly; (3) the environment acts as an event manager for the contained agents, and it can be decomposed in subpartitions, providing flexible ways to construct complex

geometries. Thus, while retaining the basic philosophy underlying the multiagent paradigm, a more useful tool is obtained. By means of this development, without invalidating the important advances in other directions, this approach can be very profitable regarding the computer modeling and simulation of complex collective processes.

II. SOFTWARE AGENTS An agent is a software entity embedded in some environment, with autonomous and flexible action, designed to fulfill predetermined goals. The essential features of an agent are autonomy, adaptability and interaction with the environment and with other agents [4]. Virtual worlds of interacting agents can be used to represent real complex problems such as fluids, species populations, sport teams, condense matter, which ultimately share the concept of collective system. According to Ferber [5] the basic components of multiagent computational models are: • • •

Agents: autonomous entities that can perform different tasks, perceiving and reacting to external stimuli. Environment: virtual space where agents and objects exist and interact. Communications: interaction categories.

Agents have been classified in two types: cognitive and reactive [6]. Cognitive agents carry an explicit representation of their environment, and can accordingly anticipate future events and apply logical inference in order to satisfy their goals. On the other hand, reactive agents (RA) are not provided with models of the environment, their behavior being determined through simple stimulus-response, reacting to messages from the environment or other agents. Reactive multiagent systems are much easier to implement than cognitive agents, but their capabilities are more limited. However, recently reactive agents were applied successfully in the study of global patterns emergence in complex systems. Interesting virtual worlds of agents have been created resembling ants populations and bacteria colonies [7-9]. From the engineering point of view, multiagent simulations can be applied to simulate statistical systems, composed of numerous elements, which synthesize non-trivial patterns on the macroscopic scale. In particular, reactive agents are efficient tools to build complex systems by means of simple elementary interactions, due to their remarkable flexibility and adaptability.

III. BUBBLE: A REACTIVE MULTIAGENT FRAMEWORK BUBBLE is an object-oriented framework implemented in Java, conceived and designed to simulate the motion of gas particles in a fluid environment. Later developments and applications demonstrate the wider potential of the framework, which progressively became a powerful support to define and organize RA simulations of cooperative processes characterized by the interaction of large numbers of individuals. A framework provides a general and reusable skeleton of classes and behavior patterns for a given domain, and starting from this support new applications can be developed in a flexible and direct way (see the Appendix). The basic bricks of the multiagent systems are RA described by an internal state and a set of executable tasks. We model the interactions among RA through events delivered and received by each instance-agent. The agents have associated sensors registered to manage events with appropriate relevance criteria (local, regional, by group, by event strength, etc.) We defined the behavior of RA by means of tasks with a condition-action scheme. A task is composed by a series of actions executed by the agents provided that certain conditions are fulfilled. The conditions are related either to the internal state of the agents or the incoming events. The framework admits agents containing groups of other agents, and tasks composed by groups of predefined tasks. In this way, complex interactions, structures and behaviors can be modeled combining primary blocks.

Figure 1 shows a diagram of the conceptual model supported by the framework, and Figure 2 depicts a class diagram with the main classes involved in BUBBLE. The framework architecture can be viewed from three different perspectives: structural organization, communications, and agent tasks.

Sensors B and C perceive event E and pass it to their associated agents

Agents

Agent D sends an event E executing a task B Agent A does not receive event E, for its sensor is not registered to listen to those events

A

D The container catches event E, and dispatch it to the sensors interested in that event

C

Event E is also received by the container

Sensors

ContainerAgent

Sensors hear events in a certain neighborhood within the container

Event eventsRegistry

Figure 1. Conceptual model of BUBBLE´s architecture

Structural organization. BUBBLE is organized applying the pattern of uniform decomposition. Uniform decomposition [10] is the partition of large software components into smaller parts, limiting the composition to a restricted uniform set. A hierarchy of abstraction levels represents the interaction between agents: agents composed by other agents, that in turn are composed by others, and so on. The same structure is used in the management of events. This technique allows a simultaneous scaling of the system and integration of the components, ensuring modifiability and reusability (See Fig. 3). The classes that support the structure are: • • •

Agent: defining the basic RA. ComposedAgent: subclass of Agent that shelters other agents. ContainerAgent: subclass of Agent that shelters both agents and sensors, and manages events between the sheltered agents.

Communications. The communications among the different components in BUBBLE are performed through events. Every agent in BUBBLE is linked to a container, and this container collects and sends incoming events to its registered sensors. Sensors act like filters, communicating "interesting" events to their associate agents, using an implicit-invocation mechanism [11]. The container agent manages the flow of events between all the agents. The classes responsible of communications aspects are: • • •

Event: representing a notification of any change occurring in the system. Sensor: receptor and conditional transmitter of events (filter). ContainerAgent: distributes the events to the sensors.

Task {abstract} currentPriority : double owner : Agent outParameters : Hashtable inParameters : Hashtable state : int

ComposedTask {abstract} tasks : Hashtable {abstract} connect() setTask(String, Task) getTask(String) : Task

+outParameters 1..*

{abstract} active() changeCurrentPriority() {abstract} addInParameters() 0..* {abstract} addOutParameters() getInParameter(String) : Object setOutParameter(String, Object) setState(int) 0..* {abstract} run()

+tasks

+owner

0..* Pipe value : Object setValue(Object) getValue() : Object connectTask(Task, String)

1..*

0..*

+inParameters +tasks Agent {abstract}

AgentEvent

properties : Vector tasks : Hashtable eventsList : Vector eventManager : ComposedAgent

arguments : Vector source : Agent type : int

+eventsList 0..*

setProperty(String, double) getProperty(String) : double 0..* {abstract} outOfLimits(AgentEvent) : boolean sendEvent(AgentEvent) updateEvent(AgentEvent) selectTask() run()

getSource() : Agent getArgument(int) : Object setArgument(Object, int)

0..*

+target Sensor {abstract}

ComposedAgent {abstract} children : Vector

target : Agent

addAgent(Agent) releaseAgent(Agent) getChildren() : Vector {abstract} handleEvent(AgentEvent)

{abstract} captEvent(AgentEvent) : boolean updateEvent(AgentEvent)

+children

ContainerAgent {abstract} sensors : Vector dispatchList : Vector eventsRegistry : Vector[]

0..*

+sensors

+dispatchList

addRegistry(int, Sensor) removeRegistry(int, Sensor) addSensor(Sensor) getSensors() : Vector dispatchEvent() handleEvent(AgentEvent)

Figure 2. BUBBLE class diagram

Tasks. All the agents of the framework perform sets of tasks. A task is composed by one or more procedures, with a set of input and output parameters. The tasks are triggered by predefined conditions, which can be related to the internal state of the agents or external events. In addition, tasks can be networked to compose higher level tasks with sets of simple modules. BUBBLE uses a Pipes-and-Filters pattern [11] combined with a uniform decomposition structure. In this way, we can dynamically assign different tasks to an agent, and the tasks compete to execute according to their priorities and activation requirements. The classes associated with agent tasks are:

• • •

Task: representing a simple task. ComposedTask: representing a net of simpler tasks. Pipe: objects that connect tasks.

Component A Component Component B

Interactions

Component C

Component D

Component E

Figure 3. Uniform decomposition organization

IV. APPLICATION CASE: BUBBLY FLOW Bubbly flows are encountered in many industrial applications, such as distillation columns, nuclear and chemical reactors, oil piping, among others. Wherever two unmiscible fluids are forced to flow together, one of them tend to concentrate in bubbles, the other fluid acting as a continuous carrying environment. Generally, macroscopic global magnitudes are used to characterize the flow, representing the relative amount of each fluid component, the number of bubbles per unit volume, the interfacial area density, the average bubble size, etc. Sets of partial differential equations are used to describe the spatial and temporal dependence of the global magnitudes, which should be coded and numerically solved by computational means. On the other hand, multiagent modeling introduces the computer in the starting point of the description, simulating the fluid particles as software agents, and afterwards global statistical patterns are calculated in order to identify the general laws resembling real flows.

We represent the flow of bubbles as a multiagent virtual world composed of a continuous liquid container (which can be partitioned in slices to construct arbitrary geometries), and a disperse phase instantiated in numerous bubbles (agents) embedded in the liquid. The bubbles are codified as reactive agents represented by spheres, which perform the following set of tasks (see Fig. 4): a) Displacement, the center of each sphere is displaced a constant distance d in a random direction θ . b) Coalescence, when two or more bubbles collide, they coalesce giving birth to a new bubble conserving the total volume. c) Breakup, each bubble is allowed to breakup into two bubbles conserving the total volume, following a given stochastic model (for example when the size is larger than a certain critical size).

Displacement Coalescence

Breakup

Figure 4. Bubble tasks

The continuous fluid is partitioned in slices, which being themselves agents have particular properties, such as turbulence intensity represented by spatial variations in the displacement task. By linking the slices, different geometrical configurations can be constructed, such as pipes, bends, or irregular vessels. The slices provide the figure of a neighborhood, precluding interactions between distant bubbles by limiting the reception of events to local bubbles. This feature greatly reduces the flow of events in the system. Additionally, partitioning the space in blocks represented by slices we can easily simulate complicated geometries (piping, bends, etc.). The bubbly flow model was implemented specializing the BUBBLE framework according to the requirements of the application domain. The fluid is an environment agent divided in slices. Inside every slice, bubble-agents represent the dispersed fluid. The agents Environment and Slice are modeled as specializations of Agent. An additional agent, BubbleView, manages the visualization of the simulation, and the statistical data is collected and processed by the StorageAgent. These last two components were implemented following the same conceptual model defined in the framework.

Redefining the bubble tasks, more complex transport phenomena can be simulated with great easy. Likely, composed tasks can be engineered to resemble complex interactions between bubbles, such as wake trapping and vortex induction. On the other hand, mass exchanges between phases are easily simulated by tasks performed by Slice and Environment classes, which can create and annihilate bubble instances. Case study: bouncing bubbles. The first case study is the trapping of certain amount of gas inside a stirring liquid cube (Fig. 5). Fixing the total volume fraction of the box occupied by gas, α called the void fraction in the fluidists jargon the agents are allowed to evolve according to their reactive tasks. Bubbles with radius larger than 3 % of the box side may breakup with probability 0.7. The bubbles randomly move, clash, coalesce and break, asymptotically finding an equilibrium state when the balance of annihilation by coalescence and creation by breakup is reached.

Figure 5. Bubbles in a box. Changing the void fraction, the bubble size distribution also change, to accommodate the breakup and coalescence rates. Several global magnitudes can be calculated in order to monitor the dependence of the equilibrium state with the void fraction. Figures 6 and 7 show the influence of the void fraction on the relevant global variables, defined as: • • • •

Bubble number density (n): Average number of bubbles per unit volume. Interfacial area density (A): Average area of the bubbles per unit volume. Coalescence rate (C): Average number of coalescences per unit volume per unit time (in equilibrium equals the breakup rate). Area production rate ( A ): Average interfacial area augmentation by breakup per unit volume per unit time.

0.5

0.024 Bubble number density

0.4 0.018 0.3 0.012 0.2 0.006

0.1 Interfacial area density

0.000 0.00

0.05

0.10

0.15

0.0

0.20

Void fraction Figure 6. Bubble number and interfacial area density in a box. Side = 5, displacement = 0.1, critical breakup radius = 1.

20 12 Coalescence rate / 10

-5

15

9 10 6 Area production rate

5

3 0 0.00

0.05

0.10

0.15

0.20

0

Void fraction Figure 7. Area production and coalescence rates in a box. Side = 5, displacement = 0.1, critical breakup radius = 1.

Figure 6 compares the bubble number and the interfacial area density in a square box. Both magnitudes increase with a power of the void fraction: α 0.75 the interfacial area density and α 0.3 the bubble number. The profiles are in agreement with experimental data in turbulent bubbly flows. Figure 7 depicts the coalescence rate and the corresponding area production by breakup. Case study: rising bubbles. The second case study was a bubble column. Bubbles are injected at the bottom of a pool and moves responding to a rising bias rule (simulating buoyancy) superposed to random displacements (see Fig. 8). Figure 9 shows the axial profile of void fraction and bubble number density along a bubble column. The resulting profiles are consequence of the competition between bubble sources, inflows and outflows at the plume axis. Far from the injection point, the void fraction and the bubble number density decreases monotonically due to the plume spreading.

Slices

Bubble injection

Figure 8. Bubble plume.

IV. CONCLUSIONS Object-oriented frameworks offer a new perspective for simulation of collective processes. The paradigm of reactive agents combines uniform decomposition structures and event-based styles, ensuring flexibility and modularity. We can simulate realities composed of large number of elements specifying the framework to particular domains, represented by agents, tasks and interactions. The tool presented in this work should be seen from a perspective showing the potential of multiagent modeling to recreate complex realities. It is hoped that the ideas and results presented here stimulate other researchers to further investigate collective processes using the proposed methodology.

0.100

0.20 n 0.15

0.080 0.060

α

0.10

0.040 0.05

0.00

0.020

0

4

8

z (cm)

12

16

0.000 20

Figure 9. Axial profile in a bubble plume (Critical breakup radius = 1 cm, random displacement = 1 mm)

REFERENCES [1] Shoham, Y.: Agent-oriented programming. Artificial Intelligence, 60(1):51-92. (1993) [2] Meyer, B.: Object-Oriented Software Construction. Second Edition, Prentice-Hall. (1997) [3] Gutowitz, H.: Artificial-Life simulators and their application. Report written for the French government. (1995) [4] Sycara, K.: Multiagent Systems. In AI magazine Volume 19, No. 2. (1998) [5] Ferber, J.: Reactive Distributed Artificial Intelligence: Principles and Applications. In "Foundations of Distributed Artificial Intelligence", Chapter 11, edited by G.M.P. O'Hare y N.R. Jennings. A Wiley-Interscience Publication. (1996) [6] Demazeau, Y., Müller, J. P. eds.: From reactive to intentional agents. In Decentralized Artificial Intelligence 2, pp. 3-14. Elsevier/North-Holland, Amsterdam. (1991) [7] Drogoul, A., Ferber, J.: Multi-agent simulation as tool for modeling societies: Application to social differentiation in ant colonies. Proc. Eur. Workshop Modeling Autonomous Agents Multi-Agent World, 4th,Rome, Italy. (1992) [8] Kreft, J., J., Booth, G., Wimpenny, J. : BacSim, a simulator for individual-based modeling of bacterial colony growth. Microbiology, 144:3275-3287, forthcoming. (1998). [9] Carnahan, J., Li, S., Costantini, C., Toure, Y., Taylor, C. : Computer Simulation of Dispersal by Anopheles Gambiae s.l. in West Africa. In C. Langton and K. Shimohara, editors, Artificial Life V: Proceedings of the Fifth International Workshop on the Synthesis and Simulation of Living Systems, Complex Adaptive Systems series, pages 387-394, Boston. MIT Press. (1997). [10] Bass, L., Clement, P., Kazman, R. : Software Architecture in Practice, Chapter 6: Unit operations. Published by Addison-Wesley. (1998). [11] Shaw, M., Garlan, D.: Software Architecture, perspectives on an emerging discipline, Chapter 2: Architectural Styles. Published by Prentice-Hall. (1996)

APPENDIX: OBJECT-ORIENTED FRAMEWORKS Object-oriented programming pioneered in software engineering is becoming the standard programming paradigm in computer science. Object-oriented languages differ from traditional procedural ones, in organizing programs into sets of interacting objects instead of hierarchies of procedures, functions or routines. An object is the minimal computing unit that shelters data and the code for transforming such data. This code should be viewed as the behavior of the object, executed when asked explicitly by another object (much like a function call in procedural languages). We define the code abstractly by classes, the objects being instances of. Classes are organized in inheritance hierarchies. A class can inherit the code implemented by superclasses. The inheritance mechanism is distinctive of object-oriented languages and it enables the reuse of the classes previously implemented. We construct the program defining abstract classes incompletely, leaving the particular implementations to appropriate subclasses. For example, to display a draw we design a class Figure implementing only the way to fix the position. The shape is then implemented in subclasses (Circle, Rectangle, etc.), which inherit the position function. Figure is an abstract class while Circle and Rectangle are concrete classes. A framework is a set of classes abstracting the general characteristics of a domain, coding the generic control structure. We can use frameworks to build specific applications by implementing appropriate subclasses, while inheriting the global structure. You may see frameworks as sort of templates for programming. The applications use the same overall structure, varying mostly in the particular methods called from the framework. In this way, we can reuse codes, taking advantage of good software designs provided by experience and expertise.