DRAFT: January 31, 2000

An Object-Oriented Approach to Basic Mechanics

David M. Auslander Mechanical Engineering University of California at Berkeley dma@me.berkeley.edu

Abstract
An approach is suggested for a methodology associated with basic mechanics that greatly enlarges the scope of problems accessible to students and professionals. A numerical approach based on Newtonian point-mass mechanics and pseudo-rigid bodies brings problems such as three-dimensional dynamics and constrained motions into the arena of basic mechanics. Because solutions of almost any problems of interest require computation, integrated study of physics, math, and computation is essential. An object-oriented computational approach is extremely useful since all models can be expressed with the same set of basic elements.

Introduction
Basic mechanics is defined as the material associated with the mechanics of rigid bodies that is presented to students in the last two years of high school through the first three years of college. Some of the material is presented in physics courses and some of it in engineering courses. Basic mechanics is important for engineers because it: Forms the basis for the study of advanced mechanics, Forms the basis for a number of engineering application areas, Establishes the pattern by which engineers approach problems involving mechanics. The last of these points is important in engineering practice because easy problems are generally defined as those that can be solved using material generally classified as basic mechanics. The purpose of this paper is to reexamine basic so as to increase the scope of problems considered easy. The starting point for this reexamination is the following two questions: 1. What is the purpose of the basic mechanics curriculum? 2. What is the appropriate role of computation in formulation of the curriculum? While these questions themselves are subjects for considerable debate, answers to them are proposed as a means of guiding this study. Different answers would, of course, lead to different approaches to basic mechanics -- indeed, even the same answers could lead to different approaches. The proposed responses are: 1. The purpose of the basic mechanics curriculum is to equip engineers with tools enabling them to solve the broadest possible class of problems.

DRAFT: January 31, 2000 2. Computation is central to the professional activities of engineers. Integration of computing methodology with the engineering science curriculum is highly desirable. The first answer, the purpose of the basic mechanics curriculum, is very pragmatic. The reasons behind the choice are both professional and historical. Professionally, engineers use physics and related engineering science subject areas to allow them to predict the behavior of actual or potential products for the purpose of improving the performance of those products. Thus, the broader the range of problems they can solve, the more effective they will be at that aspect of their engineering work. The present mechanics curriculum shows signs of the same pragmatic approach. Its antecedents go so far back that, at this point, it is hard to separate pragmatism from fundamental material. A reasonable case can be made, however, that most of the current basic mechanics curriculum consists of a set of techniques that allow solutions to be obtained for certain special cases in the absence of a computer. In pre-computer times, therefore, a student would be as well equipped as possible to solve problems in mechanics. While integration of computation with the curriculum sounds good on the surface, it brings up the following controversial issue: Is it reasonable to design a curriculum that depends almost entirely on computation to obtain solutions? This question will certainly be answered in the negative by a substantial number of engineering educators. However, this paper is based on an affirmative response. The rationale is that very few problems of modern practical engineering importance can be solved without a computer. Computer-based solution techniques can be justified if they broaden the scope of problems that can be solved. The approach to mechanics proposed here starts with the assertion that there are two fundamental topics to be covered: 1) kinematics, and 2) Newtonian mechanics. Kinematics establishes the concepts of position, velocity and acceleration in the common three-dimensional space. Newtonian mechanics describes the connections among inertial, point-mass bodies, forces and kinematics. All material beyond this represents techniques that allow these fundamental principles to be used to solve problems of practical importance. The method chosen, for its generality, is to treat all mechanical bodies as pseudo-rigid. That is, mechanical bodies are modeled as collections of point-masses connected by springs (and, possibly, dampers) that are very stiff, but not infinitely stiff. The stiffness must be high enough to maintain the mechanical integrity of the body to some desired tolerance. Bodies modeled this way can be connected to other bodies or to constraints to solve mechanical system problems. Problems formulated in this manner can be solved as initial-condition ordinary differential equations (ODEs). Each mass contributes six states to the system equation (that is, six first-order ODEs -- for position and velocity in x, y, and z). While the use of pseudo-rigid bodies as a modeling technique is not new, it is proposed here as a unifying methodology for basic level mechanics. Point-mass modeling can be used to solve a huge variety of problems in rigid body mechanics, including three-dimensional dynamics, constrained motions, rotational motions, etc., all within

