In the same way for linear movement you have the equation F = m * a, for a rotational movement there is T = I * alfa where T is the torque or moment of force, I the moment of inertia, and alfa the angular acceleration.

Problem. This is a static 2D FEA. Literally, a moment in time; so no time delta, no acceleration, no motion. And so, no direct means to determine any of them from the model.

My task is to try and turn that into a dynamic simulation. Literally, a time-lapse movie.

Start from the known starting point, run the model, extract an image of the resultant tensor field and save.

Then, try to approximate how the model must change in order to simulate the passing of a short elapsed time, and adjust the model to suit, then repeat. With small enough steps and enough iterations, a reasonable facsimile of the dynamics of the mechanism should be inferable. But the "approximation" can only be just that, because the model does not do dynamic.

The body in the problem is effectively a collection of varyingly magnetic materials. The forces involved are multiple magnetic fields impinging from essentially all directions. As the body moves relative to the magnetic field sources, the effects of those fields vary constantly; (with the square of the distance between the components of the body and the field sources impinging on them).

This problem is directly analogous to the N-body problem. Whilst it is possible to approximate a solution, calculating an exact solution would require huge resources of both time and processor power. Perhaps possible for the likes of NASA, Lawrence Livermore National Laboratory, and similar bodies, but certainly not for the likes of me :)

So, I'm back to needing to use intuition and fudge factoring to attempt to approximate the solution.

To my advantage, I do have some information not presented in the problem description -- because it arises from things outside of that description -- that tell me that the body will precess by a fixed and calculable number of degrees around A for every full revolution of the combined body/link assembly around B. Think of the 26,000 year cycle of the precession of Earth's poles as it revolves around the Sun.

In the example described and from which the numbers I've been quoting derive; that is (conveniently) 90° of body-around-A precession for every 360° of rotation of the assembly around B. This is easily incorporated into the calculations as a fudge factor.

Which brings me back to the OP description and my assumption that (in the small, and in isolation of the causes of the precession described above), the orientation of the body with respect to B will remain constant as point A rotates around B. Hence, my conclusion that the body will counter-rotate with respect to A as A revolves around B.

And so I come back to trying to work out how much counter rotation around A is required for each degree of A's rotation around B in order to maintain the body's orientation with respect to B?

As you can see from my diagram -- albeit that the angles are exaggerated -- the amount of the counter-rotation is not the same as that of the force vector. My conclusion is that it is (approximately) equal to the rotation of A about B. And that is determined by the angle at which the force vector's influence on the position of F (or equivalently A) comes to a halt because the force has moved the point F (and thus A) such that they form a straight line with B.

And that's what I am seeking either: a) confirmation of; or b) a cogent refutation of.

Thoughts? :)

My task is to try and turn that into a dynamic simulation. Literally, a time-lapse movie.

Yes, and this is the same as solving numerically the differential equations defining the mechanics of your problem.

It is a quite common and easy to solve problem:

1. Set the initial conditions of the system: initial angular speeds.
2. Using your finite element analysis software, determine the force and torques
3. Plug those values on the equations defining the mechanics of the system and get back the angular accelerations.
4. Using some arbitrary small delta time, calculate the angular speed deltas that follow from the accelerations and then the new speeds, and from those the new position deltas and then the new positions.
5. Goto 2.

How much computation power you need depends on the stability of the system. In practice that means picking smaller time deltas, or calculating them adaptively, or just using a better algorithm for the integration of the differential equations.

You will never know unless you just try.

Set the initial conditions of the system: initial angular speeds.

Um. The problem with that, is there are no "initial angular speeds". That is to say, there is simply no provision in the FEA software for the incorporation of 'speed' or 'momentum'.

Nor is there any need for it (in the FEA software). The (static) forces involved at any given position in space are the same regardless of how quickly you arrive at that point, or leave it. Indeed, if you think of something like a linear positioning motor on a CNC machine, most of the time the forces involved are those required to hold the workpiece (or tool) stationary against the cutting forces. And the magnetic forces are the same at startup, as they are for any given instantaneous position during traversal.

Now, whether I could (or should) attempt to perform the calculus required, to discretise the continuous motion between snapshots taken from the FEA, is really a moot point. To do it with any real accuracy, would -- I think -- require breaking the motion between FEA steps into 10s or preferably 100s of smaller steps. In addition to being a complexity I would rather not deal with, it would take considerable time.

Also, magnetism is often non-linear. For example, if materials move into magnetic saturation, the effects are distinctly non-linear. And at (and around) points of equilibrium, magnetic affects are subject to perturbations, which cause unpredictable instabilities (see Earnshaw's Theorum). Whilst the FEA takes all that into consideration on an instantaneous (static) basis; attempting to interpolate between static points in a linear fashion would inevitably result in non-linear jumps between frames. Better to use smaller steps and more FEA analysies than to try and second guess it, by re-writing it externally, I think.

As is, with the FEA taking an hour or more to integrate the forces for any given run, and my desire to run the model through at least one FEA analysis for each degree of rotation around B; the time-cost of the processing is already many days. I am reluctant to add substantially to that; especially as the result of the process is the production of a visualisation -- a movie -- from which no quantitative information can usefully be derived. And further because the desire is to produce a new movie after any (major) changes to the physical design of the apparatus.

The desire for the visualisation is to allow subjective, qualitative, side-by-side comparisons of the design iterations; to pick out break-point boundaries; maxima and minima; and similar events as the design progresses; to literally be able to 'see' the effects that changes have. Thus, the quantitative accuracy of the position in any given frame of the movie is of far less importance than that those frames consistently reflect the tried & tested (nearly 20 years to date) outputs of the FEA software.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)

In the absence of evidence, opinion is indistinguishable from prejudice.