Quote:
Originally Posted by Ether
|
Exactly. Also, sometimes modeling works well, sometimes it doesn't. Sometimes things working well is the best experience long term, sometimes it isn't.
This reminds my first taste of calculus back in 2010; two college mentors and I were trying to figure out the physics of various ball trajectories. After 3 hours, we didn't have any results that seemed believable and another set of student/mentors had a prototype kicker that they were testing in the hallway with a spring scale to gather empirical data with. Ultimately the empirical testing worked the best that particular time.
Based on that and other experiences, I've settled on a set of criteria that helps me figure out which route (or a mix) to take. I'll preface it by saying that this is what I'd do in a personal work/hobby situation, not as a mentor. As a mentor, I'd do some of each and let the students find out for themselves more or less what works for them, as I did before. Or rather, do some simulation, and then use a prototype to get some empirical data to match it up.
So, the first thing that I consider is how difficult/expensive a prototype is and how long such would take to make and test. If a prototype is going to be difficult, expensive, and/or time consuming, then I'll be more inclined to model than to prototype, and vice-versa.
Next, I factor in how much I know about and the difficulty of modeling the design in question. If I know how to accurately (and to a lesser degree, precisely) model the design and it isn't going to become a final exam question to deal with (read: multiple pages of equations and expressions), then I'll model it first, rather than going straight to a prototype. Otherwise, I'll reduce it down to blocks if possible and then model those that fit the above criteria.
Finally, the last thing I factor is what the end goal is. If it is a specific design, I'd be content with getting an empirical answer that just works. However, if the goal is more scientific in nature, such as a generalization or better knowledge of operation, then I'll model it, then prototype/test, then tweak the model, and repeat the cycle until I'm within an acceptable margin of error.
One other point I'll make is to factor in the degree of modeling required. There are many things and situations that have multiple models depending on application. An example of I know of in my field (EET) is diodes; in some applications they're just one-way valves for current, in some the nominal voltage drop is added, and in others, the internal resistance and/or exponential voltage drop equation is added. One device, many different models. In physics (and mechanical designs) various forms of drag fall into this category, such as air resistance and friction. Sometimes it matters, sometimes it doesn't.
Another "gotcha" to watch out for in regards to degrees of modeling is the tolerances of the design components. You're only as accurate and precise as the hardware you're going to build with. One of the biggest killers of fancy models is false precision; there is a reason why they teach the concept of significant figures in science courses (and why you should use them in engineering too!).
Sorry for the long post (or "thought post" as Dr. Joe might call this), but seeing the level of math being performed, I thought this might be good to know for those playing at home.