DRAFT: January 31, 2000 the context of solving sets of first-order, nonlinear ODEs. The solution is only practical using computer methods because of the large number of equations generated even by relatively simple systems. However, the scope of problems that can be solved covers many areas currently considered advanced. The trade-off for this generality is the need to understand and carefully apply error analysis to the results. Because of the stiff springs, the ODEs are mathematically relatively stiff so choice of solution method and error control can be quite important. A second layer of error is introduced because of the pseudo-rigid model (i.e., how stiff is stiff enough?) Because point-mass models of rigid bodies are all constructed from a small set of primitive elements, masses, springs, dampers, an object-oriented approach to computational implementation is natural. The object-oriented approach is efficient because models are built from pre-defined elements and those elements can be extended to account for situations not anticipated at the time the original software base was created. The extensions themselves use the same syntax as the original model elements so, if well designed, are also reusable and appear to subsequent users as no different than the original library of modeling elements. Because the method of constructing computational models is well defined, it is as effective for the development of automated or semi-automated modeling software as it is for direct model construction in the base language. At the lowest level, classes are defined for masses and for connectors. Connectors include both springs and dampers. Modelers, however, interact with a more abstract class representing rigid bodies. Each of these elements contains a collection of masses and connectors. The rigid body abstraction is important because it allows for underlying models to be changed without changing the application code.

