|> Y1 = f(X1) this function may requre iterative calculations to solve.
|> To make things worse, the liquid and vapor usually don't
|> actually reach equilibrium. A heuristic method is used
|> determine the psuedo-equilibrium relation, such as
|> Murphree tray efficiency.
|>
|> For multicomponent distillation, it gets much more difficult to express
|> the relationship mathematically.
|>
|> For steady state, there are 8 variables:
|>
|> L0, L1, V1, V2, X0, X1, Y1, Y2
|>
|> But there are only three equations - two mass balances and an equilibrium
|> relationship. And the equilibrium relationship may not be a simple equation.
|>
|> That means that we have 5 degrees of freedom for this object. Yet, at steady
|> state, all 8 variables will be fixed.
|>
|> So, to represent this tray as an object, it is impossible to determine the
|> steady state values of the variables from the mathematical description of this
|> one object alone. So the equations for *all* of the trays are combined and
|> solved simultaneously. But in so doing, we are no longer looking at each
|> tray individually.
|>
|> If we use the unsteady state model, we will have to solve differential
|> equations in the mass balances for each tray. We will have to do this
|> in each tray, and it will have to be done simultaneously for all the trays
|> for the results to be accurate. So, what we have is a number of autonomous
|> objects, each doing its own calculations for unsteady state response to
|> changes in the input streams, and all of these objects communicating with
|> the other objects about the composition and flow rate of the streams leaving.
|> All of the objects must be running simultaneously, or at least time sharing,
|> and the inter-object communications has to be as fast and efficient as
|> possible.
|>
|> In effect, what this will be is a distributed mathematical inference engine.
|> It will solve simultaneous differential equations in a natural order, rather
|> than in an artificial order. Currently, matrix methods are used to solve the
|> simultaneous equations, but the matrix methods suffer from combinatorial
|> explosion. There is a whole field of Chemical Engineering devoted exclusively
|> to finding more powerful methods of solving these simultaneous equations -
|> High Performance Computing.
|>
|> Industry relies primarily on heuristic methods, and in the undergraduate
|> courses, that is what we teach. But the heuristic methods are limited
|> to correlating parameters with experimental results. In other words, they
|> are a sort of 20/20 hindsight. Thus, they limit problem solutions to what
|> has already been done rather than what could be done.
|>
|> Now, all I need is the ability to design and implement an object that will
|> communicate dynamically with other objects that are running concurrently on
|> either the same processor, or on other processors. That sounds just like
|> what a lot of people are already doing - no? Yes, no, and maybe.
|>
|> To be really valuable (and I mean $$$$$ valuable), the design and
|> implementation of objects at different levels - for example a distillation
|> column at one level, and the components of the distillation column at a
|> lower level - needs to be as flexible as possible, and may require several
|> models for behavior. A distillation column, for example, may have a heuristic
|> model based on empirical correlations, a steady state model based on Lewis
|> method tray by tray calculations (the simplest model), and a dynamic model
|> that is actually calculated by the individual tray objects themselves.
|> By having multiple models, any of the models may be developed after the
|> object has already been implemented. This would be a valuable tool for
|> model refinement. Not only that, it would allow an object to be implemented
|> without being fully specified. That is a common situation - incomplete
|> specification. Also it would give a means of identifying and correcting
|> inconsistent specifications. The *REAL* bonus of this approach is that
|> when rigorous calculations are *not* necessary, they aren't performed!
|> Since it is a distributed system, that decision is handled locally.
|>
|> For multicomponent distillation, it may be necessary to use heuristic models
|> to describe the phase equilibria - that is, how the fraction of a component in
|> one phase is related to the fraction of the same component in another phase.
|> And that may require a database. Obviously, we would want a shared database,
|> and fast access to the database.
|>
|> Dr. James P. Henley Jr.
|> Visiting Assistant Professor
|> Department of Chemical Engineering
|> Auburn University
|>
|>
The ability to communicate between objects which are running concurrently is
one of the goals of Project DOE (Distributed Objects Everywhere). The Distributed
Object Management Facility (DOMF) underlies DOE and is responsible for
routing messages between objects and providing persistent storage of objects
for future use.
For those who can't wait for Project DOE (first release is in late '93),
there is still Unix message queues (for objects on the same platform)
and TCP/IP sockets (inter-platform communication). This means a process
is responsible for reading the queue/socket and routing the message to the
objects which live inside that process. This is how we do object message
in our network monitoring system.
As for having an object behave differently in varied circumstances and
allowing this behavior to be incompletely defined, this may be solved
by polymorphism and inheritence. I envision a distillation column
class with three derived classes: heuristic, steady state, and dynamic.
The distillation column class would contain the state variables.
The model used in each of these classes would be put into a virtual
method (to borrow a C++ term). The default definition of this model method
would do nothing allowing an object to be incompletely defined. Users who
wish to update the model would create a new class which is derived from one of the above three classes (heuristic, steady state, and dynamic) and the model method would be redefined.
As for a shared database, there are many database systems which support the
client/server model in the Unix world (my stomping grounds). This means that
objects can access the DB across multiple platforms. Some of these DBs
use the relational model (e.g. Informix, Oracle, Sybase) and some the
object model (e.g. ObjectStore, Objectivity, Ontos).
The one caveat regarding distributed objects is that problems are greatly
reduced when the platforms are the same. Cross-platform communication in
