Friday, September 12, 2014

Lab 3: The Non-Constant Acceleration of a Terrorist Elephant

An elephant wearing a rocket pack and futuristic frictionless roller skates could only be an invention out of a dystopian novel. What would the elephant's excuse be to skate around hills using rocket power? Where does it get such equipment? No state in its right mind would sanction rockets to an elephant. The only explanation are IED, or improvised rockets. Which means our elephant is either a terrorist, or it stole them from terrorists armed with frictionless roller skates. Either way, the thought of it is terrorizing.


In this lab, we compare the results of solving a messy calculus problem involving elephants of questionable motivation analytically, or iteratively (or numerically) using Excel, as we have done before. The elephant in question has a mass of 5000-kg, and is rolling down a hill, going 25 m/s when it reaches the bottom and arrives at level ground (remember: ignore friction). Being unable to stop itself, the elephant employs its rockets to fire in the reverse direction, generating a constant 8000 N of thrust. The rocket burns fuel, leaving its mass to be m(t) = 1500 kg - 20 (kg/s) * t.

Find the displacement from the bottom of the hill to when the elephant comes to a stop.

The first step to any such problem analytically is to gather the known variables, then figure out what we need to do head towards a conclusion. Since the elephant and rocket are braced together, it makes sense to treat them as one system, so that the total mass becomes:

mtot(t) = 6500 kg - 20 (kg/s) * t

We also know that the final velocity will be at a standstill, while the initial velocity is given, as such:

v = 0 m/s
v0 = 25 m/s

Finally, since horizontal movement isn't typically acted on by any force, the only force in the picture comes from the rocket, firing in the opposite direction as the elephant's movement, therefore:

Fnet = -8000 N

Looking at the pieces we have, there seems to be two possible relations to make: power and momentum, and Newton's Second Law. The latter is more familiar to us at this point, so we have:

F = ma
a = F / m

At this point, the plan is obvious. With acceleration, we could take 2 integrals and get the position:

a(t) = Fnet / mtot(t) = -8000 N / (6500 kg - 20 (kg/s) * t)

Divide by 20 to get:

a(t) = [-400 / (325 - t)] m/s2

Integrate from 0 to t with the given v0 as the constant C. From this point, we do a series of calculations that is, frankly, too difficult to type neatly in a blog. Thankfully, Professor Wolf has generously provided the calculations. Hooray!


So after a flurry of numbers, the answer appears like a magic number crashing through the heavens. Behold: 248.7 m!

To be sure, although math is a huge part of physics, the purpose of this lab is not merely to demonstrate prowess in manipulating numbers, but to further reinforce how to use the iterative (numerical) process to model analysis, and let the data lead the way. Despite this being a relatively difficult calculus problem to solve on our level, the real world is much more complex, with much more known and unknown variables that make it exceedingly hard to predict everything deductively. Thus, it is necessary that we get used to modeling with data and finding approximate solutions. To do this, we open up trusty Microsoft Excel, again on the company's arch-nemesis, an Apple computer. This dichotomous combination seems to capture the worst of both sides.

Although we did this in class with Excel, I am posting pictures of Apache OpenOffice Calc from a personal computer, since I had neglected to collect all the relevant data. It is important to keep as many variables as possible when modeling, and avoid magic constants, so that we could tweak values and let the spreadsheet formulas reflect them automatically. In this experiment, we create 7 columns, for each variable, and define each of them with formulas that relate them to each other. Then we could change the time interval, for example, and see how the data changes.


We begin with an 0.1 s interval. We want to find the distance before the elephant stops, so in numerical terms this is the distance x when the velocity v reaches 0 m/s. Since these values are based on calculations of acceleration and time, they will not reach 0 m/s perfectly; we compensate by finding the row corresponding to a v closest to 0 m/s.


Here, at a v reasonably close to 0 m/s, the distance x is 248.697 m (taking more than significant digits to make a point). But what if we increase the time interval 1.0 s--how will the data look?


We can see that with a larger time interval, while the data is less accurate (our v is further from 0 m/s), we are able to see our result within 20 rows of data. Here, our distance is 248.379 m, which is further than our analytic ideal. That means that by decreasing our time interval, to say 0.05 s, we should be able to get a better answer, right?


Notice here that our v is closer to 0 m/s still, but it doesn't affect the x that much more--248.699 m as opposed to 248.697 m! The downside is that it requires 395 rows of data as opposed to 197. There is always a tradeoff in experiments when it comes to practicality versus accuracy. A spreadsheet running on 64-bit architecture could conceivably run tens of thousands or more rows of data, but once again the real world is much more complex, and accuracy increases costs in equipment, as well as time eliminating sources of uncertainty. It would be useless to articulate minute differences if much of it is caused by error. So the way we can tell how much accuracy we need is to note the uncertainty in the problem. We then manipulate the time interval such that the value v is within the standard deviation of the ideal value, in this case 0 m/s. We note that even with 0.1 s time interval, if we round the x we get, it becomes the same as the analytical answer of 248.7 m. Therefore, 0.1 s should have been sufficient, but not 1.0 s, which would have yielded 248.4 m. By getting a good grasp of the accuracy needed, we save both time and money--two things we need the most!

No comments:

Post a Comment