Imagine you had to figure out whether or not a complicated engineering problem you're trying will work - for example, whether or not you can build a solar panel to power your home. The system is too complicated just to guess, but figuring out exactly how much power you need and how much the solar panel can give would take a lot of time and energy - and would be a waste of time if you figured out you were wrong!

Instead, you could use values you can guess reasonably accurately (like the hours of sunlight where you live and power requirements of your lightbulbs) to get a rough idea of whether your idea is feasible or not. If it looks like it might work, you can go on to do more in-depth calculations, and do a design. If it looks very unrealistic - for example, it takes about a whole field of solar panels to power your house - then you might want to think about another way of doing things! *This is an example of what estimation is.*

Very simply, estimation is the skill of roughly figuring out the value of something by using other values you can guess easily, and making a model of the problem.

It is one of the most basic skills in physics, and also very useful in engineering. It lets us get an good idea very quickly about whether something is possible or not.

Sometimes this might be very simple: e.g. “how many beans are in that jar”

However, some are not so obvious. e.g. “is my solar system feasible” might really mean “can I make a system that will supply the power I need to my house, but will also be able to be physically built and won't be too expensive”

There are lots of ways to do this. You can work backwards from what you want to find out and see what values your answer depends on, and what *they* depend on, until you get things you can guess.

Or, you can see what values you can guess right now, and see if you can figure out how to model the problem based on them.

E.g. for the obvious problem “how many beans are in this jar”, important values could be:

Volume of the jar

Volume of one bean

How much (what percentage) of the jar's volume is taken up by beans?

A good way to start is to make a list of all the values that affect the problem, and then see if you can make a model using them. See which values you can easily make a good guess at, and which ones you need to figure out from other values.

A model of a problem is the set of assumptions that you are making about the problem and how they are related. The key to estimating a complicated system is dependent on making a model! What values are involved? How do they depend on each other? What assumptions can we make about them?

A problem can be modelled in lots of different ways. For instance, for the question “how many domestic flights are there in India per week?” we could model the problem a few ways:

We could say that the number of flights depends on the number of passengers…

How many people are there in India? ( ~1 billion) → how many of them can afford to take regular flights? (~5% of the population, so 0.05 x 1 billion = 50 million) → how many flights does the average passenger take per year? (~3 ) → how many passengers are there per year (3 flights x 50 million people = 150 million passengers) → how many passengers are there per plane (~150) → how many planes fly per year (150 million passengers / 100 = 1 million) → how many planes per day → (1 million per year / 365 = ~2,700 per day

OR we could come at it from a different approach.

We could say that the number of flights depends on the number of flights Indian airports can host…

How many airports are there in India? %%*%%space for this fermi problem*

Complicated problems like these that need to be worked out by estimation are called Fermi problems.

We've said before that what is important is a good model, rather than exact numbers. We're wouldn't use estimation to design our system, but we'd use it to see if our system was *worth* building. We use it to see whether building the system is possible or not.

Therefore, it doesn't matter what exact value we get, but whether it has the right order of magnitude. The order of magnitude of a number is how many times it is multiplied by ten. For example, 20 and 40 have the same order of magnitude, as do 430 and 600, but 20 and 430 do not.

In general, we can say something is feasible if it is the correct order of magnitude. For instance if you estimate your power requirement to be 600W and approximate power you can generate to be 50W, then your idea is probably not feasible.

However, if you estimate the power requirement to be 600W and the power you can generate to be 400W, then it's probably worth doing some more exact calculations to see how you could design the system.

By their very nature, all these problems are modelled in different ways, so the only way to really understand how to model a Fermi problem is to do them yourself!

Here is a good resource for Fermi problems: http://www.vendian.org/envelope/dir0/fermi_questions.html

Some common ones:

How many fish are there in the ocean?

How long would it take to walk around the world?

How many motorcycle repair shops are there in your town?

What is the weight of the food you eat in a year?

How much water do households in your country use in a week?

How many gallons of paint do you need to paint the walls of your school?

How many times will your heart beat during your lifetime?

We can work out fermi problems easily if we're familiar with the context of the problem. Try to think of either universal problems, or problems related to the lives of the students in the club. Come up with at least 5 or 6 before the lesson that would be familiar to the students.