My kids’ new favorite game is Outfoxed.  Everyone works together to try to identify the fox guilty of stealing a pie.  Sort of a mash up of Clue and Guess Who.

In order to make either of two moves (find a clue or reveal suspects), a player has to roll three dice and have them all come up “eyeballs” (for suspects) or “paw prints” (for clues) — each six-sided die has 3 of each, so 50/50 chance to roll either.  You have to decide ahead of time which set of three you’re trying to roll, and you get three chances to get all three.  After each roll, you can set aside any dice that are what you’re going for; subsequent rolls only involve the remaining dice.

It wasn’t obvious to me at the outset how hard it would be to successfully roll, but after playing for a little bit, it was pretty clear that you were more likely to be successful than not.  So I wanted to try to figure out how the odds were stacked.  The rolling scheme is sufficiently complicated that I couldn’t figure out any sort of clever solution, but it’s not too complex that you can’t brute force all the possibilities.  So that’s what I did:

So I broke out all the possible roll combinations and the associated likelihood for each (note, since we may roll anywhere from one to three times, each outcome is not equally likely).  To check my math, I summed up all the probabilities and got unity, so I’m optimistic I did it right.  The odds are that you’ll be successful on just a skosh more than 2 out of 3 turns (67%).

It never hurts to double check.  So in addition to this sort of derived approach, I went for a Monte Carlo approach as well.  It only took a little bit of python to confirm the numbers that I got previously.  I also confirmed an additional little detail.  When successful rolling paws for the purposes of finding clues, the average (mean, median, and mode!) number of paws is exactly 4 (note: 3 of the sides of each die have paws; 2 of the sides have a single paw and 1 side has two paws).

import random

random.seed(19)

die = [0, 0, 0, 1, 1, 2]

def roll(ndice):
 dice = []
 for i in range(ndice):
 dice.append(die[random.randint(0,5)])
 return dice

def get3():
 paws = 0
 ndice = 3
 for i in range(3):
 dice = roll(ndice)
 for i in range(ndice):
 if dice[i] > 0:
 paws = paws + dice[i]
 ndice = ndice - 1
 if ndice == 0:
 return paws
 return 0

nturns = 100000
success = 0.
fail = 0.
paws = 0.

for i in range(nturns):
 outcome = get3()
 if outcome == 0:
 fail = fail + 1
 else:
 success = success + 1
 paws = paws + outcome

print 'Success: ',success/nturns
print 'Failure: ',fail/nturns
print 'Avg. Paws: ',paws/success

My apologies in advance if you’ve never had the privilege to ride in a car with a sun roof at a high rate of speed. If you’ve been this fortunate, perhaps, because sun roofs can be quite noisy when traveling at high rates of speed, you’ve been in such a car during which the sun roof is closed while traveling at a high rate of speed.  If not, I think closing a window while the car is moving fast can work equally well.

I bring this up, because it happened to me this weekend, and I noticed something quite interesting, which aroused the fluid dynamicist in me. My ears popped. Like changing elevation quickly, or closing your nose off while blowing out, the pressure in my ears changed. This caught me off guard, but it should not really come as a surprise.

Engineers use a similar principle to determine pressure drops in pipes, using an instrument called a manometer. It all starts with the Bernoulli equation:  +\rho g z_2

Bear with me, but we’ll go ahead and ignore the effect of elevation in this case, leaving us:

A manometer can measure the static pressure of a flow (the p value in the above equation) with an opening perpendicular to the direction of flow.  Oftentimes, whatever tube that’s perpendicular to the flow will have a column of liquid that will move up or down depending on the static pressure it is measuring.

Okay, so let’s call the car a giant manometer of sorts that takes on the static pressure of the air whooshing by the sun roof.  Supposing the static pressure of the air rushing by is simply a single atmosphere (101 kPa), then if there was no other circulation in and out of the car, this is what the static pressure of the car would be (the caveat is that the geometry of the sun roof is probably not ideal for measuring the precise static pressure).

Well, if the car were perfectly sealed, and the sun roof could close very, very fast, the pressure would not change.  However, the car is certainly not immune from the influences of the outside air, even with the sun roof close.  I’m going to assume that with all the windows closed and the A/C off, the inside of the car will equilibrate to the stagnation pressure:

That doesn’t seem like a huge difference, but it’s likely sufficient for your ears to pick up on.  If the A/C was on high or there was a giant hole in your windshield, the car would probably maintain a pressure of 101.4 kPa.  But suppose the forces driving the pressure of the car down to 101 kPa through the sun roof are more powerful than the ventilation leaks that would tend to move the needle to 101.4 kPa.  Then the act of closing the sun roof will quickly (depending on how “leaky” the car is) shift the pressure up to 101.4 kPa, causing your ears to pop!

My intention was to come up with a cleaner description for this effect than I managed to churn out.  My apologies for making a mess of it, and I’m open to suggestions on how to tighten up the explanation… but it’s a simple enough experiment to try it out for yourself!