Motivation
The notion that a reexamination of the basic mechanics curriculum was warranted came from experience with a freshman seminar titled Animating Physics. The purpose of this seminar was to offer an attractive experience that would parallel and integrate material from math, physics, and computation courses. The theme of the course was the production of physically realistic animations, that is, animations in which the motions of the objects obeyed the laws of physics (http://euler.Berkeley.EDU/~dma/res.html, then follow links to ME39E, Animating Physics). The prerequisite was high school physics (calculus was not required). Figure 1 shows a typical student project from this class. This is the opening graphic that was animated. The animations were all two-dimensional, done completely in Matlab. A graphics-animation package was supplied that allowed students to concentrate on the basic pictorial description of their problem (circles, rectangles, shapes made of multiple lines) and the computation via simulation of successive positions, shapes, colors, etc. Figure 1. Student Project: Newton's Cradle (see the above-mentioned web site for copies of the sample software). Students were responsible for all of the programming involving

DRAFT: January 31, 2000 the physics of their specific problems. The programming was done using Matlabs standard procedural language. The course was successful as a seminar in several ways: It did interest students. Animation was a theme that people could identify with and understood immediately. Students dealt with integration of math, physics, and computing in a natural way. It was very clear that such integration was necessary to produce an animation. It explored the role of extended projects in engineering science instruction. Students picked problems with significant complexity and were not afraid of nonlinearities or system configuration changes. Despite the successes of this seminar, several disturbing factors emerged. Two were particularly influential in motivating a complete reexamination of the physics curriculum: Students were notably unprepared for dealing with a numerical approach to problem solving. There were a number of interesting problems for which they had no useful formulation tools, particularly problems involving simple constrained motions. The numerical approach to problem solving in physics was clearly alien to these students. They seemed to feel that all solutions should be expressible as closed-form expressions for position. They also had no experience with anything but the special case problems (constant velocity, constant acceleration, etc.) for which formulaic results are available. Since students selected their own projects, a large variety of physical situations were represented. Some of these used physical configurations for which none of the solution methods available to students at this level were applicable. A good example of a problem of this sort is the double pendulum. The single pendulum is discussed in all basic physics classes, but the solution used is not generalizable to a double pendulum.

A Numerical/Computational Approach
The work in the Animating Physics seminar strongly suggested a numerical approach to mechanics. However, an examination of the current curriculum is not encouraging. Because a substantial part of the curriculum is devoted to special cases for which analytical solutions can be obtained, it does not seem that a numerical approach would add much. Adding numerics to the existing curriculum might allow for introduction of some nonlinearity, but would not expand on the scope of problems that could be solved. An alternative is needed! The current curriculum can be viewed in three parts: kinematics, Newtonian point-mass mechanics, and special cases of problems that can be solved without a computer. If a suitable methodology can be found, an attractive approach would be to keep the first two topics because they represent fundamental physical phenomena and eliminate the special cases. Such an approach is discussed below.

DRAFT: January 31, 2000

Kinematics
Basic kinematics describes motion in the normal Euclidian three-dimensional space. Decomposition of the motion into orthogonal components is a key element. Most of the actual numerics in solving mechanics problems is in the kinematics. All problems are viewed incrementally, with acceleration or velocity given and position (and velocity, if necessary) calculated by accumulation. Finite accumulation is used rather than the integral or differential equation formulation to allow introduction of this material before calculus. This order should actually help the calculus courses because it would add motivation and relevance to the calculus material. The basic Euler formulation for numerical solution of differential equations is used to introduce incremental kinematics,
v(t + t ) = v(t ) + a (t ) t x(t + t ) = x(t ) + v(t ) t

Eq (1) Eq (2)

This form makes intuitive sense and is easy to explain and implement. It can be used either for evaluation of integrals or for differential equations. It can be applied to orthogonal components or to motion along a path. Understanding the use of this formulation is the key to the numerical approach. Newtonian mechanics will be used to calculate accelerations for a system of bodies. These kinematic relations are then used to calculate the actual velocities and positions. An example of this approach is the problem of motion along a prescribed path. This problem, and several variants of it, is used as a theme problem for the sections that follow. It is typical of problems that students can work on using the approach described here. It uses the numerical/computational approach to generalize well beyond the types of problems that can be solved using the current curriculum. However, the programming involved requires student intensity that is beyond that of the current curriculum also. In this case, the problem is stated in terms of velocity. That is, the velocity and the nature of the path are specified. The objective is to calculate the position of the object as a function of time. Only the second of the Euler forms, for position, is needed for this problem. The general method of solution is to compute how far the object will move along the path for the current time increment, then use a search algorithm to find the point on the path the given distance from the current point. The search is a one-dimensional search with the angle from the current point as the search variable. As an assignment, this problem has a number of interesting aspects. In addition to exploring the kinematics of a velocity-specified problem, there is the issue of how to do a search (i.e., solve a general one-dimensional nonlinear equation). A number of simple problems can be given initially, such as straight lines and circles. These problems are also solvable analytically, if desired. Figure 2 shows the result for a circle. The X and Y positions versus time show the familiar sinusoidal shapes and the swept angle increases proportionally with time.

DRAFT: January 31, 2000

2 1.5

2.5 x y 2 0.5 0 0 5 tim e 10 1.5 0 5 tim e 10 2.5 y 0 5 tim e 10 2 1.5 0.5 1 x 1.5 1

800 600 angle(deg) 400 200 0

Figure 2 Following a Circular Path with Specified Velocity

Unlike the analytical result for a problem of this sort, the numerical solution is fully generalizable. For example, the velocity along the path may not be a constant, Figure 3.
2 1.5 1 0.5 0 0 5 tim e 10 3 2.5 2 1.5 1 0 5 time 10

800 600 angle(deg) 400 200 0 0 5 tim e 10

y y

2.5

1.5 0.5 1 x 1.5

Figure 3 Motion on a Circular Path: Varying Velocity

On the other hand, the path might not be circular, Figure 4. In this case, though the velocity along the path is also constant, the X and Y positions of the object versus are not even vaguely sinusoidal, nor does the swept angle vary linearly with time.

DRAFT: January 31, 2000

3 2

2.5 x y 2 0 -1 0 5 time 10 1.5 0 5 time 10 3 300 angle(deg) 200 100 0 0 5 time 10 0 1 x 2 2.5 y 2 1.5 1 1

400

Figure 4 Motion on an Elliptical Path with Specified Velocity

The program that created these results was written in Matlab. The portion of the program where the primary material of the problem is located is quite small (and consists mostly of copying output values and comments),
for t = 0:DeltaT:TFinal % Copy output values i = i + 1; tt(i) = t; yy(i,1) = x; yy(i,2) = y; yy(i,3) = ang; % Compute the current velocity velcur = vel + velvar * sin(velfreq * t); % Compute distance to move based on velocity d = velcur * DeltaT; % Find point on path at this distance - uncomment whichever is %in use (make sure to change Fxy accordingly!) %[x,y,ang] = FindPoint(circ,x,y,d,ang); [x,y,ang] = FindPoint(ellipse,x,y,d,ang); end

As a student project, much of the interesting work is buried in the FindPoint() function. This is where the search takes place. Some studies of error control would be a crucial part of any work with the program. At a geometric level, chordal steps approximate the motion on the path. Thus the distance traveled is in error. That error can be explored by varying DeltaT and comparing computed travel distance (the computation of travel distance isnt shown in the code above, but is a simple addition). The search algorithm is another rich source of exploration (a simple variant of a one-dimensional simplex search is used in this program).

DRAFT: January 31, 2000 Construction of the entire program would be a significant project for students somewhere in the first quarter of a unit on mechanics. This is typical of the pedagogical question relating to use of extended projects in the engineering science curriculum, is the time a student would need to construct this program worthwhile? While a full answer to this question is well beyond the scope of this paper, some relevant points can be made: in order to complete such a project a student would have to integrate knowledge from several subject areas and he or she would have an experimental vehicle to carry out a variety of experiments in kinematics. The program could also be reused in subsequent units. For example, it would only take changes in a few lines of the code to convert the problem from a velocity specification to an acceleration specification.

Point-Mass Mechanics
Newtons laws provide the means of relating forces and masses to kinematics. For constant mass problems they give a direct connection to acceleration. For numeric purposes, it is much better to always posit the relationship in terms of momentum. Then problems with varying mass can also be solved, although students will almost always take the F=ma shortcut because there are relatively few varying mass problems (maybe the y2k computer bug could have some influence here!). Newtons laws also define an inertial reference frame that establishes some of the limits of validity of the Newtonian approach. By adopting a numeric approach, a wide variety of point-mass problems can be solved. The circular motion kinematics example can be modified to produce a problem of constrained motion of a point-mass object. The problem consists of a vehicle moving on a track of specified shape driven by a force that is always in the direction of motion. The vehicle is modeled as a point mass. As before, the numerical approach allows for any shape of track to be used. The constraining force can also be computed. Most of the kinematics sample program remains the same. The core code is modified to calculate acceleration on the basis of the force applied to the vehicle. The constraining force is approximated from the change in velocity in the direction orthogonal to the motion. The core Matlab code is:
for t = 0:DeltaT:TFinal % Copy output values i = i + 1; tt(i) = t; yy(i,1) = x; yy(i,2) = y; yy(i,3) = Fconstraint; % Acceleration along the path if t < TimeOff, f = force; else f = 0; end accel = f / mass; % Compute the current velocity vel = vel + accel * DeltaT; % Compute distance to move based on velocity d = vel * DeltaT; % Find point on path at this distance - uncomment whichever is %in use (make sure to change Fxy accordingly!) %[x,y,ang] = FindPoint(circ,x,y,d,ang); [x,y,ang] = FindPoint(ellipse,x,y,d,ang);

DRAFT: January 31, 2000

% Compute constraining force dAng = ang - AngPrev; AngPrev = ang; Fconstraint = vel * sin(dAng) / DeltaT; % Change in othogonal velocity end

The problem is set up with the vehicle initially at rest. The force is applied for a specified time, and then the vehicle is left to coast (with no friction). The results are shown in Figure 5 for circular motion. The lower left graph shows the constraining force. It builds with time as the vehicle speed increases, and then becomes constant as the vehicle coasts at constant velocity along the path.
2 1.5 1 0.5 0 0 5 tim e 10 1.5 0 5 time 10 2 2.5

500 2.4 400 Fc ons traint 2.2 300 200 1.8 100 1.6 0 0 5 tim e 10 0.5 1 x 1.5 y 2

Figure 5 Point-Mass Vehicle on a Circular Track

For elliptical motion, Figure 6, the same two changes are made as in the kinematics example. The constraining force is dramatically different than in the circular motion case.

DRAFT: January 31, 2000

3 2 1 0 -1 0 5 tim e 10

2.5

1.5 0 5 tim e 10

1500 3 Fc onstraint 1000 y 500 0 0 5 tim e 10 0 0.5 1 x 1.5 2 2.5 2 1.5 1

Figure 6 Point-Mass Vehicle on an Elliptical Track

There are always interesting error analysis issues with numerically produced results. In this case, the tolerance specified in the search for the correct point on the path shows up in the calculation of the constraining force. Since that calculation, in effect, differentiates the vehicle-heading angle, small errors in computation of the angle can be magnified. Using smaller step sizes for the integration will magnify that effect further, giving a good example showing that smaller is not always better in step size. In these cases, although not very much has changed in the code, a full differential equation is being solved. To the student, however, it appears in a very natural way as an extension of the kinematics material.

Pseudo-Rigid Elements
While the above solutions display considerable generality in terms of the way that the vehicle is driven, the shape of the track, etc., the formulation of how the constraint is applied and how the constraint forces are calculated is largely ad hoc. A much more consistent formulation can be based on the use of pseudo-rigid elements. In this case, a spring is attached between the mass representing the vehicle and a point that can move along the specified path (Figure 7, not to scale!) In order to compute the spring force, the moveable point is first positioned along the path such that the distance between that point and the vehicle mass point is minimized. The spring force calculation then proceeds. If the spring constant is made very high, but not infinite, it will act as a constraining element that guarantees that the moving mass is always within a reasonable tolerance of the constraining path (the rest length of the spring is set to zero).

10

DRAFT: January 31, 2000

Path

Moving reference point Spring

Point-Mass object

Figure 7 Pseudo-Rigid Constraint to a Path

Whereas the earlier solution was an ad hoc one-dimensional solution based on motion along the path, this is a general solution of a two-dimensional problem. No special solution techniques are needed to solve the problem. The force on the mass from the spring is computed according to the normal rules for computing such forces. The constraining force is just the force in the spring. No special computation is required to determine the constraining force. The shape of the path is unique to the particular problem being solved, and a method must be provided to find the point on the path nearest to the current position of the moving mass. These are general techniques, however, and are useful in a wide variety of other problems. The solution is easily generalized to three dimensions, for example. The description of the path and the solution of the }nearest point problem become more difficult, but nothing really changes. The primary Matlab code for this problem is below. It still uses the Euler solution method, however, this case might be a good stepping-off point for examination of other ODE solvers because of the stiffness of the resulting equations.
for t = 0:DeltaT:TFinal % Copy output values i = i + 1; tt(i) = t; yy(i,1) = x; yy(i,2) = y; yy(i,3) = Fconstraint; %sqrt(vel * vel.'); % Spring force %xp = NearestPointCircle(circ,x,y); % Find the point on the circle % nearest to (x,y) -- This is an example of how to save computing time % by taking advantage of special cases. xp = NearestPoint(PathIndex,path,x,y,xydir(ang),tol); L = [x y] - xp; Ls = sqrt(L * L.'); ang = Fslope(PathIndex,path,xp(1),xp(2),ang); if Ls == rs, Fsp = [0 0]; Fs = 0; else Fs = ks * abs(Ls - rs); Fsp = (L / Ls) * Fs; end

