After 25 years in aerospace, I have never seen a program derailed by a coarse mesh. I have seen them bleed money over a precise answer to the wrong question.
You're welcome Harsha. I'm glad to hear that the article is helpful for you. Feel free to reach out anytime about your FEA learning process. I will be more than happy to help you.
Love this article and discussion. Thank you for bringing this discussion forward.
In my experience what is meant by the term “engineering judgement” often varies based on the engineer. Pick your favorite and most well-respected colleagues and ask them to define it.
In many contexts judgements are decisions that are made in the absence of the desired engineering data. Such judgements about what is appropriate are often a time saver, until testing or real world operation teaches otherwise, as you highlighted.
What you describe as “engineering judgement” is very very very important when the consequences are high. However, in some circles what you described is considered a process of “critical thinking” that if performed results in a thoughtful evaluation of each of the choices an analyst makes on a project.
Something to ponder to ponder over coffee, tea, or beer and with friends.
Thank you Brett for this, it is a sharp distinction and worth sitting with.
You are right that the term gets used loosely, and I think the "critical thinking" framing you mention is actually closer to what I am pointing at than "judgment" as it is sometimes used in everyday speech. When people talk about judgment as some accumulated instinct that cannot be articulated, that is where I part ways with the term. What I am describing is closer to a disciplined evaluation process: estimate first, interrogate boundary conditions, know the model's domain of validity, treat surprises as questions. That is teachable and checkable, which instinct is not. Your point about judgment filling the gap where data is absent is a good one, and I would add that the danger is not making that call under time pressure, it is failing to flag that the call was made at all. Appreciate you pushing on the terminology, it sharpens the argument.
Thank you very much, this article is extremely important and helpful for people like me to improve my perspective and get better as an FEA Engineer.
You're welcome Harsha. I'm glad to hear that the article is helpful for you. Feel free to reach out anytime about your FEA learning process. I will be more than happy to help you.
Great discussion.
Love this article and discussion. Thank you for bringing this discussion forward.
In my experience what is meant by the term “engineering judgement” often varies based on the engineer. Pick your favorite and most well-respected colleagues and ask them to define it.
In many contexts judgements are decisions that are made in the absence of the desired engineering data. Such judgements about what is appropriate are often a time saver, until testing or real world operation teaches otherwise, as you highlighted.
What you describe as “engineering judgement” is very very very important when the consequences are high. However, in some circles what you described is considered a process of “critical thinking” that if performed results in a thoughtful evaluation of each of the choices an analyst makes on a project.
Something to ponder to ponder over coffee, tea, or beer and with friends.
Cheers
Thank you Brett for this, it is a sharp distinction and worth sitting with.
You are right that the term gets used loosely, and I think the "critical thinking" framing you mention is actually closer to what I am pointing at than "judgment" as it is sometimes used in everyday speech. When people talk about judgment as some accumulated instinct that cannot be articulated, that is where I part ways with the term. What I am describing is closer to a disciplined evaluation process: estimate first, interrogate boundary conditions, know the model's domain of validity, treat surprises as questions. That is teachable and checkable, which instinct is not. Your point about judgment filling the gap where data is absent is a good one, and I would add that the danger is not making that call under time pressure, it is failing to flag that the call was made at all. Appreciate you pushing on the terminology, it sharpens the argument.
Great article a pleasurable and insightful read
Thank you Nkosana. I'm glad to hear that you enjoyed the article. Thank you for your feedback. Much appreciated.