In Proc. of TOOLS EUROPE’92, Dortmund, Germany, March 30 - April 2, 1992. Published by Prentice-Hall
Industrial Application of Object-Oriented Mathematical Modeling and Computer Algebra in Mechanical Analysis Peter Fritzson, Lars Viklund, Johan Herber, Dag Fritzson* Department of Computer and Information Science Linköping University, S-581 83 Linköping, Sweden Email:
[email protected], Phone: +46 13 281484 *SKF
Engineering and Research Centre B.V. Postbus 2350, 3430 DT Nieuwegein, The Netherlands Abstract: In this paper, we present the first programming environment and modeling language which integrates inheritance within a computer algebra language. This environment and language, called ObjectMath (Object oriented Mathematical language for scientific computing), is currently being used for industrial applications in advanced mechanical analysis, but is generally applicable to other areas. Using ObjectMath, it is possible to model classes of equation objects, to support inheritance of equations, and to solve systems of equations. The ObjectMath environment is designed to handle realistic problems. This is achieved by allowing the user to specify transformations and simplifications of formulae in the model, in order to arrive at a representation which is efficiently solvable. Such algebraic transformations can conveniently be supported since ObjectMath models are translated into the Mathematica computer algebra language. When necessary, equations can be transformed to C++ code for efficient numerical solution. The motivation for this work is the current low-level state of the art in programming for scientific computing. Much numerical software is still being developed the traditional way in FORTRAN. This is especially true in application areas such as machine elements analysis, where complex non-linear problems are standard. We also report some experience from successful use of a prototype version of ObjectMath in representing and solving a 3-dimensional example model of 200 equations describing a rolling bearing. The re-use of equations through inheritance reduced the model by a factor
of two, compared to a direct representation of the model in the Mathematica computer algebra language. Keywords: Object oriented, Scientific computing, Computer algebra, Compilation, Symbolic transformation, Mechanical Analysis, Programming environment
Introduction In this paper we report work on developing a practically usable high-level object-oriented programming environment for scientific computing, which supports programming in equations instead of low-level procedural programming, and permits better re-use of equations in mathematical models. So far, a prototype of such an environment including a modeling language (ObjectMath – Object oriented Mathematical language for scientific computing) has been designed and implemented, and used for a rather realistic application. Initially the application domain for scientific computing has been chosen to be mechanical analysis of machine elements. The goal for this application domain is to create a Mechanical Analyst's Workbench for high level modeling and application development. However, obtained results are generally applicable, and can be used in most application areas of scientific computing. In our view it is essential to cooperate with application experts in scientific computing in order to focus the research on realistic problems rather thant just toy problems. The structure of the paper is as follows: First we review the current state of the art in scientific computing, and propose an alternative improved development strategy. Then, the structure of typical models in the machine elements application domain are analyzed. This is illustrated in terms of a rolling bearing example. The requirements of a very high level programming and modeling environment are reviewed. Then the design, use
and implementation of the ObjectMath environment is discussed, followed by implementation status and conclusions. An appendix contains most of the rolling bearing model expressed in the ObjectMath language.
Motivation The current state of the art in modeling and programming in scientific computing and advanced mechanical analysis is still very low-level. A designer often spends more than half the time and effort of a typical project in writing and debugging FORTRAN programs. These programs are written in order to perform numerical experiments to evaluate and optimize a mathematical model, e.g. of a machine element. Numerical convergence problems often arise, since the optimization problems usually are non-linear. A substantial amount of time is spent on modifying the program to achieve convergence. Feedback from results of numerical experiments usually lead to revisions in the mathematical model, which subsequently require re-implementing the Fortran program. This whole process is rather laborious and error prone. There is a clear need for a higher level programming environment that would eliminate most of these lowlevel problems and allow the designer to concentrate on the modeling aspects. Machine, Material, Geometrical Knowledge
Feedback
Systems of equations Numerical Implementation (FORTRAN programs)
Numerical Solution of Optimization Problems
Graphical Presentation Figure 1. The iterative process of modeling in traditional mechanical analysis. Often 50-75% of the time is spent on FORTRAN programming.
Application domain: modeling in mechanical analysis At the current state of the art, there are two main classes of activities within research projects or advanced de-
velopment projects in mechanical analysis of machine elements: •
Theory development
•
Numerical computation
During theory development, a mathematical model is developed that describes the relevant properties of the investigated machine element. This is normally done manually, using only pen and paper. In order to perform numerical computations, the model must be translated to some programming language, or to input specifications for some existing numerical modeling program, such as for example a finite element analysis program. Normally, existing high level tools can at best be used for limited parts of the total computational problem, because it usually is too complex.
The ideal programming environment: programming in high-level equations The ideal high level programming environment would automatically transform systems of equations into efficient symbolic and numerical programs. It would select optimization routines with good convergence properties for the given problem. The environment would also aid in formulating equations given geometrical constraints and transforming equations between different coordinate systems. However, fully automatic versions of some of these capabilities will be hard to achieve. It is more realistic to assume that the user will work in dialogue with the interactive system, and that the user can supply valuable hints and information that will guide the system to choose the right algorithms and transformations. Another important advantage of an equational representation over a FORTRAN implementation is that more inherent parallelism of the problem is preserved. Thus better results can be expected when generating code for parallel machines. Some desired capabilities are listed below: •
Support in expressing systems of equations, e.g. handling geometrical constraints and coordinate transformations
•
Integration of object-oriented techniques in equational modeling
•
Algebraic transformations of equations
•
Compilation/transformation of model equations to efficient numerical programs
•
Transformation of equations for computation
on parallel hardware •
Convergence and selection of optimization methods
•
Evaluation of Numerical Experiments
•
Graphical presentation
A comparison between the current and the proposed practice is given in a table on the next page.
Currently available tools In this section we make a quick overview of some currently available tools, their strengths and weaknesses. A more detailed review, including full references and discussion can be found in [Fritzson,Fritzson-91a]. So far, none of these tools offer exactly what we want, although some provide a subset of the desired capabilities. One group of tools and methods include finite element analysis (FEM), Multibody systems analysis programs [Schiehlen-90], CAD (Computer Aided Design) and CAE (Computer Aided Engineering). Some of these tools could theoretically solve the above problems. However, they usually generate masses of low-level numerical data, which is not what we want. Also, they tend to be very inefficient, especially on non-linear problems. They provide no equational model development support. Computer algebra systems such as Macsyma, Maple, Reduce and Mathematica are good at representing and manipulating symbolic formulae and equations, but are lacking model development support and efficient numerical computation. However, their symbolic capabilities are needed in our desired environment. Matrix languages such as APL, Fortran8X and especially MATLAB, provide convenient programming of matrix, vector and linear algebra related problems. However, non-linear problems are not handled and symbolic formula capabilities are missing. There are several numerical differential equation solving systems, e.g. SIMNON [Elmqvist-75], which accept as input a set of partial differential equations expressed in an attractive high-level algebraic form. However, these systems lack algebraic capabilities and use bruteforce numerical difference methods to solve the partial differential equations. This often leads to totally unrealistic computation times, and generates vast amounts of low-level data.
There are also hybrid systems for numerical optimization, using expert system techniques to automatically select the appropriate solution or optimization routines. Another class of systems are hybrid systems for algebraic-numerical-graphical analysis, including GENTRAN, FINGER, MathStation and MaMis. These systems combine a computer algebra system with capabilities for generating and executing numerical code, but have no support for object-oriented structuring of equation-based models and inheritance of equations.
Mechanical analysis software modeling and implementation: a concise recommendation Current Practice: Model Specification Using pen and paper: Visual modeling of geometry & constraints. Specify mechanical and material equations. Equational modeling of geometry etc.
Proposed Practice: Model Specification Use an object-oriented design tool. Specify important objects. Interactively specify geometry and constraints using an editor. Associate mechanical and material equations with objects.
Equational specification for solution
Equational specification for solution
Algebraic transformations by hand: Algebraic coordinate transformations. Transform equations to prepare for solution of relevant quantities.
Use a computer algebra system for algebraic transformations of equations. Use parametric models of geometry. Built-in geometrical formula support. Algebraic coordinate transformations. Transform equations to prepare for solution for relevant quantities.
Numerical solution model
Numerical solution model
Using pen and paper: Choose optimization and numerical algorithms. Reformulate the equational model as an optimization problem.
Semi-automatic tools for classification and choice of solution algorithms. Use a computer algebra system to reformulate the equational model as a simulation/optimization problem.
Numerical implementation
Numerical implementation A compiler generates code from the set of equations. Generation of code for data flow between solution routines. Semi-automatic classification and interpretation of convergence problems.
Write Fortran code: Use existing applicable subroutines. Implement data flow between routines. Try to understand convergence problems. Manually fix convergence.
Interpretation and visualization Interpret numerical results. Write plotting programs for visualization.
Interpretation and visualization The object-oriented model is used for automatic visualization of certain numerical results. Semi-automatic state-space analysis. Diagrammatic visualization.
The Structure of Models in the Machine Element Application Domain We need to describe the structure of machine elements, i.e. the parts, components and their substructure, together with material data and interaction between components. These together represent the total machine element. As an example machine element model, we will use a rolling bearing model throughout this paper. The picture of the rolling bearing below has been automatically generated from model equations expressed in the ObjectMath modeling language. Outer Ring (Er)
Roller (W[i])
Part-of relation
Ex ring
In ring
Bearing
W[1] roller
W[2] roller
...
W[n] roller
Figure 3. Physical structure: the parts hiearchy for a simple version of the bearing model
Inner Ring (Ir)
Relevant geometry description For example, this can be a detailed parametric surface/ volume model, or just a few parameters such as diameter and length.
Function description The function is the most important aspect of a machine element model. This may include many aspects such as: a model for deformation under external loads and temperature, strain and stress inside the body, interaction with other machine element bodies including contacts and forces, interaction with a fluid, etc. Figure 2. A three-dimensional view of the rolling bearing, automatically generated from the model example equations Considering our machine element example, the rolling bearing has the following structure:
Parts: Rings: Inner ring. External ring. Rolling element set(s): Rolling element 1. Rolling element 2, etc. Guiding elements: Cage(s). Centre ring. Lubricant.
Material models/data: Here we are concerned with material models and material data for materials and fluids. Solid material model. Solid material data for different materials: Material 1. Material 2, etc. Fluid material model. Fluid properties data: Lubricant 1. Lubricant 2, etc.
Analysis oriented modeling So far we have discussed a descriptive and easily understood type of model exemplified by a rolling bearing. Such models describe what parts an object consists of and what functions they perform. In this section we concentrate on the analysis aspect, i.e. what equations we should solve and which quantities are relevant. The previous description must be modified to suit this purpose. This should be done without losing the “natural” decomposition and description of the machine element and its function. We also introduce the term “object”. An object can represent many different things and we can have different classes of objects. Some examples of what an object can be are: •
A real three dimensional body.
•
An equation.
•
A coordinate system.
•
A set of material data.
•
or a combination of those items.
Regarding the previous description of the rolling bear-
ing example one can conclude that there are primarily two types of information that can be grouped into objects: •
•
Self-contained objects These are objects which are more or less selfcontained, e.g. physical objects or abstract objects such as coordinate systems. They describe a certain object and not the relations between objects. Connection objects The main purpose of these objects is to describe relations and connections between other objects. A typical example is a contact between two physical bodies.
Another observation is that it is quite useful to use existing objects when defining new objects. New objects can be defined through composition and combination of existing objects, or as specialization of existing objects using inheritance. For example, a cylindrical roller element can inherit many properties from an existing general cylinder object, and add special information such as size and material properties.
Instantiation and Inheritance Roller
Ex ring
In ring
Instantiation and Inheritance
A coordinate system.
•
A theory that describes the structural deformation of a body given loads or displacements on the body.
•
A material model for a material.
•
Material data for a certain solid.
•
Material data for a certain fluid.
When defining the external ring object, it is natural to use and combine several of the basic objects defined above in order to give an appropriate description of a general simple ring object. We then create the external ring machine element object, by inheriting from the general ring object, and adding properties that are special for the external ring. When later defining an object such as the inner ring, we can create a new object that inherits information from the general ring object, and subsequently add specialized information.
...
W[n] roller
The purpose of connection objects is to describe relations and connections between self-contained objects. This corresponds to forming systems of equations in traditional analysis.
In this class of objects there are several natural different object classes that describe various aspects of the studied problem. Some examples of basic objects:
•
W[2] roller
Connection objects
Inheritance
A geometry description of a physical body.
W[1] roller
Figure 4. Inheritance and Instantiation of Self-contained Equation Objects for the Rolling Bearing
Self-contained objects
•
SimpleRing
Inheritance
GeneralContact
NonFrictionContact
NonLinearContact
FrictionContact
LinearContact
Con Con . . . Con ExW[1] ExW[2] ExW[n]
Con InW[1]
Con . . . Con InW[2] InW[n]
Figure 5. Inheritance and Instantiation of Connection Objects for the Rolling Bearing
Examples of connection objects are: •
Fixed contacts or connections between bodies.
•
An elastohydrodynamic contact between two bodies.
•
A full film contact between two bodies.
•
Interaction between a fluid and a body.
•
Equilibrium conditions for a body or a set of
bodies. •
A constraint which reduces the number of degrees of freedom.
•
An application of a certain displacement, rotation, or force field to a body.
It is possible to classify connection objects into two loose groups: •
•
Binary connection objects that involve two self-contained objects. Examples are contact problems. One to many connection objects that involve a relation between one self-contained object and many other self-contained objects. An example is a force field which is influencing many bodies.
When defining new connection objects it is natural to combine existing basic connection objects, or to use inheritance to re-use most definitions from general connection objects when defining classes of more specialized objects. For example, a general contact can be specialized into the two classes non-friction and friction contacts, where all general contact and equilibrium equations can be re-used. The class of non-friction contact objects can then be further specialized into linear or non-linear contacts, etc.
Requirements on the Ideal Programming Environment Below, we make a quick overview of some desired properties of an ideal programming environment. Our current prototype implementation of this environment provides some support within each category, with an emphasis on model specification and model transformation.
equations from general objects to more specialized objects should be supported. It should be possible to model constraints and connections between physical objects within connection objects. The use of such object-oriented programming techniques for modeling in equations eliminates unnecessary repetition of similar formulae, imposes a better structure on the mathematical model, and reduces the overall number of equations.
2. Model transformation The user should interactively be able to transform equations and formulae associated with an object, with the help of a computer algebra system. Transformed formulae should be saved within new versions of the objects from which they were derived. It should be possible to specify which variables should be solved for, and which variables are input or output.
3. Choice of numerical solution routines The user should be able to choose between a few builtin numerical solution and optimization routines, obtained from some appropriate numerical library. Specification of, e.g. iteration start values and stop conditions should be supported. All this information should be associated with the appropriate equation object.
4. Generation of numerical code and computation. Formulae and equations produced during the interactive symbolic transformation phase should be used to generate efficient numerical code, e.g. in efficiently compiled languages such as for example Fortran or C++. Code for automatic call of selected numerical routines should be automatically generated.
5. Visualization of results
1. Model specification A machine element object, such as a ring, will have attributes and associated operations. As an example, attributes for a ring are the radius, a formula for parametric definition of the surface of the ring, a formula for elasticity properties etc. Associated operations can for example be to compute the normal vector to the surface of the ring, to compute the volume, or to graphically visualize it on the screen. The programming environment should support the user in defining such objects. In addition, the creation of composite objects, and inheritance of attributes and
Resulting data should be amenable to visualization in two or three dimensions. By using parametric equations for defined objects, this can be obtained, e.g. by calling general 3D graphics routines which accept parametric surface definitions.
ObjectMath - An Object-Oriented Modeling Language and Environment The modeling language ObjectMath has been designed to be a hybrid language, combining object oriented language constructs with a basic computer algebra lan-
Figure 6. The ObjectMath high-level modeling environment on the 200-equation rolling bearing example. The three-dimensional view of the bearing has been automatically generated from equations expressed in ObjectMath.
guage. Rather than inventing yet another computer algebra language, we decided to use an existing language as the computer algebra component. Our choice of Mathematica here is partly motivated by its readable and systematic syntax and language features compared to older languages such as Macsyma, and partly by its support of three-dimensional graphics. One objective behind the design of the ObjectMath language was to be able to represent all relevant mathematical formulae and equations, including vectors, matrices and tensors. Another objective was to be able to group equations together into objects, and support inheritance of equations between classes to permit better re-use of mathematical models. Both of these objectives have been achieved within ObjectMath. The ObjectMath language provides single inheritance. We have chosen to avoid multiple inheritance partly for reasons of simplicity, and partly because we have not yet seen any good applications of it in the examples we have examined so far. Multiple inheritance might however be included in a future version of ObjectMath, if we find some reasonable uses for it. Currently the ObjectMath language does not include a mechanism for enforcing encapsulation. This is because we wanted to keep the language as simple as possible, both to facilitate the implementation of the prototype, and to make the language easy to learn for me-
chanical engineers who do not have much experience in object oriented programming. The next version of the ObjectMath language will include proper encapsulation.
Usage of inheritance ObjectMath has been successfully used to model the rolling bearing mentioned previously. The original bearing model, which is described in detail in [Fritzson,Fritzson-91b], contains approximately 200 equations when expressed in conventional mathematical form. The bearing model, when specified in ObjectMath, (see appendix A), is actually more compact than that, since the use of inheritance has eliminated some unnecessary copying of similar equations. The model size was reduced by a factor of two (from 588 lines to 308 lines) by re-use of equations through inheritance. This is a strong indication of the feasibility of this approach when applied to a realistic example.
Object Oriented Language Features of ObjectMath ObjectMath contains just a few constructs in order to allow for object oriented modeling and programming. Parameterized classes can be defined using the CLASS construct. As mentioned before, conventional single inheritance between classes is allowed. The ObjectMath INSTANCE declaration is in a tradi-
tional sense both a class declaration and a declaration of one instance of this class. This makes the declaration of classes with a singleton instance compact. A similar mechanism exists in the BETA programming language [Kristensen,et.al-87]. Classes implicitly declared in an ObjectMath INSTANCE declaration can be inherited from, just as classes declared with a CLASS declaration. A symbolic array (or set) of objects can be created from one INSTANCE declaration, by adding an index variable in brackets to the instance name. This allows for the creation of large numbers of nearly identical objects, for example the rolling elements in a rolling bearing. To represent differences between such objects, methods that are dependent upon the array index of the instance can be used. The implementation makes it possible to do computations with a symbolic number of elements in the array. In comparison with the concept of prototype using standard object-oriented terminology [Wegner-89], the INSTANCE construct serves as a class, i.e. a template, since class-variables and equations are duplicated at instantiation time, whereas they would have been shared in the case of inheritance from a prototype. Both classes and instances can be parameterized. Parameters to both classes and instances allow equations in the bodies of these declarations to be more generally applicable. In addition to the keywords CLASS and INSTANCE, a MODEL keyword has been introduced to designate whole models.
Naming in ObjectMath In addition to equations and variables, ordinary functions and procedures (=methods) can be associated with an object. Since the Mathematica context facility is used in our implementation of objects, the normal dot-notation for referring to intra-class definitions has been replaced by Mathematica's apostrophe notation for referring to definitions within a class. This can be seen in the example: Coord‘TransPoint[r[Ex][u,v],Ex,WNo[i]], where the TransPoint method within the Coord object is called. One convention that we have used in this model is that each equation within an object is named, e.g. Eq[1], Eq[2], in order to allow reference or application of such equations within other objects. Another naming convention could be Eq[SimpleRing1], Eq[SimpleRing2] for two equations within the SimpleRing class,
which might be advantageous for avoiding name collisions when inheriting equations. Another naming convention in this model is to let the symbol within the first pair of brackets always denote the coordinate system within which the relevant quantity is defined. For example, the quantity r in: r[WNo[i]][u,v] denotes the parametric surface function r of parameters u and v, defined within the WNo[i] coordinate system. Note that these two conventions are not part of the actual ObjectMath language – they just serve to make models more consistent and easier to understand.
Implementation of Inheritance, Classes and Instances Inheritance between classes, and between classes and instances is implemented by copying definitions of equations and other attributes. Only instance declarations actually give rise to generated Mathematica code, which of course contains all equations from classes inherited by the instance. An instance declaration with array brackets will generate one instance of Mathematica code and several data objects. For example, the instance declaration with array brackets: INSTANCE BodyW[i] INHERITS Roller(W[i]) can give rise to several data objects (indexed by i) which can be used during numerical simulation of the model.
Some CLASS examples: The following is an example of a class, which contains four equations that hold for all contacts between bodies. These equations will be inherited by more specialized classes and connection objects. The parameter C denotes the relevant coordinate system; Body1 and Body2 denote the two objects involved in the contact. CLASS GeneralContact(C, Body1, Body2) (* C is a coordinate system name; Body1 and Body2 are objects *) (* Equations *) Eq[1] := Body1‘n[C][u[Body1], v[Body1]] + Body2‘n[C][u[Body2], v[Body2]] == {0,0,0}; Eq[2] := delta * Body1‘n[C][u[Body1], v[Body1] == Body2‘r[C][u[Body2], v[Body2]] Body1‘r[C][u[Body1], v[Body1]]; Eq[3] := Body1‘F[C][Body2] == Body2‘F[C][Body1]; Eq[4] := Body1‘M[C][Body2] == Body2‘M[C][Body1]; END GeneralContact;
The SimpleRing class contains general ring properties, such as parametric surface equations for a ring. A subset of the equations is shown below. These equations are inherited by other objects such as the external ring,
r
( C)
u ∈ [u min,u max] v ∈ [v min,v max]
x(u) ⋅ cos v (u, v) = x(u) ⋅ sin v z(u) u min = 0 v min = 0
Ra + ( Ra − Rb) u Ra x(u) = Ra + ( Ra − Rb) ( 3 − u) R b
1 L 2 3 −L ( u − 2 ) z(u) = 1 − L 2 7 L (u − ) 2
u max = 4 v max = 2π
CLASS SimpleRing(C) (* The C parameter is the ring-centered coordinate system *) ... (* Variables *) Rb; Ra; L; u[min] := 0; u[max] := 4; v[min] := 0; v[max] := 2 Pi;
0≤u 1, M = A[Path[[2]], Path[[1]]] . M; Path = Drop[Path, 1]; ]; Return[M]; ]; (* Function for transforming a point *) TransPoint[p_, S1_, S2_] := Block[{Path = FindPath[S1, S2], M = p}, While[Length[Path] > 1, M = R[Path[[2]]][Path[[1]]] + A[Path[[2]], Path[[1]]] . M; Path = Drop[Path, 1]; ];
Return[M]; ]; (* Safety function for Root. *) Root::undefined = "Root undefined for ‘‘."; Root[x_] := Message[Root::undefined, x]; END CoordinateSystem; INSTANCE Coord INHERITS CoordinateSystem (* Definition of Coord Systems Ex, EG, In, IG, W[i], WN[i], No[i], S[i] *) (* In variables *) Phi$[ExG][Ex][3]; R$[G][ExG][1]; Phi$[InG][In][3]; Phi$[WNo[i_]][W[i_]][3]; Phi$[G][S[1]][3]; (* Other variables *) R$[No[i_]][WNo[i_]][1]; (* Definition of coord system Ex relative to ExG*) Root[Ex] := ExG; Phi[ExG][Ex] := { 0, 0, Phi$[ExG][Ex][3] }; R[ExG][Ex] := { 0, 0, 0 }; R[Ex][ExG] := - TransVector[R[ExG][Ex],ExG,Ex]; A[Ex, ExG] := Rotmat[Phi[ExG][Ex]]; A[ExG, Ex] := Transpose[A[Ex, ExG]]; (* Definition of ... (* Definition of ... (* Definition of ... (* Def. of coord ... (* Def. of coord .... (* Def. of coord ...
coord system ExG relative to G*) coord system In relative to InG*) coord system InG relative to G*) system W[i] relative to WNo[i]*) system WNo[i] relative to No[i]*) system No[i] relative to
S[i]*)
(* Definition of coord system S[i] relative to G*) Root[S[i_]] := G; Phi$[G][S[i_]][3] := Phi$[G][S[1]] + 2 Pi (i-1) / Wn /; i > 1; Phi[G][S[i_]] := { 0, 0, Phi$[G][S[i]][3] }; R[G][S[i_]] := { 0, 0, 0 }; R[S[i_]][G] := - TransVector[R[G][S[i]],G,S[i]]; A[S[i_], G] := Rotmat[Phi[G][S[i]]]; A[G, S[i_]] := Transpose[A[S[i], G]]; Root[G] := Null; END Coord; CLASS SimpleRing(C) (* The C parameter is a name of the ring-centered coordinate system *) (* Variables *) Rb; Ra; L; u[min] := 0; u[max] := 4; v[min] := 0; v[max] := 4; (* Definition of parametric surface *) x1[u_] x2[u_] x3[u_] x4[u_] x[u_] x[u_] x[u_] x[u_]
:= := := := := := := :=
Rb + (Ra - Rb) u; Ra; Rb + (Ra - Rb) (3 - u); Rb; x1[u] x2[u] x3[u] x4[u]
/; /; /; /;
0 1 2 3