11

DRAFT: January 31, 2000

Fconstraint = Fs; % Force on mass if t < TimeOff f = force * [cos(ang) sin(ang)]; else f = [0 0]; end % Compute the current velocity Mom = Mom + (f - Fsp) * DeltaT; % Update momentum %disp([ang*180/pi atan2(vel(2),vel(1))*180/pi f Fsp Ls*ks]); vel = Mom / mass; % Convert to velocity % Compute distance to move based on velocity xnew = [x y] + vel * DeltaT; x = xnew(1); y = xnew(2); end

Note that in this case the mechanics computation is based on momentum rather than acceleration, as was the case for the previous example. The solution for the elliptical path is shown in Figure 8. The obvious price paid for the increased generality of the solution method is in computing time. As a note on generality, the method used for this problem easily solves the double pendulum problem. There are also several different error control issues raised in this case. An interesting question, probably raised by an error control issue, is left as an exercise for the reader: why are the peak values of constraining force higher in Figure 8 than they are in Figure 6? A more important question: are those peak values to be believed?
3 2 1 0 -1 0 5 tim e 10 3 2.5 2 1.5 1 0 5 tim e 10

1500 3 Fc ons traint 1000 y 500 0 0 5 tim e 10 0 1 x 2 2.5 2 1.5 1