Now that I had established the mis-calibration of my oven, I wanted to characterize it so that I can dial it in to achieve a desired temperature.  I know that it’s easier to raise the temperature than to wait for the temperature to dissipate, so my plan was to start at a low temperature (200 ) and periodically (approx. every 20 minutes) increase it by 25 degrees at a time.  Below are the results:

A couple of neat points until I get to the heart of the matter.  Notice how the frequency of the temperature control increases at higher temperatures.  Remember, I had established that the cooling off of the oven occurs similar to exponential decay.  The result is that it cools off relatively fast (deg/min) at higher temperatures, and slower at lower temperatures, because the temperature difference with its surroundings is higher at the higher temperatures.  So, because it’s cooling off faster at higher temperatures, the heating element has to turn on more often, causing the temperature to fluctuate much faster.  In fact, at the lower temperatures, I didn’t even get a full cycle over which to average during the 20 minute duration.

So I pick up the temperature correlation at 275 .  My initial inclination was to just take the average value between each period’s peak and trough, but because the curve is not regular (it cools off slower than it heats up), this would bias the temperature higher than what the time averaged temperature actually is.  So I took the time to actually time average each curve segment between peaks (or multiple peaks if available).  The following is those results as well as a linear curve fit:

In a perfect world, where the oven works like it’s supposed to, the best fit line would have a slope of 1.0 and an intercept of zero, i.e. , i.e. what you dial up on the oven is what the temperature actually is.  Unfortunately, both values differ from their ideal.  So, not only is there an offset between dialed and measured temperatures, but moving the dial by a degree results in 1.06 degree change in the oven temperature.  As a result, the oven is off more at higher temperatures.   For example, when the dial reads 300, the oven is at 336 ; 36 degrees off.  But when the dial is at 500, the oven is at 548 ; 48 degrees off.

I don’t think I’ll be wanting to run that calculation every time something needs cooking.  I’ll probably pick a “best” offset value of, say, 40 degrees and hope that the recipes can tolerate a difference of 10 degrees or less.

I knew that thermocouple that I bought with no solid plans for using would come in handy some day…

I’ve got a new place with a new oven that has been consistently over-cooking my food.  I could call the super, or turn the oven down or cook everything for less time, but none of that gives me an excuse to bust out my Arduino.  Fortunately, I already had a (K-type) thermocouple and MAX6675 amplifier on hand that have been looking to add purpose to their lives.  Using a handy Arduino library for the MAX6675 made life and coding really straight-forward.

My original intention was to simply display the oven temperature on an LCD and take readings at several oven temperature settings.  I’m glad I decided to be a little more rigorous and actually record the serial data that was sent to my computer (one data point per second).  As it turns out, the temperature fluctuated over a wide range, so the data records were handy.  Not only was there a wide range of temperatures, but they were consistently higher than the oven setting of 400 .

This is the data taken after turning the oven on.  You’ll notice a couple of things.  First, the temperature oscillates pretty regularly.  As far as I can tell, the heating element goes from all on to all off, contributing to the bouncing around.  Also, the magnitude of the fluctuations made me suspicious that I was getting a bit of a misleading reading due to the radiation coming off of the heating element.  I’d rather not expound on this too much in this post, but try holding your hand in front of your face when next to a fire.  You will immediately feel cooler; most of the heat you from a fire (an outdoor one, anyway), is radiative.  This temperature does not reflect the air temperature; this is why you put a thermometer in the shade.

Anyway, I thought this might be contributing to an elevated temperature reading, so I put a piece of aluminum foil between the thermocouple and the heating element at the bottom of the oven.  The foil was intended to block the radiation from the red hot heating element.  I tend to believe this worked; it’s not as if the foil got red hot (~1500 ), but obviously, it made little to no difference in the temperature reading.  So either this radiative heating was never or factor, or I am making a mistake.

After 35 minutes, I turned the oven off, just to see how it cooled off:

This looked like something that maybe I could model…  In fact, recalling some of my heat transfer book-learnin’, I figured the best way to start would be to treat the oven as a lumped capacitance system (insert spherical cow joke here).  I didn’t have my old textbook on hand, so I fell back on Wikipedia, which provided me with a nice equation for the expected exponential decay:

A characteristic time of 0.00045 seemed to do a nice job of matching the theory to the model:

Not bad.

I did these tests two different days; I was actually shocked at how consistent the temperature histories are!  The oven may be wrong, but it’s wrong consistently, which means I should be able to learn to use it without burning everything.  I guess a potential next test would be to do this analysis at various oven setting and observe what the results are so that I have a consistent adjustment to cook my food appropriately.

At the end of the day, I’m wondering what my oven is doing wrong. Is the feedback (a thermocouple, I presume) mis-calibrated (assuming mine is accurate…)? Where is it placed? Perhaps it’s measuring temperature in a location not particularly relevant to the oven center. Questions for another day…