Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

Gravitation attraction proportioned

  1. May 28, 2008 #1
    Begin with two stars in space, A is 1 solar mass in size, B is two solar masses. The distance between them is such that the equation for gravitational attraction works out to 3 meters per second squared. It seems to me that with A being smaller, it will accelerate towards B at the rate of 2 m/sec^2 while B will accelerate towards A at 1 m/sec^squared. Is this correct?
     
  2. jcsd
  3. May 29, 2008 #2

    Hootenanny

    User Avatar
    Staff Emeritus
    Science Advisor
    Gold Member

    No, that is not correct. Consider Newton's law of Gravitation,

    [tex]F = G\frac{m_1m_2}{r^2}[/tex]

    And Newton's second law,

    [tex]F = ma \Rightarrow a = \frac{F}{m}[/tex]

    Hence, if one calculate the acceleration a1 of the first body with mass m1 one finds,

    [tex]a_1 = \frac{1}{m_1}\cdot G\frac{m_1m_2}{r^2} = \frac{Gm_2}{r^2}[/tex]

    And similarly for the second mass,

    [tex]a_2 = \frac{1}{m_2}\cdot G\frac{m_1m_2}{r^2} = \frac{Gm_1}{r^2}[/tex]

    As you can see, the acceleration dye to gravity of a body does not depend on it's own mass, rather it depends on the mass of the body it is accelerating towards.

    Do you follow?
     
  4. May 29, 2008 #3

    D H

    User Avatar
    Staff Emeritus
    Science Advisor

    Hoot, that is exactly what the OP has. He is correct.

    As Hoot mentioned, the gravitational accelerations of A toward B and B toward A as seen by an inertial observer are

    [tex]
    \begin{aligned}
    a_A &= G\frac {m_B}{r^2} = G\frac {2m_A}{r^2}\\
    a_B &= G\frac {m_A}{r^2}
    \end{aligned}
    [/tex]

    Right off the bat one can see that that inertial acceleration of A is twice that of the inertial acceleration of B because B is twice as massive as is A. Since A accelerates toward B and B accelerates toward A, the acceleration of A relative to B (or B relative to A), given as 3 m/sec2, is the sum of these accelerations:

    [tex]
    \begin{aligned}
    a_{\text{rel}} &= G\frac {2m_A}{r^2} + G\frac {m_A}{r^2} = G\frac {3m_A}{r^2} \equiv 3\,\text{m}/{\text{sec}^2} \\
    \text{Thus} \\
    a_B &= G\frac {m_A}{r^2} = 1\,\text{m}/{\text{sec}^2} \\
    a_A &= 2 a_B = 2\,\text{m}/{\text{sec}^2}
    \end{aligned}
    [/tex]
     
  5. May 29, 2008 #4

    Hootenanny

    User Avatar
    Staff Emeritus
    Science Advisor
    Gold Member

    :uhh: :redface:
     
  6. May 31, 2008 #5
    DH & Hoot,
    Thanks for the confirmation. I do have a follow up. Start with:

    [tex]F = G\frac{m_1m_2}{r^2}[/tex]

    I started out with that equation for force. Finding a value for the mass of the earth, I plugged in the values and simplified down to

    [tex] F = \frac{9.803 meters}{Kg sec^2}[/tex]

    I now put this into words to see if my understanding is correct.

    That given calculated force will cause one Kg of mass to accelerate at 9.803 meters per second squared. But part of saying that is general knowledge rather than a pure reading of the equation.

    After rewriting this a few times and not getting what I want, I will try to simplify. The 9.8 meters I understand, as do I the per second squared. But the per Kg part seems awkward and is not making sense. If the mass is doubled to 2 Kg, then the accelration will half to 4.9 meters / second squared.

    But just the same, the meters per kilogram part does not set well in my brain. I don't know what else to say, but am hoping you can say something that will help me alter my perspective.

    Thanks for your replies.
     
  7. May 31, 2008 #6

    D H

    User Avatar
    Staff Emeritus
    Science Advisor

    The force due to gravity near the Earth's surface is [itex]F = mg[/itex] where [itex]g=9.8\,\text{m}/\text{s}^2[/itex]. It is not [itex] F = 9.8\,\text{m}/\text{kg}/\text{s}^2[/itex]. The acceleration is (nearly) constant.
     
  8. May 31, 2008 #7
    I start out with
    F = (G m1 m2 ) / r^2

    If I expand G and drop the constants (makes it easier to track the types) I get:

    G = meters^3 / Kg seconds^2

    Adding in the m1m2/r^2 I get

    F = (meters^3) ( Kg ) ( Kg ) / ( Kg ) ( sec^2 ) ( meters^2)

    F = meters Kg / sec^2

    I see one error in that Kg should have been in the numerator instead of the denominator. But my equation is still wrong. Where am I getting or not dropping the extra Kg?

    DH said: The acceleration is (nearly) constant.
    If an object falls towards earth from 100 feet above the surface, the acceleration at the surface will be a tiny bit faster than at 100 feet. Was that your intent?
     
  9. May 31, 2008 #8

    D H

    User Avatar
    Staff Emeritus
    Science Advisor

    You can verify this via the SI version of Newton's second law, F=ma. The units of force in SI units is kg-m/sec2.

    In other words, your dimensional analysis is just fine.

    (Note: The generic form of Newton's second law is F=kma. SI is constructed by design such that the constant of proportionality in Newton's second law is exactly one. The proportionality constant is not necessarily one in other systems. For example, in the English system with mass expressed in pounds-mass and force expressed in pounds-force the constant of proportionality is 1/32.1740486 lbf-sec2/lbm/ft.)

    Your error was using little g, Earth standard gravitational acceleration, as a force. g is 9.803 m/sec2. It is not just 9.803 (it has units), and it is not a force (it is an acceleration).

    That is one of two reasons I said "(nearly) constant". Another reason is that larger masses do accelerate toward the surface of the Earth slightly faster than do smaller ones. Think of Newton's third law. Gravity makes the object accelerate toward the Earth and the Earth accelerate toward the object. The relative acceleration of an object with mass m toward the surface of the Earth is

    [tex]G\left(\frac{M_e+m}{r_e^{\;2}}\right)[/tex]

    However, [itex]M_e\ggg m[/tex] for even the largest man-made object. The difference in acceleration between a one gram object and a one metric ton object is immeasurably small.
     
  10. May 31, 2008 #9
    I am still missing something, but for the moment I would like to cut to the chase. I am writing a program that will provide the ability to enter the position, mass, and velocity of a few stars, then watch them zip around on the screen and see what happens. Going back to Hoot’s post it looks like I can use:


    [tex]
    a_1 = = \frac{Gm_2}{r^2}
    [/tex]

    And

    [tex]
    a_2 = \frac{Gm_1}{r^2}
    [/tex]

    This will calculate the acceleration imposed by any two stars on each other. (direction calculations omitted for now) I will do a round robin comparing every star in the simulator against every other star.

    As I know the units, the calculation will be:

    [tex]
    a_1 = \frac{6.67428 * 10^-11 * m2 }{r^2}
    [/tex]

    And if I have this right, I can express mass in tens (or hundreds) of million kilograms and radius in tens (or hundreds) of million meters and it should work out ok.

    That's just the acceleration in a straight line between the two. There is more work to do. My plan is to do two passes through. First calculate and sum the acceleration vectors on each star, then on the second pass, calculate the new velocity and positions. If I can get that to work (looking more difficult all the time), then I may consider the effects of general relativity.

    Thanks again for your time.
     
  11. May 31, 2008 #10

    D H

    User Avatar
    Staff Emeritus
    Science Advisor

    Here is an even better way:
    You will need a pair of functions (plus other functions to do your graphics) and a driver. One of the functions computes the acceleration vectors of all of the stars. Call this function the derivative function. The other function is your state propagator. This function takes as inputs a time step and state descriptions of each star (state meaning position, velocity, mass). The state propagator will call the derivative function and use this information to propagate the states of all of the stars to the end of the time step.

    Here are two simple state propagators; both call the derivative function once per time step. The accelerations depend only upon position.In the math that follows, I have denoted the accelerations produced by your derivative function as f(x). (The bold indicates vectors).

    Basic Euler method
    [tex]\begin{aligned}
    \mathbf x(t+\Delta t) &= \mathbf x(t) + \Delta t\,\mathbf v(t) \\
    \mathbf v(t+\Delta t) &= \mathbf v(t) + \Delta t\,\mathbf f(\mathbf x(t))
    \end{aligned}[/tex]

    Euler-Cromer method
    [tex]\begin{aligned}
    \mathbf v(t+\Delta t) &= \mathbf v(t) + \Delta t\,\mathbf f(\mathbf x(t)) \\
    \mathbf x(t+\Delta t) &= \mathbf x(t) + \Delta t\,\mathbf v(t+\Delta t)
    \end{aligned}[/tex]

    These two methods differ only in the order in which the positions and velocities are updated. In the basic Euler method, position and velocity are updated simultaneously. In the Euler-Cromer method, the position is updated using the updated velocity. If you want to use one of these simplistic techniques, use Euler-Cromer. Energy is more or less in Euler-Cromer conserved but not with the basic Euler method.

    The advantage of writing your simulator in the fashion I outlined is that doing so enables you to use more advanced propagation algorithms without changing any other parts of your code. How you propagate state should have nothing to do with how you initialize the system, compute acceleration, or display things graphically.

    A slightly more advanced integrator is the velocity verlet:
    [tex]\begin{aligned}
    \Delta \mathbf v_1(t) &= \Delta t\,\mathbf f(\mathbf x(t)) \\
    \mathbf x(t+\Delta t) &= \mathbf x(t) + \Delta t(\mathbf v(t) +
    \frac 1\ 2 \mathbf \Delta v_1(t)) \\
    \Delta \mathbf v_2(t) &= \Delta t\,\mathbf f(\mathbf x(t+\Delta t)) \\
    \mathbf v(t+\Delta t) &= \mathbf v(t) +
    \frac 1 2(\Delta \mathbf v_1(t) + \Delta \mathbf v_2(t))
    \end{aligned}[/tex]

    Here you call the derivative function twice per time step. This is *a lot* (not just twice) more accurate than either of the Euler methods.

    Even more accurate techniques include Runge-Kutta methods (RK4 being the most famous), various Adams-Bashforth-Moulton methods (ABM3 being the most widely used of these methods), and many, many other techniques.
     
  12. May 31, 2008 #11
    Hello DH,
    I did not want to go into much detail on program concepts, but we are clearly in agreement. I am creating a class for a star object. The class will contain the mass, position and velocity. It will be able to query other star objects for their mass and position, then calculate the imposed acceleration. On the first pass, every star will query every other star to determine a composite acceleration rate. On the second pass, the acceleration will be applied to velocity then to position over the time interval. Then I start over. As you noted, all the processes of initialization, display, calculating accelerations, velocities, and positions will be as independent as possible.

    To your last set of equations. I would like to verify that I understand what you have taken the time to write. I understand that these equations are applied after all the composite accelerations have been calculated. The first of the last four:

    [tex]
    \Delta \mathbf v_1(t) &= \Delta t\,\mathbf f(\mathbf x(t)) \\
    [/tex]

    This says that the change in velocity and a given time is equal to the change in time multiplied by the acceleration rate. The f(x(t)) referring to the earlier discussions in this thread for acceleration.

    Pass 1, part 1: Calculate the acceleration rate (vector) generated by the relationship between each pair of stars.
    Part 2: Determine the angle of the vector
    Part 3: Break the acceleration down into x, y, and z components
    Part 4: Add the components to the current velocity. (delay until pass 2?)

    This does imply that I intend to keep the acceleration and velocity vectors in x, y, and z components rather than a polar type component.

    I think the next three equations are applied in part 2. I will state how I interpret the first one and see where I stand.

    [tex]
    \mathbf x(t+\Delta t) &= \mathbf x(t) + \Delta t(\mathbf v(t) +
    \frac 1\ 2 \mathbf \Delta v_1(t)) \\
    [/tex]

    The new position of the star is equal to:
    The current position + the change in time multiplied by the current velocity + negative 2 times the change in velocity at time t.

    I don’t understand the superscripted 1 in front of the last delta symbol, but I suspect that you really wanted the fraction ½ delta v1 at time t. That would make that phrase: plus one half delta v1 at t.

    As I read this I get the idea that the star object might need to keep the current velocity and acceleration separate from the delta velocities and acceleration until the first step is complete, then I will have both for the second step when applying the acceleration to the current velocity and position.

    I don’t know what the next two equations do yet or how they work together, but I would like to go one stage at a time. When I understand them individually, then, hopefully, I can put them together in my head.
     
  13. May 31, 2008 #12

    D H

    User Avatar
    Staff Emeritus
    Science Advisor

    Hi, kbelly.

    Don't do it this way. This architecture will restrict you to the simplest of integrators. It is much better if the integrator calls the derivative function. This will allow you to advance to integration techniques that are much more accurate the the primitive Euler techniques.

    :blushing: Oops. I wrote too quickly writing and spent even less time reviewing what I wrote.

    Corrected velocity verlet equations:
    [tex]\begin{aligned}
    \Delta \mathbf v_1(t) &= \Delta t\,\mathbf f(\mathbf x(t)) \\
    \mathbf x(t+\Delta t) &= \mathbf x(t) + \Delta t(\mathbf v(t) +
    \frac 1\ 2 \mathbf \Delta v_1(t)) \\
    \Delta \mathbf v_2(t+\Delta t) &= \Delta t\,\mathbf f(\mathbf x(t+\Delta t)) \\
    \mathbf v(t+\Delta t) &= \mathbf v(t) +
    \frac 1 2 (\Delta \mathbf v_1(t) + \Delta \mathbf v_2(t+\Delta t))
    \end{aligned}[/tex]

    In pseudocode, assuming Star contains public members position, velocity, acceleration,
    Code (Text):

    VelocityVerlet::integrate (
       double dt,
       Star * stars,
       int nstars)
    {
       compute_accelerations (stars, nstars);
       for (int ii = 0; ii < nstars; ii++) {
          delta_v1[ii] = dt * stars[ii].acceleration;
          stars[ii].position += deltat *(stars[ii].velocity + 0.5*delta_v1[ii]);
       }
       compute_accelerations (stars, nstars);
       for (int ii = 0; ii < nstars; ii++) {
          delta_v2[ii] = dt * stars[ii].acceleration;
          stars[ii].velocity += 0.5*deltat *(delta_v1[ii] + delta_v2[ii]);
       }
    }
    The velocity verlet integration function evaluates the derivative at the start and end of the integration interval. Note that you can eliminate the first call to the derivative function by calling the derivative function at startup time. (This optimization will not be valid if you add in a general relativistic correction, as the acceleration becomes a function of position and velocity.)

    BTW, here is RK4 (here written with the acceleration function taking position and velocity as inputs):
    [tex]
    \begin{aligned}
    \mathbf x_0 &= \mathbf x(t) \\
    \mathbf v_0 &= \mathbf v(t) \\
    \mathbf a_0 &= \mathbf f(\mathbf x_0, \mathbf v_0) \\
    \mathbf x_1 &= \mathbf x_0 + \frac{\Delta t} 2 \mathbf v_0 \\
    \mathbf v_1 &= \mathbf v_0 + \frac{\Delta t} 2 \mathbf a_0 \\
    \mathbf a_1 &= \mathbf f(\mathbf x_1, \mathbf v_1) \\
    \mathbf x_2 &= \mathbf x_0 + \frac{\Delta t} 2 \mathbf v_1 \\
    \mathbf v_2 &= \mathbf v_0 + \frac{\Delta t} 2 \mathbf a_1 \\
    \mathbf a_2 &= \mathbf f(\mathbf x_2, \mathbf v_2) \\
    \mathbf x_3 &= \mathbf x_0 + \frac{\Delta t} 2 \mathbf v_2 \\
    \mathbf v_3 &= \mathbf v_0 + \frac{\Delta t} 2 \mathbf a_2 \\
    \mathbf a_3 &= \mathbf f(\mathbf x_3, \mathbf v_3)
    \end{aligned}[/tex]

    The updated position and velocity are a weighted average of these intermediate states:

    [tex]
    \begin{aligned}
    \mathbf x(t) &= \mathbf x_0 +
    \frac{\Delta t} 6 (\mathbf v_0 + 2\mathbf v_1 + 2\mathbf v_2 + \mathbf v_3) \\
    \mathbf x(t) &= \mathbf v_0 +
    \frac{\Delta t} 6 (\mathbf a_0 + 2\mathbf a_1 + 2\mathbf a_2 + \mathbf a_3)
    \end{aligned}[/tex]
     
    Last edited: May 31, 2008
  14. Jun 1, 2008 #13
    Originally Posted by bkelly
    On the first pass, every star will query every other star to determine a composite acceleration rate. On the second pass, the acceleration will be applied to velocity then to position over the time interval. Then I start over.

    DH wrote: Don't do it this way. This architecture will restrict you to the simplest of integrators. It is much better if the integrator calls the derivative function. This will allow you to advance to integration techniques that are much more accurate the the primitive Euler techniques.

    As we carry on this discussion I am building the foundation of this program. I have created the basic galactic body class and am working on dialogs to view and enter data. I have not begun the work on calculating the values so I am completely flexible in that regard.

    As I envision this work, I see a list of galactic bodies (i.e. stars). In order to calculate the next step (new velocities and positions), each star must be compared with all the remaining starts to determine the cumulative gravitational effect. It seems to me that I must calculate these gravitational effects for all the stars before I update the position of any star. Otherwise, a star would move in the middle of the calculation and all calculations following that move would be a half breed of two time intervals.

    That is why I see two passes. The first pass determines the force exerted on each star at the beginning of a time interval. The second updates the velocities and positions of each star to what is expected at the end of the interval, which is the starting point of the next interval.

    I can handle the programming part of this, (and do very much appreciate any coding suggestions you provide) but it is very clear that you (and most the people in this forum) know much more about the gravitational and motion equations than I. I am a software/systems engineer, but I had to struggle mightily to pass Calculus Two.

    When you say “It is much better if the integrator calls the derivative function.” I lose track of which calculation you are referring to. Can you back up and state that in more of a layman’s terms.
     
  15. Jun 1, 2008 #14

    D H

    User Avatar
    Staff Emeritus
    Science Advisor

    That is correct.

    This is where I am having an issue. Developing your simulation in this way will inherently constrain you to using a propagator with low accuracy.

    The "derivative function" to which I referred is that function which calculates the accelerations of each star due to gravitational attraction to all of the other stars.

    Here is a suggested architecture:
    Code (Text):

    class Star {
       public:
       double mass;
       double position[3];
       double velocity[3];
       double acceleration[3];
    };

    class Stars {
       Star * stars; // Or some other mechanism (e.g. vector) for storing star data
       int nstars;

       // Initializer function. This function allocates data for the stars and sets each star's
       // mass, initial position, and initial velocity.
       void compute_accelerations();

       // The derivative function. This function computes accelerations for all of the stars.
       void compute_accelerations();
    };

    class Propagator {
       void initialize (Stars & stars);
       void update (Stars & stars);
    };

    void simulation_driver (void)
    {
       Stars stars;
       Propagator propagator;
       Graphics graphics;
       double deltat;
       double time;

       // Initialize the system.
       time = 0.0;
       deltat = ...;
       stars.initialize ();
       propagator.initialize (stars);
       graphics.initialize (stars);

       // Main loop. This loop propagates the stars to the next time step and portrays the
       // updated star positions graphically.
       while (! finished) {
          propagator.update (stars, deltat);
          time += deltat;
          graphics.update (stars);
       }

       // Cleanup code. You should play nice and free memory and other resources.
    }
    Some things to note:
    • All of the accelerations must be computed before any stellar position is updated.
    • The Stars::compute_accelerations method does just this.
    • The Propagator::update method is responsible for computing the accelerations (via stars.compute_accelerations()), not the driver.
    • Whether the propagator calls stars.compute_accelerations() once per time step or more is up to the propagator, not the driver. Better propagators will compute the accelerations multiple times per time step (i.e., one pass through the main loop).
     
  16. Jun 1, 2008 #15
    I don't understand why you say that. My comment further down on classes may clarify.

    Then I take it that the integral part of this operation is to apply the accelerations to produce new velocities and positions. Correct?

    Regarding classes:
    The class encapsulates the parameters of an object, and the methods that operate on those parameters. There is almost never a valid reason for making variables public.

    The glactic object class will contains all the mass, position, and velocity variables. One object will be created for each star. All share the executable code, but do not share any of their variables. The base object contains the code to perform updates. To determine how star 1 is affected by star 2, I will call a procedure in star1 and pass it a pointer to star 2. The star 1 object will then query star 2 for its mass and position. Star 2 will provide a copy of the values it contains for mass and position. The star 1 object will use that data provided by star 2 to to determine the accelerations induced by star 2. The variables contained within any star object are never exposed to access from outside the object.

    A dialog box will provide the means to update values such as initial mass, position, and velocity. That dialog box will call methods of the star object and give those methods the values to update. The class code will make the update with a call typified by:
    Code (Text):
    Star_Pointer->Set_X_Pos( Value );
    The dialog box never directly accesses the internal variables. In this manner, the procedure Set_X_Pos() can examine the values passed in, determine that they are within specified limits, and apply them to the internal variables.

    I browsed around a bit and was not able to find a FAQ or other directions concerning formatting text in posts. Some controls are fairly common such as puting "quote" within brackets, but others are not. Where do I find that information about how to create a code box with and without scroll bars.
     
  17. Jun 1, 2008 #16

    D H

    User Avatar
    Staff Emeritus
    Science Advisor

    Regarding formatting of posts: It always helps to read the FAQ, https://www.physicsforums.com/faq.php. Physics Forums, like many other bulletin boards, uses vB Code, described at https://www.physicsforums.com/misc.php?do=bbcode. For example [noparse]
    Code (Text):
    code ...
    [/noparse] will display the "code ..." as code (monospaced font, etc). The display generator determines whether scrollbars are needed.

    Each thread has a new "New Reply" button displayed near the bottom of the page. You have been you clicking that button. This brings up a form in which you type your response. A set of vBcode shortcut buttons lies above the entry panel. One of these (the "#" button) wraps CODE tags around highlighted text (or creates an empty set of CODE tags if no text was highlighted.)

    One other thing of note: vBcode as-is doesn't display math very well. This is not good for a physics and math forum. This forum displays math written in LaTeX in the form [noparse][tex]LaTeX code ...[/tex][/noparse].
     
  18. Jun 1, 2008 #17

    D H

    User Avatar
    Staff Emeritus
    Science Advisor

    I know about object oriented programming. Unfortunately, it like many other programming paradigms, has a religious aspect to it. The debate over public/private is, to some extent, just religion. We don't condone religious debates at this forum. :biggrin:

    Consider reading the star specifications from a file. The dialog box mechanism is not very good if you want to have more than a handful of stars in the system or if you want to explore variations on a theme (e.g., Monte-Carlo analyses).

    I mentioned this in my previous post. See the hyperlinks I posted there. Regarding code boxes, the user doesn't have control over the presence of scroll bars. The user specifies the content of a code box. The display software determines whether scroll bars need to be used. It adds horizontal scroll bars if the basic code box is too wide, vertical scroll bars if the basic code box is too tall.
     
  19. Jun 1, 2008 #18
    DH wrote:
    I remain concerned about this post as I don’t understand why you say that. I would really like to back up to that point in our conversation and hear what you have to say on this.

    DH wrote:
    Writing from the perspective of a professional engineer with significant experience in writing software that must perform properly and must be maintainable by others, I impose stricter guidelines on the code that I and my peers write than most people do. To me, the guidelines do not take on a religious aspect as they are backed up by evidence. However, as you say, and noting that this is not a programming forum, its best to not go there. I mentioned those items only to provide the concept of the environment in which my class will operate.

    DH wrote:
    An excellent point. Before I go there I want get the simulator running with two, then three or four stars. I will provide some default values for the first few stars. After I get the fundamentals working, then it will be time to add the ability to save simulation parameters to a file and restore them. OTH, even when entering two or three stars, it may well prove tedious and error prone to make the entries by hand. I just may implent the save and restore functions earlier than planned.
     
  20. Jun 1, 2008 #19

    D H

    User Avatar
    Staff Emeritus
    Science Advisor

    So, let's back it up.

    My problem is your wanting to do things in two stages. I took you to mean doing something like this in your driver:
    Code (Text):

    while (! finished) {
       galaxy.compute_acceleration();
       galaxy.update_positions_and_velocities(deltat);
       time += deltat;
       graphics.update(galaxy);
    }
    That is fine for the simplest of propagators, i.e., the Euler methods. The general name for problems of this sort is "initial value problems". An initial value problem comprises the initial state of some set of parameters (in this case, the initial positions and velocities of a bunch of stars) and a set of ordinary differential equations that governs the time evolution of the state of the system (in this case, [itex]\frac{d}{dt}(\mathbf x(t)) = \mathbf v(t)[/itex] and [itex]\frac{d}{dt}(\mathbf v(t)) = \mathbf a_{\text{grav}}(\mathbf x(t))[/itex]. Mathematicians, scientists, and engineers have investigated solving these initial value problems for the past two or three hundred of years or so. Doing things "in two stages" describes the workings of the simplest of techniques. Better techniques do things in multiple stages. If you establish an architecture up-front that accommodates a wide range of techniques, tada, you will be able to use a wide range of techniques to solve the problem. If, on the other hand, you establish an architecture up-front that accommodates only the simplest of techniques, you might will be hard-pressed to move on to better techniques.
     
  21. Jun 1, 2008 #20
    Replying to DHs last post, et al:

    Understood. I did not present a clear picture of my intentions. The basic concept of implementation will have an effect on the outcome so here is a high level pseudo code of the control.

    Please note that my spelling is atrocious. This was edited in Microsoft Word which tends to enforce capitalization rules capriciously. Please ignore any errors of that nature.

    There will be a class called Galactic_Body. It will contain all the variables and code necessary to track the position of a start in simulated space, and calculate and remember the effects of gravity induced by other star. N number of instances of this class will be connected via a linked list for easy traversal.

    After considerable thought I have decided that further details would be inappropriate for this forum. This may already push the limits, but I think DH (and possibly any other reader) will be more comfortable with this conversation if I post this.

    This is an outline of the code that conducts each time interval of the galactic simulator.
    Code (Text):

    Do
    {
          // stage 1
          // get the first body in the list
       Star_pointer = link_root->next;  
       Do
       {
       Star_pointer->Traverse_List_For_Gravity();
       Star_pointer = star_pointer->get_next_body();
       }(until end of list )

           // stage 2
          // get the first body in the list
       Star_pointer = link_root->next;  
       Do
       {
       Star_pointer->Integrate_Acceleration_into_Next_Position();
       Star_pointer = Star_pointer->get_next_body();
       }(until end of list )

    // insert code for housekeeping, update time, iteration counts, etc.
    // insert code to check for operator input, maybe several places

    }(until done);
     
    Within the class is a method to traverse the list of stars, check each star’s position and mass, and calculate the effect of gravity. It will go something like this.
    Code (Text):

    Void Traverse_List_For_Gravity()
    {
    Other_pointer = link_root->next;
    Do
       {
          If( Other_pointer == me) continue;
             // structure Other_body is a local structure for temporary storage of the values
             // retrieved from the other body.
          Other_body.mass = Other_pointer->query_mass();
          Other_body.position = Other_pointer->query_position();
          Calculate_gravitational_effect();
          Other_pointer = Other_pointer->next;
       }(until end of list);
    } // end of function
     
    Now to the function that seems to be of primary importance:
    Code (Text):

       Star_pointer->Integrate_Acceleration_into_Next_Position();
     
    This is the essence of what I am referring to as stage two of a single time interval. This function, contained within the Galactic_Body class, can be as simple or as complex as desired. Within this function, the code can iterate through the data as many times as necessary. If the time interval is one hour, it could calculate intermediate values for each second. I can start with an overly simple function, then change it as desired. Other than consuming time, changes to this function will have no effect on the remainder of the program.

    After the first stage, each body will be aware of the gravitational effect from each other body, but will not have implemented any positional changes. Then the second stage begins and does the positional updates. (I think velocity can be calculated in stage 1, but am not certain.) The concepts to be implemented in method Integrate_Acceleration_into_Next_Position(); is where I need help.

    Now the proximate question becomes, does this resolve the questions that the reader may have with my method? Or does it show a flaw in how I plan on conducting the simulation?

    In the meantime, I am new to Visual Studio and having difficulties in getting the framework operational. I will be working that and looking at the equations already presented.

    I do wish to say to DH, Your comments have been extraordinarily helpful. I am aware of and appreciative of the time you have consumed in answering my questions.
    Thank you.
     
Know someone interested in this topic? Share this thread via Reddit, Google+, Twitter, or Facebook

Have something to add?



Similar Discussions: Gravitation attraction proportioned
  1. Gravitational attraction (Replies: 19)

Loading...