Problem Solving

The comment from FUG led to a nice little blog about chemistry with a clever title, although I hope his future is centered on experimental UNCERTAINTY rather than experimental ERROR!

For some reason (my money is on a bug due to use of M$-specific java crapware), I can't comment on blogger driven blogs that use "comment_from_post_iframe.js" like his does. It simply does not recognize my selection of the pull-down menu. As a result, I will comment here on one of his recent articles. Another article, an undergrad's view of the chemistry -v- physics "fight", has potential as a jumping off point for a look at why so many engineering students dislike chemistry. What "type" of person prefers one over the other?

Here, I want to look at his article about a basic static equilibrium problem of a beam and a mass.

He gets off to a pretty good start, drawing a nice, clean free-body diagram. That is essential, and the only thing missing is the location of the center of mass of the stick and the fact that an unknown force "mg" acts there.

But his next step is not the most important one. Rather than notice

the fact that the meter stick isn't moving

and identify the problem as a STATIC equilibrium problem (with the implications that net torque = 0 will likely be used to solve it), he grabs the equation for accelerated motion and worries about the moment of inertia of each object. That would only matter if the same situation was described, but you were told the angular acceleration of the system at a particular moment. (That would make a good problem. Make a note of it.)

His "simplest solution", using the fact that the system's center of mass must be over the support point, is equivalent to solving the net torque = zero problem. (Another mental note: I need to point that out, because we encounter those two ideas at rather different points in the course.) The key to finding that solution is at the very start, when classifying the problem type. That step is triggered by the key words "it is balanced" in the question.

That is where "critical reading" enters the problem-solving game.

And I happen to think that it is more important to spend time on "critical reading" as a component of problem solving than some of the tricky concepts. But that is the subject of the yet-to-be-written next blog entry.

Aside:
Regarding the observation

The human mind can only compute so much.

I can only say that I agree, but the limits on it are the result of training, experience, and focus. For example, when fully immersed in the problem, I know I can hold the essentials of about 10,000 lines of Fortran computer code in my head (along with all of the associated physics), but can only manage parts of a 100,000 line code in that way.