Month: January 2021

Cooking Thermodynamics

Published on by Michael BurkeLeave a comment

This year for Christmas, knowing my love of comparative cooking methods, my wife Deborah got me an Air Fryer; the results have been delicious.(1) This got me thinking about the thermodynamics of cooking(2) and what it would take to model both an air fryer and a past present (the instant pot).(3)

Physical (modeling)

Cooking is a heat transfer problem; move the energy from the cooking device into the food.

  • Pan cooking: conduction
  • Oven cooking: conduction and radiation
  • Air frier: conduction, radiation and convection
  • Instant pot: conduction

However there are limitations. The maximum temperature of an oven is limited to the energy of the heating method (gas or electric), boiling liquids are “capped” at the boiling point of water; this then is the “trick” to both the air fryer and the instant pot. The air fryer combines 3 methods for transferring heat, while the instant pot increases the pressure in the “pot” which raises the boiling point of water.(4)

Three simple rules

3 rules

Cooking with an air fryer has three simple rules:

  1. Pre-heat: Heats the basket, giving conduction cooking
  2. Space out: Aids in convection
  3. Shake: Gives all sides a shot of conduction

From this we can determine that when you cook there is browning in the contact in the pan, that the air blows around the food from all sides (and the bottom) and that to get brown all sides of your food need to touch the bottom. So what would the physical model look like and how do we optimize the results?(5)

ParameterEffectTrade off
Pan thermal massBrowning effectLonger warm up time
Grate arrangement of panAirflow (convection) between foodReduces thermal mass
Blower speedIncrease convectionEnergy usage
Food packingImpact convectionVolume of food to be cooked
at one time
TemperatureRate of food temperature increaseEnergy usage

Equation time!(6,7)

For now let’s assume a Platonic solid French Fry, e.g. cube 1 cm x 1cm x 1cm.(8) In this case the equations for the heat transfer could be written as…

  • Conduction: Q/Δt = -k * A * ΔT/Δx (9)
  • Convection: Q/Δt = A h(Tp – Tpf)(10,11)
  • Radiation: By evaluation O(10-3): dropped

By further inspection we can see that Q is the energy from the heating unit. If we assume that the thermal mass can be treated as an infinite sink (and if we have Platonic Fries we can allow this) then we can reorder the equations as so…

Tpf = Q/(Δt) * ((1/k*A1) + (1/h*A2)) + Tp

The Platonic Fry Model

Extensive field work is now ongoing to determine by experiment the values of k,h, A1 and A2 for Platonic fries (and other foods). The formula for “browning” is also under development, but as I hope this article has shown you, it is possible to determine through analysis and simulation.

Footnotes

  1. The biggest surprise is how good the “air fried” carrots are; they are a reliable “go-to” afternoon snack.
  2. The control algorithm for this device is very simple, a boolean for the fan on or off, and a predictive element for the temperature.
  3. I find it most interesting to alternate between new kitchen gadgets and experimenting with just a pan, bowl and knife.
  4. I just had a thought; when you flambe food or cook with alcohol in general it boils off due to the lower boiling point than water; what would happen in the instant pot?
  5. In this case optimizing the results means crispy exteriors and internal temperature cooked to “done.”
  6. “Equation time” sounds like a kid show that I would like to see produced.
  7. Despite the image we will not be covering solar roasters today.
  8. When I picture this it sounds more like Platonic Hash Browns
  9. The thermal conductivity of a potato should be similar to that of water due to the high water content of the potato.
  10. Tp is the pan’s temperature and Tpf is Platonic fry’s temperature.
  11. The “A” term in this equation is affected by the crowding of the pan; the more crowded the food the lower the A.

Testing Requirements: Part 3

Published on by Michael BurkeLeave a comment

In part 3 of this series, we look at how and why we create test harnesses.

Post credit thoughts

MathWorks provides stellar documentation on the creation of test harnesses; the key thoughts should be on why we create them (to avoid modifying the UUT) and how we call them (from test runners!)

Types: Not just for fonts…

Published on by Michael BurkeLeave a comment

Typographically inclined people can debate for hours the importance of font selection in the presentation of a message; a proper font(1) sets the right type of message.(2) With programs, data type is used to specify range and resolution of the data as well as determining the total memory and speed of your program.

I is for integer, at least in FORTRAN

In modern programing languages there are three primary data formats; integer, fixed point(3) and floating point. The range of integer data types is determined by the size of the data, e.g. 8, 16, 32 or 64 bit data types and the signed / unsigned nature.(4)

Floating point data represents information as a combination of a sign bit, an exponent component and a fractional component. This gives floating point data a greater range and resolution; however this can lead to issues when performing operations on data of significantly different orders of magnitude. For an overview of floating point data I would recommend this Wikipedia entry.(5)