Figure 8 Elliptical Track: Pseudo-Rigid Constraint

12

DRAFT: January 31, 2000

Rigid Bodies
One step takes the methodology in the previous section, which applies to the solution of problems of the motion of constrained point-masses, to the much broader domain of rigid body dynamics. A rigid body can be thought of as a set of point masses connected by rigid, massless rods. In the spirit of the previous problem, those rods represent constraints on the distance from each point-mass to its neighbors. If, for computational purposes, those constraints were replaced by pseudo-rigid, massless springs, it would appear that problems in rigid body dynamics could be solved by the same computing methodology that was used to solve the point-mass on a path problem. This is exactly the case. Thus, having arrived at this point, the fundamentals of mechanics are complete! As an illustration, consider a solution to a problem in basic gyroscopic motion. Figure 9 shows a schematic of a simple top. When placed as shown, it will fall over if it is not spinning. If it is spinning rapidly enough, it will balance. This is a problem in three-dimensional dynamics, which is not accessible to students who have studied basic mechanics but that could be solved by such students (or practicing engineers) using the point-mass approach.

Figure 9 A "Top"

Figure 10 is a point-mass representation of the top. The disk is modeled as a set of three point masses with pseudo-rigid connections. The rod balancing the disk is modeled by three more pseudo-rigid connections that constrain each of the masses to be a fixed distance from a fixed pivot point.

