A large rotating drum has unbalance in two planes. As the drum turns, the mounting system experiences a rotating force and moment, and the upper and lower bolts may alternate between higher tension and compression. The task sounds ready for software: build the geometry, assign materials, constrain the support, apply a load and solve.
But what load should be applied? Is the objective to estimate a global bolt-force range, investigate a local joint stress, predict bearing reactions, assess vibration amplitude, check resonance or study fatigue? Are the drum and support sufficiently rigid for a first estimate, or will flexibility and damping govern the response? Does the analysis represent one instant of rotation, a steady operating speed, a run-up or a speed range?
The software cannot answer those questions before the engineer does. It can only calculate the mathematical problem that the engineer has chosen to represent.
The direct answer
Explaining the physics before opening software does not mean solving every detail by hand. It means being able to state the engineering decision, isolate the relevant system, identify the source and path of loads or energy, predict the expected response and governing trends, expose important assumptions, and name the evidence that would challenge the model.That explanation is the minimum reasoning needed to choose a suitable model and interpret its output. Without it, software activity can look productive while the underlying engineering question remains undefined.
What “explain the physics” actually means
A physics explanation is not a recital of formulas. It is a causal account of what the system is doing and why. Another engineer should be able to hear the explanation and understand which bodies interact, where the loading comes from, how the effect reaches the component of interest, what response is expected and which assumptions could change the conclusion.
It is also not an argument against simulation. Some problems are too geometrically complex, nonlinear, dynamic or multidisciplinary for useful hand solutions. The point is different: computational complexity does not remove the need for physical clarity. It increases the need to define the model deliberately.
Why software-first analysis is so tempting
A software interface provides immediate visible progress. Geometry appears, materials can be selected, meshes can be generated and contour plots arrive quickly. The difficult choices are less visible: the objective, system boundary, load origin, support representation, relevant failure mode and evidence needed for credibility.
A tutorial may begin after those choices have already been made. The learner practises the commands but does not necessarily practise deciding whether the problem should be static or dynamic, linear or nonlinear, global or local, simplified or detailed. When the real task is under-specified, that missing decision layer becomes obvious.
Use a seven-question physics briefing before modelling
1. What decision must the analysis support?
“Find the stress” is not a complete objective. The decision may be to accept a design, compare concepts, size a bolt group, investigate a failure, select a test, change an operating speed or determine whether more detailed analysis is justified. The required model depends on the decision.
2. What physical system is being isolated?
Define what is inside the model and what is represented only through interactions. For the rotating drum, the system might be the drum and shaft, the bearing reactions, the flange and bolt group, the support frame or the complete rotor-support assembly. Each boundary answers a different question.
3. What creates the load or excitation?
Loads need origins, not merely arrows. In the drum case, mass eccentricity creates rotating unbalance excitation. Gravity, transmitted torque, process forces, thermal effects, start-up transients and joint preload may also matter. The relevant set depends on the intended decision.
4. How do force, moment or energy travel through the system?
Trace the path from the excitation to the component and eventually to ground. A rotating unbalance acts through the drum and shaft, reaches bearings or flanges, passes into the bolt group and support, and is reacted by the surrounding structure. Missing one interface can change both the load distribution and the apparent stiffness.
5. What response or failure mode matters?
The important result may be bolt-force range, joint separation, bearing load, shaft deflection, vibration amplitude, natural frequency, dynamic stress or fatigue damage. A maximum contour value is not automatically the answer. The output must correspond to the physical response and decision.
6. What trends and limiting cases should be true?
Before calculating, predict how the response should change. With zero unbalance, the rotating excitation should disappear. Increasing speed should increase unbalance loading strongly. Lower support stiffness can alter the load path and natural frequencies. Near resonance, the response becomes highly sensitive to damping and operating speed. These trends are not the final solution; they are tests of whether the model behaves plausibly.
7. What evidence will challenge the result?
Choose checks before seeing the contour. Depending on the problem, use force and moment balance, units, order of magnitude, a rigid or flexible limiting case, a simple hand model, a speed-sensitivity check, comparison with axial and radial vibration measurements, bearing-load data, test observations or another trusted model. The check should be capable of revealing a wrong assumption, not merely confirming the desired answer.
Let the physics choose the model
The same rotating drum may require very different levels of analysis.
• For a first estimate of global force and moment on an idealised rigid mounting, equilibrium and a compact hand model may be sufficient.
• For response across operating speed, support flexibility, natural frequency and damping may require a modal, harmonic, transient or rotor-dynamic representation.
• For local flange separation, bolt preload, contact and load sharing, a detailed joint model may be necessary.
• For fatigue, the cyclic load range, mean load, operating history and relevant material or joint criterion become central.
More detail is not automatically more correct. A detailed model can still represent the wrong boundary, excitation or failure mode. A simpler model can be useful when it is explicitly tied to a limited decision and supported by suitable checks.
Prediction before calculation is a technical skill
Prediction is sometimes dismissed as guessing. In engineering, a disciplined prediction is a compact statement of expected direction, trend, relative magnitude or dominant mechanism. It may be qualitative: “the bolt-force range should increase substantially with speed,” or comparative: “a more flexible support is likely to reduce a natural frequency and change the load distribution.”
Writing the prediction before solving protects the analyst from being persuaded by a polished result. If the output contradicts the expected trend, the contradiction becomes a question to investigate: Was the prediction incomplete, or was the model assembled incorrectly? Either outcome creates learning.
Five software-first answers that are still incomplete
“I will run FEA.”
FEA is a method family, not an engineering objective. The element formulation, analysis type, boundary conditions and outputs still have to be selected.
“I will apply centrifugal force.”
The analyst must define the rotating mass, eccentricity, angular speed, reference frame, spatial distribution and whether the load produces a net force, a couple or both.
“The mounting is fixed.”
A fixed support is an idealisation. The question is whether support, bearing, flange and foundation flexibility are negligible for the decision being made.
“The maximum stress is below yield.”
A rotating system may be governed by fatigue, resonance, joint separation, serviceability or bearing load rather than monotonic yielding. The criterion must match the failure mode and load history.
“The mesh converged.”
Mesh convergence addresses one part of numerical behaviour inside the chosen model. It does not prove that the physical system, load case or intended use was represented correctly.
Why intended use must come first
NASA’s current modelling-and-simulation standard treats acceptance criteria, credibility and communication as responsibilities across the model life cycle. Its companion handbook provides implementation guidance for the production, use and consumption of modelling-and-simulation products. ASME’s V&V 10 similarly provides a framework for assessing and improving the credibility of computational solid-mechanics models. [2][3][4]
The practical implication for a graduate engineer is simple: credibility work does not begin after the solver finishes. It begins when the question and intended use are defined.
How Struxinova develops physics-first reasoning
Struxinova follows a consistent sequence: understand the real-world situation, identify load sources and interactions, isolate the body or system, trace the load path, predict the response, perform a proportionate calculation or simulation, interpret the result and validate it. The course moves from remembered concepts to application, analysis, evaluation and creation through varied structural-mechanics situations. [1]
The rotating-drum situation is one example. The full learning task includes idealisation, dynamic unbalance, bolt behaviour and vibration interpretation. Public content can show the reasoning architecture and qualitative trends without reproducing the complete derivation, solved case or assessment logic.
This approach does not claim that a course score certifies employability or replaces company procedures, testing, standards or supervision. It develops a habit that makes later software work more purposeful and reviewable.
A ten-minute exercise before your next simulation
Choose a model you have already built, but do not open the file. On one page, answer these seven questions:
• What decision was the model intended to support?
• What was included in the physical system, and what was represented as a boundary condition?
• Where did every important load or excitation come from?
• How did the effect travel through the system to the region of interest?
• What response or failure mode was the model meant to evaluate?
• What trends or limiting cases did you expect before solving?
• What independent evidence could have shown that the model was wrong?
Then open the model and compare it with your briefing. Look for loads with no physical origin, supports that were chosen by convenience, outputs disconnected from the decision, and checks that were added only after the result appeared. Revise the explanation first; then decide whether the model needs to change.
Software should be the second language
Engineering software is most powerful when it expresses a physical model that has already been reasoned through. The analyst does not need to know the final answer before solving. The analyst does need to know what is being asked, what mechanism is expected, what assumptions are being made and what evidence would make the result believable.
Before you open the software, explain the physics. That explanation is not a delay before the analysis. It is the beginning of the analysis.
About the author
Avinash S is the CEO and Partner at InnoventEdutec, leading the Struxinova and Mathinova learning initiatives. He has more than 16 years of experience spanning engineering skill development, application engineering, technical-content development, project leadership and learning-product strategy. His work includes university- and industry-aligned learning programmes, academic and OEM engineering projects, engineering simulation programmes and technical training. Through Struxinova, he focuses on scientific thinking, engineering judgement, applied structural-mechanics fundamentals and physics-based simulation validation.
Sources and publication notes
[1] Struxinova course: “Free Body Diagram” lecture deck; “Structural Mechanics for Designers and Analysts” 150-hour roadmap; “Engineering Mechanics”; and “Free Vibration and Elements of Shaft Dynamics
[2] NASA-STD-7009B, Standard for Models and Simulations, active standard dated 5 March 2024; official status verified 5 August 2026. It establishes uniform practices for the design, development, acceptance and use of models and simulations, including acceptance criteria and credibility communication. Official source: standards.nasa.gov/standard/nasa/nasa-std-7009.
[3] NASA-HDBK-7009B, NASA Handbook for Models and Simulations: An Implementation Guide for NASA-STD-7009B, active handbook dated 3 February 2026; official status verified 5 August 2026. It provides technical information, clarification, examples, processes and techniques for good modelling-and-simulation practice. Official source: standards.nasa.gov/standard/nasa/nasa-hdbk-7009.
[4] ASME V&V 10-2019 (R2025), Standard for Verification and Validation in Computational Solid Mechanics; official edition and reaffirmation status verified 5 August 2026. It provides common language, a conceptual framework and general guidance for implementing VVUQ and assessing computational-model credibility. Official source: asme.org/codes-standards/find-codes-standards/standard-for-verification-and-validation-in-computational-solid-mechanics.