Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re^6: [OT] Forces.

by bitingduck (Chaplain)
on Feb 15, 2016 at 23:56 UTC ( [id://1155310]=note: print w/replies, xml ) Need Help??


in reply to Re^5: [OT] Forces.
in thread [OT] Forces.

You're overthinking it. All you're trying to do is numerically integrate the accelerations over time to get the new position at any given time.

You can start with F=ma. Your system means that the motion is constrained to a circle, so all of the a's and v's will be angular accelerations and velocities.

Don't solve the forces at a uniform distribution of positions around the circle, solve them at a uniform distribution of times. To get the new position at each time, use the acceleration (a=F, since m=1)to get the velocity, then add v*t to your current position to get the new position (holding the current velocity for use next time, too. If you pick reasonably small time steps, this should work fine. If you solve it at uniform angles instead, you should be able to get away with interpolating. It doesn't matter if there's an initial angular velocity-- that would just be added to whatever you get.

In pseudocode I think all you need is:
$m_inverse=1 /* this could be chosen as arbitrarily small, like 0.000 +01 to get effectively smaller time steps) */ $v=0 $theta=0 while(!$done){ ($F_x,$F_y)=ForceCalculator($theta) $F_perp=$F_x*sin(theta)+$F_y*cos($theta) $v=$v+$F_perp*$scale $theta=$theta+$v }

And you just have to make $m_inverse small enough to make the motion from step to step differences small. This is equivalent to changing the mass.

EDIT: this is the same thing that salva said here: Re^7: [OT] Forces.

Replies are listed 'Best First'.
Re^7: [OT] Forces.
by BrowserUk (Patriarch) on Feb 16, 2016 at 04:30 UTC
    All you're trying to do is numerically integrate the accelerations over time to get the new position at any given time.

    Okay. Accept by setting mass = 1 (or any other constant), were effectively ignoring the mass; so any "position" derived is at the very best scaled incorrectly. Presumably, the undeclared, set or explained $scale in your pseudo-code is there to account for that.

    So effectively, $v becomes a running accumulation of the consecutive instantaneous force vectors (minus their direction?) scaled by some arbitrary constant. The direction could be retrieved/retained by storing tan-1( Fy / Fx )

    But, F(N) = m(kg) * a(ms-2). Set m = 1, and F(N) = a(ms-2). I'm given F, I want metres, so rearranging m = N * s-2. I have N, but no s. s is undefined and undefinable. If the mechanism is rotating slowly, the time taken to traverse an input step of 1 degree will be longer than if it is running quickly. Perhaps orders of magnitude: 1 rpm versus 1000 rpm.

    And if we set the time to some arbitrary constant, then we are equating distance moved with force acting: m = N. If the mechanism was a simple rotation around a single axis, we might get away with that. (And I'm unconvinced of even that.)

    But as the force we have is acting in a semi-radial direction on a compound (cam) linkage, the force will act for some unspecified time period to 'straighten' the link, at which point it reaches a form of equilibrium. But achieving that position will only require some subset of the force acting. At that point, the rest of the force will simply be expended trying to stretch the link. And as far as I can tell, there is no way to decide what proportion of the force did work, and what was expended in futility.

    Since my steps are (can only be) (angular) distance traveled -- and that's what I'm trying to determine -- the next input position is defined as the position resulting from the last integration. The best I can do to achieve my desired "at least 1 simulation for every degree of rotation", is: if the result of a step is substantially greater than one degree, divide the angles I used to establish the position I fed into that step, by 2 or 3 or whatever is appropriate, and re-run the model to obtain the intermediate positions.

    But that accumulation of intermediate steps will almost certainly result in a different final position, as the forces acting through a degree of movement are definitely non linear.

    For example, let's assume that the general direction of the preponderance of forces acting is fixed. (They aren't, but bear with me.) And for simplicity, let's assume that direction is the opposite direction of the green force line shown in my diagram. And the X/Y force values I get are Fx = 200, Fy = 3.

    In the first step, the vast majority of that X component will be expended in trying to compress the link A-B. And only the small Y component will cause A to rotate about B, some small amount.

    In the next step, the small movement that resulted from the previous step means that the leverage has changed, and the same forces acting will have a bigger effect. Ditto the next step, and the step after that, until eventually, A has rotated far enough around B that A-B is aligned with the resultant force vector. At that point, if the forces acting don't vary, no further rotation would be possible.

    My point is, I cannot see how directly equating distance with force can possibly result in anything useful?

    Please, I'm an engineer who does a little math. If I missing the purity of the math you are suggesting, (and simply muddying it with all my talk of physical units and motions, I'm sorry :) but since any determination of work done derive from F = ma inevitably requires a known time delta, and there is simply no way to derive one from a static model.

    Nor do I see it possible to assume one or allocate one arbitrarily.

    Also, and perhaps more importantly, F = ma requires that all forces (and masses and accelerations) are taken into account; but, by Newton's 3rd, the reaction force from the solid, fixed and immovable B is unaccountable in the above.

    Update:BTW, don't you just love the way a-holes downvote what they don't understand. Amuses me no end :)


    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.

      Also, at worst you're only off by the mass scaling factor-- you can solve the whole problem as described and the only thing that changes with mass is the speed. Each loop iteration is a time interval, also with some unit that you can select later, where you can rescale the whole problem by the mass and time units. Dimensionally what I've shown is correct, and since you don't actually have a mass or specified time, you can rescale by both later.

      The only force component that matters to producing motion is the one that I've called F_perp. The loop is a numerical integration over time to get the position and velocity, where we're using arbitrary time units (which is perfectly acceptable as long as they're consistent). You could explicitly put in a "dt" each iteration, but you can scale by that at any time.

      There's nothing philosophical about it--I'm just leaving out the things that don't matter. If there are no torques on the disk/cylinder, then conservation of angular momentum means it will maintain its orientation as it goes round, so that's a distraction. As are forces that put tension or compression on the linkage, but don't produce motion unless you want to include the real properties of materials and then you're talking full up FEM and you might as well just have somebody draw it in SolidWorks and mesh it up to see the tiny deformations (unless you choose silly putty as the material, in which case they'll be huge).

      This problem is much closer to my day job than coding in Perl is.

      Edits to add more explanation:

      I'm not equating a force to a distance-- we're integrating up the acceleration over time. F= ma (units mass*length/time^2). If I divide out the mass (in arbitrary units, where the mass involved =1 unit, then I have a= magnitude(F) with units of (length/time^2). If I calculate the forces on the disk at some time t, then multiply by some small dt (which is buried in the mass scaling factor, so I cheated a little there), then I get a new velocity at time t+dt=v+a*dt, and a new position that's x=x+v*dt. I buried the dt by suggesting that you just keep shrinking the scale til the motions of the linkage on any iteration are small, but you could put it in explicitly for convenience.

      Another edit...

      since any determination of work done derive from F = ma inevitably requires a known time delta, and there is simply no way to derive one from a static model.

      You don't have to ask the static model for a time delta. You pick a time delta small enough that if you calculate the velocity and acceleration (from the net force produced by the static model) at any time t and multiply it by the interval you're choosing, you get a new position and velocity that aren't very different from the previous ones. That's how numerical integration works. As the time delta gets smaller and smaller, you get something closer to what you'd get from an analytical solution.

        You are modifying theta by your derived v, but if the force calculated directly opposes or aligns with the current position of link A-B, NO MOVEMENT WOULD RESULT, but your calculation would adjust theta by an effectively random amount.

        Simply stated, that cannot be correct; nor even an approximation to correct.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1155310]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others examining the Monastery: (7)
As of 2024-04-16 13:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found