13

DRAFT: January 31, 2000

Figure 10 PointMass Representation of a Top

Figure 11 shows the simulated behavior of the top. A small transverse initial velocity is introduced as a disturbance. The upper graph gives the X and Y locations of the center of the disk and the lower graph has the X location of one of the masses, all as a function of time. The center point motion shows the precession of the top while the outer edge X location shows the spinning motion.

0.4

Center X & Y

0.2 0 -0.2 -0.4 0 1 0.5 1 2 3 4 5 6 7 8

Edge X
0 -0.5 -1 0 1 2 3 4 5 6 7 8

Figure 11 Simulated Motion of Top

It is important to note that the solution to the top problem involved nothing more than the kinematics and Newtonian point-mass mechanics already introduced. This is a problem including both three-dimensional dynamics and constrained motion. In addition to the questions of error analysis noted previously, a couple of new issues are raised with this problem. One of these is the representation of a rigid body. The top is described as a disk on a massless supporting rod. The disk is represented by three point-masses. How is this justified? There are two approaches to rigid body representation. One is to position an arbitrary 14

DRAFT: January 31, 2000 number of point masses in approximately the locations of the actual mass. The approximation is deemed to be adequate when the result does not change significantly with the addition of more masses. Appealing to rigid body theory however, it can be shown (XXXX ) that it takes at most four masses to represent a rigid body. As long as the principal moments of inertia match the pseudo-rigid body representation retains all of the dynamic properties of the original object. For degenerate objects, such as a disk, fewer masses are needed. This is a good example of how the introduction of appropriate theory can make the numerical representation much more efficient. A second issue in complex systems, particularly with three-dimensional motion, is the description of the resulting behavior. The problem was sidestepped in this case by using Cartesian coordinates of different places on the object. Some kind of rotational angle system is needed in most cases, however. Unfortunately, except for direction cosines, all of the angle systems contain singularities. Direction cosines do not have any singularities but, with nine values, are not very convenient! Angular representations are not necessary for the basic system simulation but can be important, for example, if there is a force that follows the orientation of an object (typical in propulsion, jet engines, rockets, etc.). Angles, however, are often very important in behavioral visualization. A number of angle systems are in common use rollpitch-yaw, azimuth-elevation-range, Euler angles, etc. It seems likely that a choice must be available for visualization but a single standard may be important for simulation.

