JIVE:
Java Based Visual Environment
for Engineering Simulation
L. Van Warren
© 1998 * All Rights Reserved

Architectural Background

Consider an object on a background canvas within a browser such as this.
The graphical object represents a chunk of Java, that is, an instance of a Java object.

 
I would like to: a) select the object:
(which would correspond to selecting a specific instance of a Java object.)
I would like to: b) copy the object:
 
(which would correspond to creating an identical duplicate instance of a Java object.)
I would like to: c) paste the object so we can have another one to do something different with:
(which would cause the display manager to keep track of two Java objects.)
d) or decide I didn't want to do that and delete the pasted object:
(which would cause the duplicate instance to be removed.)
 
That object itself might consist of 1) subobjects, or 2) it could be a pre-existing hunk of java.
 
If the object had subobjects: If the object were a pre-existing hunk of java:
I want to edit the subobjects interactively:  
I would be taken to the code where I could make changes:  

 public void Graph(double xDrawBuf[],  Color fore,  
  {  
     setColor(back);  

     // draw x axis and y axis  
    graphics.drawLine (xCurr + 0*dps    , yCurr  
    graphics.drawLine(xCurr + W*dps/2, yCurr  

    // set line color  
    setColor(fore);  
  
    // convert from squares to pixels  
    Math2.linMapInterval(xDrawBuffer, xDrawBuffer,  
  }  
  
  
 

 
I would like to be able to do a simulation as a set of analytical pieces and then link them together visually.  I would like to be able to "stub off" portions of the simulation with fake behaviors until an appropriate analytic model could be developed.

For example if I wanted to do a simulation of an automobile engine, I might choose to break that down as a single cylinder engine running autonomously.  I might choose to break a single cylinder engine into a combustion chamber, a piston, a connecting rod and a crankshaft object.  Each piece would have a visual component consisting of geometry and rendering specifications.  Each piece would have an analytic model possibly consisting of a  different geometry with a material specification.  These could be used to compute mass.  Input messages would be the external forces applied to the object.  Output messages could be the new position, velocity and acceleration applied to interface models which would handle the connection between objects.

A key aspect of all this is to develop a one to one correspondence between visual models and Java objects.  Let's develop this for a set of simple structural problems.

Consider the table of object below.  By combining instances from the table a large number of common engineering problems can be expressed, even though the vocabulary is incomplete.  We would like to freely choose among the constraints, links, springs and forces to connect some kind of a structural abstraction together.  We would then like to click a "Run" button and find out what happened to the structure.  Did it move?  Did it bend?  Does it reach equilibrium, does it keep accelerating, does it oscillate?
 

Wall
dx =0
 VDolly
dx = 0
VMount
dx = 0
dy = 0
Pivot
 
dx = 0
dy = 0
dM = 0
 Link
dL = 0
 Bank
dy =-dx
 TDolly
dy = -dx
TMount 
dx = 0
dy = 0
Weld
 
dx = 0
dy = 0
dq = 0
Spring
 
F = kx
Floor
dx=0
HDolly
dy = 0
 HMount
dx = 0
dy = 0
Force
F = ai+ bj
 
Table of Possible Objects for An
Interactive Statics and Kinematics System
 
 
 Statics
Problem A
Dynamics
Problem B
 Dynamics
Problem C
Three Simple Problems Built From Table
 

How would we organize such a tinker toy engineering system along an object oriented paradigm?  What unifying algorithm could be used that would cause the solutions that we see from statics and dynamics to simply appear?  How would we distinguish solution steps that iterate towards static equilibrium from those that march in time?  Can we model the three problems on the bottom row of the table as an automatic conversation among cooperating objects?

Consider the leftmost problem in the bottom row of the table, the statics problem.  The "conversation" might go something like:

Force object:
    Who am I connected to?
    Let me check my table.
    I am connected to node B of link A.
        Tell [Link A: Node B] that [Force: F = ai+ bj].
End Force

Link object:
    Who am I connected to?
    Let me check my table.
        For each subobject:
            Node A:
                I am connected to a fixed constraint.
                I cannot move in x, in y or theta.
                i = Case[3,1]    // from green class table above
             Node B:
                I am connected to a Force object.
                I will ask Force what their* message is.
                    Ask[Force object]**
                        Force tells me I have an applied force of  [Force: F = ai+ bj].
                j = Case[3,4]

        End For

        run Solver[i, j] to compute new link state [ pos, vel, acc, rot, bending, shear, elongation, etc.]

        update my free body diagram
End Link

Floor object:
    Who am I connected to?
    Let me check my table.
    I am connected to node A of link A.

    Tell [node A of link A] that [Floor: dx = 0, dy = 0, dtheta=0].

    ask Solver for reaction so I can

    update my free body diagram
End Floor

Remarks

Note that the force and floor objects do not run the solver.  Only the link has the power to run the solver, since it is the only object that has the possibility of a change of state.  However the floor object needs to consult the solver to find out what the reaction was so that the free body diagram of the floor reaction can be drawn.

 One should be able to go through an elementary statics and dynamics text, specify the problems in JIVE and click run.  Easy as pie.
My question, and reason for creating this document was this, "Can this be done?", "Is Java the right implementation language",  "are their better solutions already in existence that will allow me to worry about the problem instead of the solution methodology?".

I have always wanted to pose engineering problems on a unified visual platform.  Until Java appeared there was no widely available object oriented programming language that wasn't riddled with the frailties of pointers.  If Java holds to its promise of "write once, run everywhere", it could be a significant advance.  The appearance of the Microsoft Java Application Foundation Classes (AFC) solves many of the user interface problems that plagued earlier versions of Java.  It is not clear at this writing how the AFC integrates with the existing development environments such as Visual J++.  We'll have to wait a couple of days for that epoch to pass.



 
* her/his --> her his --> heris --> heirs --> theirs --> their

**"Ask" causes an evaluation of an object if the objects output queue is empty.  If the object has been evaluated then the message in the output queue of the object is sent.