What is the “point”?

Memory usage is easy to understand,(6) using all 32 bit integers in your program will use twice the memory of 16 bit integers; the same idea applies to floating point data types. The trade-off then comes with accuracy and speed. Integer based arithmetic is computationally faster then floating point; likewise, 64 bit floating point takes longer then 32 bit. The objective should be to use the smallest data type that fully represents your data after completion of the operation.

Tips and tricks!

  • Overflow, underflow and precision loss can be detected through the use of simulation or tools such as Polyspace
  • Disable range checking and overflow options for generated code to create more efficient implementations

Footnotes

  1. Here in this blog I lack the control of what font you see in your browser or in your email; for all I know you are using Wingdings (🕈︎♓︎■︎♑︎♎︎♓︎■︎♑︎⬧︎).
  2. And of course typesetting is part of the act of printing, the precursor to publishing electronically.
  3. Fixed-point could be considered a special case of integer data type, we will look at it in a future blog post.
  4. E.g. an 8-bit unsigned integer would have a range of 0 to 2^8 (256), while a signed 16-bit integer would have a range of (2^15 – 1) to 2^15 (-32767 to 32768). In every case they have a resolution of 1.
  5. There is a conceptual overlap between fixed point data floating point operations work; this link provides a general overview of fixed-point data.
  6. There is a caveat here; all hardware has a “smallest data type.” If you specify a data type smaller then the smallest data type you do not see any memory savings.

Testing requirements: Part 2

Published on by Michael BurkeLeave a comment

In this final video we are going to tackle the “Must never” and “Must always” cases for requirements. To do so, the use of mathematical analysis is employed to determine if the conditions hold.

Afterword

In some instances “never” and “always” cases cannot be definitively proven; when this happens there are three alternatives. First, subdivide the model into a smaller unit under test and attempt to prove the condition at that level. Second, determine under what conditions the requirement cannot be proven and then implement guards against those conditions. Or finally, explicitly guard against the condition in your model.

Port in a storm

Published on by Michael BurkeLeave a comment

“It is not enough to know how; it’s the when that is key.” With all projects, at some point in the development cycle problems arise.(1) When they do, questions of refactoring or porting should land on your shores. Often simple bug fixes or in-language refactoring is enough to resolve the issue; however when the impact crosses a critical threshold the answer is to port.

Port:
noun: a town or city with a harbor where ships load or unload.
verb: to transfer between two locations or environments

When it’s not right: port(2)

Porting software can be a major endeavor. Prior to this action a 5 part assessment should be made:

  1. Will this software module be in use for the long term(3) (e.g., will it exist in code deployed in the field; what is the life span of that product?)
  2. What is the criticality of the error? Is it: life threatening, product unusable, product behavior degraded, or is it a minor usability issue?
  3. What are the other issues facing the product and their criticality?
  4. If fixed now in-language will a later porting be required?
  5. What is your deadline?

Assuming that the metrics for 1 ~ 4 are high enough, and assuming that there is enough time before your deadline, it is time to port.

Estimating port fees

How do you estimate the time it will take to port your module, e.g. what is your “port fee?”(4) Ask yourself the following questions:

  • How long did it take the first time around; of that time how much was spent on determining what to do versus implementation?
  • Is the new language better suited for the implementation?
  • Is there existing testing infrastructure and can it be repurposed for the new environment?
  • Is the module unique or similar to existing code in the new environment; e.g. how well do you know your new environment?

The last question, how well do you know your environment is key. If you are just starting out in a new environment, the recommendation is to learn on non-critical applications. Learning an environment should never be a high stakes game.

Ah yes, the classic high stakes snakes and ladders game…

Footnotes

  1. Problems can
    • arise: e.g. float up from the buried issues in a poor design
    • fall: e.g. come from outside sources as new information or requirements are given
    • saunter in from the side: e.g. issues of integration with teammates
      All in all, problems are three dimensional in nature
  2. Assuming you are moving forward, port is left.
  3. Stones from pyramids and other monuments have over time found their way into other construction. It is possible that stones from the pictured are part of someone’s house. When determining if a software module will be in use “for the long haul” it is not enough to look at the full systems but all the stones that make it up.
  4. While free trade ports are a hot topic in economics, they do not exist in software.

Testing Requirements Part 1

Published on by Michael BurkeLeave a comment

This is part 4 in my video series on Model-Based Design testing. Today I look at how to test requirements of the form “When X happens the response is Y.” Follow these steps and then you too can enjoy testing.

Post movie credits…

In the video I state there are two basic types of requirements, when X happens Y occurs and X never occurs. In the final video in this series we are going to look at how we can prove the “never occurs” case.