Computing Considerations
It only takes a few examples to realize that constructing models from scratch using point-mass methodology can get very tedious indeed! The number of components goes up very rapidly and each mass contributes six state equations. Keeping track of all of the correct directions and sign conventions can be a major headache. Object-oriented computing should keep this problem in check by burying those details into the class structure from which specific models can be constructed. The fact that regardless of the nature of the bodies used in the modeling, the underlying computation always sees nothing but a cloud of masses, springs and dampers makes object-oriented computing very attractive. In fact, while the path-following examples were constructed from scratch using Matlab, the top gyroscopic example was built using a semi-object-oriented Matlab infrastructure. The code makes heavy use of Matlab version 5s data structures, but does not use its class structure. Defining the disk uses the following code sequence:
DiskMass = 0.75; % Total mass of disk DiskDiameter = 2; % Diameter of the uniform disk (point masses will % be located so as to match the moment of inertia to that % of the uniform disk c0 = [0 0 0]; % Coordinates of the initial center position [Masses,Springs,Disk1] = CreateUniformDisk(... DiskMass,DiskDiameter,c0,Masses,Springs);

The variables Masses and Springs are the lists of masses and springs. The call to CreateUniformDisk() adds appropriate elements to those lists to create a model for the specified disk.

15

DRAFT: January 31, 2000 The disk is then constrained to a fixed point to create the top by adding pseudo-rigid springs as connections:
kspr = 1; cnflag = 1; % These are dummy constraint springs GroundPt = [0 0 -2]; % A point on the z axis for i = 1:3 % Constraints to all three masses [Springs,ifix] = AddFixedEndSpring(Masses,Springs,i,... GroundPt,kspr,cnflag); end

The basic calculation in the right-hand side function used for the ODE solver calculates all of the spring forces and uses those to compute the derivatives of the momentum terms,
MM = InsertStateVector(MM,x); % Update Mass information % Compute the spring forces in all of the springs SS = SpringForce(SS,MM); InitFlag = 1; MM = SumSpringForces(MM,SS,InitFlag); % Sum spring forces (2nd argument % zeros the forces before summation, 0 would add to the % existing values) % Additional forces can be added after this has been done InitFlag = 0; % For any additional forces, sum with previous entries MM = GravityForces(MM,MiscPar.Gravity,InitFlag);

What is important to note here is that the calculation is completely general. It is independent of the details of the application because all applications are just collections of masses and springs (the variables MM and SS are the same as the Masses and Springs used above). Unless there is some unique calculation such as a control or other input of some sort, the same right-hand side function can be used with many applications. Before pursuing this Matlab approach too far, however, it became obvious that it wouldnt work satisfactorily. The major problem was computing time. Because Matlab is interpreted, it is to be expected that its compute times will be long but not as long as was observed for the samples used (including the gyro-top). The probable problem is associated with the use of data structures (MM and SS are data structures). Because Matlab has neither pointers nor references, every time a data structure is passed into a function, modified, and passed back, the entire data structure must be copied into fresh memory several times. This is very time consuming and generates a large amount of memory thrashing. For this reason, the Matlab code was not completed and is not available for distribution. To get a more computationally efficient environment, a C++ version was created. It followed much of the structure of the Matlab version, but used a full class-based approach and added another object layer. As before, objects were defined for masses and springs and lists were created to manage them. In addition, a class was defined for a body. This was absent in the Matlab version. As can be seen from the code above, keeping track of bodies is up to the programmer. The advantage to defining a class for bodies is that many general-purpose operations can be defined that pertain to bodies. The general design is that in most cases the

16

DRAFT: January 31, 2000 programmer putting together a model of a physical system will deal only with body elements and will not have to manipulate the internal masses or springs at all. The C++ approach succeeded in increasing the computation speed considerably (100-fold or more). The downside to this switch is the loss of all of Matlabs mathematical and graphical facilities. Unless quality distributable libraries for C++ can be located these facilities must be replaced locally. The sample below uses locally produced libraries for the ODE solver, matrix functions, etc. The example of a single pendulum shows quickly how the C++ software works. The main difference from the Matlab software shown above is that all references are to bodies rather than to masses and springs. To set up the pendulum problem a body consisting of a single mass is created for the bob and a second body is created for the pivot point,
CPointMass *PendulumBob1 = new CPointMass(MassList,BodyList,SurfaceList, MassBob1,p1,v1,"Bob1"); CFixedPoint *Pivot = new CFixedPoint(MassList,BodyList,SurfaceList, pivot,"Pivot Point");

The SurfaceList allows for the definition of surfaces associated with the bodies (something that could not be done with the mass-spring orientation). This can be important for collisions, bodies that slide or roll, etc. The surface facility is not yet highly developed. The pendulum bob is constrained to the pivot point by,
double bc[3] = {0.0,0.0,0.0}; // Location of bob mass in body coordinates PendulumBob1->ConnectToConstraint(MassList,ConnectionList,Pivot,bc,kspr1,kdmp1);

Computation is even more compact than in the previous case. The generic right-hand side function for the ODE solver is:
void CSystemODE::GetRHS(double t,double *x,double *rhs) { // This is the real version CopyFromStateVector(x,Masses); // Copy current state // information to the mass information ComputeConnectionForces(Connections); // Compute the // internal forces due to springs and dampers SumMassForce(Masses); // Zero forces on each mass and // add in all forces from connecting elements AddGravityForce(Masses,Gravity); ComputeRHS(rhs,Masses,nStates); }

Most of the other code needed to set up a solution sets parameter values, determines output for writing to a file, establishes the connection to the ODE solver, etc.

17

DRAFT: January 31, 2000 A difference between this example and the traditional pendulum example is that this one works in three dimensions. An interesting problem is finding the correct initial velocity so that the pendulum moves in a circle at constant height.
2 1 0 -1 -2 0 5 tim e 1 -1.8 0.5 y 0 -0.5 -1.84 0 5 tim e 10 15 -1 -1 -0.5 0 x 0.5 1 10 15 2 1 0 -1 -2 0 5 time 10 15

-1.82

Figure 12 Single Pendulum: Motion in a Horizontal Plane

Figure 12 shows a nearly correct solution. The top graphs show the x and y motions as a function of time; the lower left graph shows the z motion and the lower right shows the projection of the pendulum motion onto the XY plane. The z motion is limited to about +/- 0.01. The buzz in the z-motion graph is the oscillation due to the compliance of the spring constraining the pendulum to the pivot. That can be reduced at the expense of increased computing time by increasing the stiffness of that spring. An incorrect solution is shown in Figure 13.

18

DRAFT: January 31, 2000

2 1 0 -1 -2 0 5 tim e -1.7 -1.8 -1.9 -2 10 15

1 0.5 0 -0.5 -1 0 5 tim e 10 15

y y 0 5 tim e 10 15

0.5

-0.5 -2.1 -1 -0.5 0 x 0.5 1

Figure 13 Single Pendulum: "Incorrect" Initial Velocity

This problem is interesting because it introduces the beginnings of gyroscopic motion using only a single point-mass and a constraint. Once the pendulum is set in motion revolving around the zaxis it is very stable in that motion. The faster it revolves, the more stable it is. It also shows that a more general approach to a standard textbook problem leads to interesting and complicated problems arising from a relatively simple physical system. As a student exercise it could be a good vehicle for relating simulation to problem solution and analytic techniques. The solution above was found by trial-and-error. However, a faster route to the solution would be to look at the constraining force on the pendulum and realize that the solution is reached when the z-component of the constraining force exactly equals the gravity force. This force is easily obtained from the simulation. Because the motion is circular, the required velocity can also be computed directly from the acceleration needed to keep the pendulum in pure horizontal motion.

Conclusions
As shown by the examples, the point-mass approach to mechanics can be used for problems that are far beyond the scope of current curricular material. Further, an object-oriented computational approach seems essential for all but the simplest problems. Otherwise the internal bookkeeping complexity could quickly overwhelm any attempts at rational software design. These observations support the initial hypothesis that a base-zero re-examination of the mechanics curriculum is warranted. The material seems ideally suited to an integrated approach, including computation, modeling, and mathematics with the physics. Modeling seems an especially important addition here. Modeling explores the connection between the computational physics and the real-world systems the physics purports to represent. The ability to handle more realistic systems means that the modeling has a broader purview in which it can be applied. In any case, though, good attention to modeling in an academic context is very difficult. One area of mathematics that is clearly emphasized in this work is trigonometry. Beyond that, subjects like interpolation, curve-fitting, matrix manipulation, solution of linear and nonlinear equations, ODE 19

DRAFT: January 31, 2000 solvers, and others all play a role. How much is exposed and how much is hidden of these subjects is a curricular decision. The computational component brings up other issues. While some early preliminary work can be done in a friendly environment such as Matlab, the need for efficient computing pushes the work very quickly to a compiler environment such as C++. Learning C++ (or an equivalent) would absorb a substantial amount of time at the late high school-early college level. Such languages are not usually the vehicles for personal computing, as is used here for the solution of problems in physics. On the other hand, one objection to C++ or the like, the turnaround time for compile-link-execute, is no longer a problem. Modern compilers, with incremental compilation, can handle a small change in source code and start a new computation in a few seconds. Thus, using the main() routine of a C++ program as a working space for manipulating a simulation is entirely practical. Students took very well to animation, so its use as a visualization tool for solutions could be an excellent way to tie many aspects of the experience together.

20