Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > sci.physics.relativity > #384218 > unrolled thread

Interesting problem

Back to article view | Back to sci.physics.relativity

Contents

  Interesting problem "HGWilson, DSc." <hgw@....> - 2016-05-26 07:05 +1000
    Re: Interesting problem Poutnik <poutnik4nntp@gmail.com> - 2016-05-25 23:17 +0200
      Re: Interesting problem "David (Time Lord) Fuller" <fuller.david@hotmail.com> - 2016-05-25 14:20 -0700
    Re: Interesting problem "David (Time Lord) Fuller" <fuller.david@hotmail.com> - 2016-05-25 14:18 -0700
    Re: Interesting problem Odd Bodkin <bodkinodd@gmail.com> - 2016-05-25 16:20 -0500
      Re: Interesting problem Tom Roberts <tjroberts137@sbcglobal.net> - 2016-05-25 18:31 -0500
      Re: Interesting problem "HGWilson, DSc." <hgw@....> - 2016-05-27 03:25 +1000
        Re: Interesting problem Odd Bodkin <bodkinodd@gmail.com> - 2016-05-26 13:32 -0500
          Re: Interesting problem HGW <hw@...> - 2016-05-27 12:15 +1000
            Re: Interesting problem Odd Bodkin <bodkinodd@gmail.com> - 2016-05-27 04:26 -0500
              Re: Interesting problem "HGWilson, DSc." <hgw@....> - 2016-05-27 19:52 +1000
                Re: Interesting problem Odd Bodkin <bodkinodd@gmail.com> - 2016-05-27 05:46 -0500
                  Re: Interesting problem "HGWilson, DSc." <hgw@....> - 2016-05-27 21:55 +1000
                    Re: Interesting problem Odd Bodkin <bodkinodd@gmail.com> - 2016-05-27 07:23 -0500
                      Re: Interesting problem Odd Bodkin <bodkinodd@gmail.com> - 2016-05-27 07:26 -0500
                      Re: Interesting problem "David (Time Lord) Fuller" <fuller.david@hotmail.com> - 2016-05-27 05:29 -0700
                      Re: Interesting problem "HGWilson, DSc." <hgw@....> - 2016-05-28 19:47 +1000
                        Re: Interesting problem Prokaryotic Caspase Homolog <prokaryotic.caspase.homolog@gmail.com> - 2016-05-28 04:12 -0700
                          Re: Interesting problem Prokaryotic Caspase Homolog <prokaryotic.caspase.homolog@gmail.com> - 2016-05-28 04:51 -0700
                            Re: Interesting problem alsor@interia.pl - 2016-05-28 11:27 -0700
                              Re: Interesting problem Prokaryotic Caspase Homolog <prokaryotic.caspase.homolog@gmail.com> - 2016-05-28 14:01 -0700
                                Re: Interesting problem alsor@interia.pl - 2016-05-28 15:10 -0700
                              Re: Interesting problem "HGWilson, DSc." <hgw@....> - 2016-05-29 09:35 +1000
                                Re: Interesting problem alsor@interia.pl - 2016-05-29 10:35 -0700
                                  Re: Interesting problem "HGWilson, DSc." <hgw@....> - 2016-05-30 07:01 +1000
                                    Re: Interesting problem Prokaryotic Caspase Homolog <prokaryotic.caspase.homolog@gmail.com> - 2016-05-29 15:22 -0700
                                      Re: Interesting problem alsor@interia.pl - 2016-05-30 13:05 -0700
                                    Re: Interesting problem alsor@interia.pl - 2016-05-30 16:27 -0700
                                      Re: Interesting problem "HGWilson, DSc." <hgw@....> - 2016-05-31 20:56 +1000
                                        Re: Interesting problem alsor@interia.pl - 2016-05-31 08:40 -0700
                                          Re: Interesting problem HGW <hw@...> - 2016-06-02 09:40 +1000
                                            Re: Interesting problem alsor@interia.pl - 2016-06-02 11:53 -0700
                                      Re: Interesting problem Prokaryotic Caspase Homolog <prokaryotic.caspase.homolog@gmail.com> - 2016-05-31 04:25 -0700
                                        Re: Interesting problem mlwozniak@wp.pl - 2016-05-31 04:58 -0700
                                          Re: Interesting problem "HGWilson, DSc." <hgw@....> - 2016-06-01 06:31 +1000
                                            Re: Interesting problem Odd Bodkin <bodkinodd@gmail.com> - 2016-05-31 16:30 -0500
                                              Re: Interesting problem HGW <hw@...> - 2016-06-02 09:44 +1000
                                            Re: Interesting problem JanPB <filmart@gmail.com> - 2016-05-31 14:58 -0700
                                        Re: Interesting problem "HGWilson, DSc." <hgw@....> - 2016-06-01 06:24 +1000
                                          Re: Interesting problem Prokaryotic Caspase Homolog <prokaryotic.caspase.homolog@gmail.com> - 2016-06-01 06:23 -0700
                                            Re: Interesting problem Odd Bodkin <bodkinodd@gmail.com> - 2016-06-01 11:11 -0500
                                              Re: Interesting problem HGW <hw@...> - 2016-06-02 09:47 +1000
                                            Re: Interesting problem Prokaryotic Caspase Homolog <prokaryotic.caspase.homolog@gmail.com> - 2016-06-01 18:50 -0700
                                              Re: Interesting problem alsor@interia.pl - 2016-06-02 12:07 -0700
                                          Re: Interesting problem alsor@interia.pl - 2016-06-01 08:59 -0700
                                            Re: Interesting problem HGW <hw@...> - 2016-06-02 10:09 +1000
                        Re: Interesting problem Odd Bodkin <bodkinodd@gmail.com> - 2016-05-29 13:52 -0500
                          Re: Interesting problem "HGWilson, DSc." <hgw@....> - 2016-05-30 07:09 +1000
                            Re: Interesting problem Sam Wormley <swormley1@gmail.com> - 2016-05-29 16:26 -0500
                              Re: Interesting problem Fabian Russell <fb@zen.info> - 2016-05-30 04:25 +0000
                              Re: Interesting problem "HGWilson, DSc." <hgw@....> - 2016-05-31 21:00 +1000
                                Re: Interesting problem Fabian Russell <fb@zen.info> - 2016-05-31 22:46 +0000
                                  Re: Interesting problem HGW <hw@...> - 2016-06-02 09:32 +1000
                    Re: Interesting problem Prokaryotic Caspase Homolog <prokaryotic.caspase.homolog@gmail.com> - 2016-05-27 05:34 -0700
                      Re: Interesting problem "David (Time Lord) Fuller" <fuller.david@hotmail.com> - 2016-05-27 05:40 -0700
                        Re: Interesting problem "David (Time Lord) Fuller" <fuller.david@hotmail.com> - 2016-05-27 05:43 -0700
                      Re: Interesting problem rotchm <rotchm@gmail.com> - 2016-05-27 06:40 -0700
                        Re: Interesting problem Prokaryotic Caspase Homolog <prokaryotic.caspase.homolog@gmail.com> - 2016-05-27 07:42 -0700
                    Re: Interesting problem rotchm <rotchm@gmail.com> - 2016-05-27 06:36 -0700
                      Re: Interesting problem Odd Bodkin <bodkinodd@gmail.com> - 2016-05-27 09:01 -0500
                        Re: Interesting problem "HGWilson, DSc." <hgw@....> - 2016-05-28 20:04 +1000
                          Re: Interesting problem Prokaryotic Caspase Homolog <prokaryotic.caspase.homolog@gmail.com> - 2016-05-28 04:34 -0700
      Re: Interesting problem Fabian Russell <fb@zen.info> - 2016-05-27 22:03 +0000
        Re: Interesting problem "HGWilson, DSc." <hgw@....> - 2016-05-28 20:10 +1000

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#384516

On Saturday, May 28, 2016 at 1:27:54 PM UTC-5, al...@interia.pl wrote:
> W dniu sobota, 28 maja 2016 13:51:15 UTC+2 użytkownik Prokaryotic Caspase Homolog napisał:

> > Speaking of problems, have you had a chance to see whether you could adapt
> > the RK4 code that I posted to your three-body simulation?
> > https://groups.google.com/d/msg/sci.physics.relativity/mOK4P9IC5zY/2b5d63W6CQAJ
> > 
> > I'm really interested in seeing the improvement. Using a second-order method, I
> > could simulate 250000 weeks of the effects of Venus on Mercury's precession in
> > a reasonable period without an unacceptable amount of accumulated error. With
> > RK4, I ran the simulation for nearly 1000000 weeks but accidentally terminated
> > the session. 
> > 
> > My next refinement will be Runga Kutta Fehlberg, since that allows step sizes
> > that automatically adjust themselves.
> 
> You probably omited the fact:
> even a simple summation of many numbers preduces a big error!
> 
> What is a numerical integration?
> 
> It's just a long summation in fact!
> 
> r(i+1) = r(i) + v(i)*dt + a(t)*t^2/2 + ...
> 
> so, after 100 years of the simulation,
> with a step size, say: dt = 10 mniutes,
> any algoriyhm of integration must sum up billions of numbers!
> 
> 1 day = 1440 minutes;
> 1 year = 365.25 x 1440 = 525960 minutes
> 100 years = 52596000 minutes
> 
> So, for a time step size: dt = 10 minutes,
> the algorithm must make 5259600 steps,
> and in every step it makes still about 10 operations, or more...
> 
> And even for a simple summation, the final error can be gigantic:
> 
> http://en.wikipedia.org/wiki/Kahan_summation_algorithm

I am very aware of such considerations. "Real" long-term planetary simulations
use iterative methods from 8th to 12th order and, depending on the available
hardware, extended precision formats from 80 to 128 bits.

It is not easy to devise high order integrators. They tend to suffer from
instability, and the design of *consistent* high order RK methods in particular
requires consideration of a large number of order condition issues. 

Furthermore, with current processors, very important considerations include how
amenable a candidate method is to a parallel implementation and whether a given
algorithm is adaptive. Many published high order integrators have been observed
to fail when subject to stringent stress testing.

When you previously bragged about being able to devise 16 and 30 order 
integrators, you were displaying your ignorance *much* more than anything else.
Try researching a topic before flaunting your dismal lack of background
knowledge.

[toc] | [prev] | [next] | [standalone]

#384518

W dniu sobota, 28 maja 2016 23:01:39 UTC+2 użytkownik Prokaryotic Caspase Homolog

> I am very aware of such considerations. "Real" long-term planetary simulations
> use iterative methods from 8th to 12th order and, depending on the available
> hardware, extended precision formats from 80 to 128 bits.

Good. But You are still unaware, together with others,
of the error growuth in the Kepler problem simulation.

There the of the radial distance is in fact tiny,
for any standard integrator...
but what is the error is a phase - angle?

Unfortunately, this error grows quadraticaly in fact!

error = n^2.eps, where n = number of steps.
 
> When you previously bragged about being able to devise 16 and 30 order 
> integrators, you were displaying your ignorance *much* more than anything else.
> Try researching a topic before flaunting your dismal lack of background
> knowledge.

I use the extrapolated integration methods,
and in this type of method the order is no problem...

Simply:
take a metod of order n, and next compute
two times the same using this, but with different steps.

Now you only combine these two results and get the better one - 2 orders higher.

Look at this:
http://arxiv.org/pdf/0809.0914.pdf

There is a simple 2-order integrator only at start,
and extrapolated several times, you can get any order of method...
up to 100, and more:

4 - order - 1 extrapolation
6 - order - 2 extrapolations
...
10-order method: 4 extrapolations of the primitive 2-nd order method.

[toc] | [prev] | [next] | [standalone]

#384522

On 29/05/16 04:27, alsor@interia.pl wrote:
> W dniu sobota, 28 maja 2016 13:51:15 UTC+2 użytkownik Prokaryotic Caspase Homolog napisał:

>
> You probably omited the fact:
> even a simple summation of many numbers preduces a big error!
>
> What is a numerical integration?
>
> It's just a long summation in fact!
>
> r(i+1) = r(i) + v(i)*dt + a(t)*t^2/2 + ...
>
> so, after 100 years of the simulation,
> with a step size, say: dt = 10 mniutes,
> any algoriyhm of integration must sum up billions of numbers!
>
> 1 day = 1440 minutes;
> 1 year = 365.25 x 1440 = 525960 minutes
> 100 years = 52596000 minutes
>
> So, for a time step size: dt = 10 minutes,
> the algorithm must make 5259600 steps,
> and in every step it makes still about 10 operations, or more...
>
> And even for a simple summation, the final error can be gigantic:
>
> http://en.wikipedia.org/wiki/Kahan_summation_algorithm

I actually create ellipses by iterating Newton's force equation and they 
are sufficiently accurate over one orbit for brightness curve 
simulation. (using about 40000 points) The operation takes a fraction of 
a second on a pretty fast PC. Over many cycles, the generated orbit 
naturally precesses, which made me wonder if the integration 'error' is 
actually simulating the finite speed of gravity, which in turn could 
conceivably be a contributing factor in planetary precession.

[toc] | [prev] | [next] | [standalone]

#384555

W dniu niedziela, 29 maja 2016 01:35:27 UTC+2 użytkownik HGWilson, DSc. napisał:

> I actually create ellipses by iterating Newton's force equation and they 
> are sufficiently accurate over one orbit for brightness curve 
> simulation. (using about 40000 points) The operation takes a fraction of 
> a second on a pretty fast PC. Over many cycles, the generated orbit 
> naturally precesses, which made me wonder if the integration 'error' is 
> actually simulating the finite speed of gravity, which in turn could 
> conceivably be a contributing factor in planetary precession.

Yes. The problem with the artificially generated precession,
during numerical integration is well known... for the experts of the numerics methods.

This artifical precession goes backward usually,
thus it decreases the real precession... in the many-body problem simulaion.

[toc] | [prev] | [next] | [standalone]

#384574

On 30/05/16 03:35, alsor@interia.pl wrote:
> W dniu niedziela, 29 maja 2016 01:35:27 UTC+2 użytkownik HGWilson, DSc. napisał:
>
>> I actually create ellipses by iterating Newton's force equation and they
>> are sufficiently accurate over one orbit for brightness curve
>> simulation. (using about 40000 points) The operation takes a fraction of
>> a second on a pretty fast PC. Over many cycles, the generated orbit
>> naturally precesses, which made me wonder if the integration 'error' is
>> actually simulating the finite speed of gravity, which in turn could
>> conceivably be a contributing factor in planetary precession.
>
> Yes. The problem with the artificially generated precession,
> during numerical integration is well known... for the experts of the numerics methods.
>
> This artifical precession goes backward usually,
> thus it decreases the real precession... in the many-body problem simulaion.

Is there a way to correct the error?

In the x direction, the simplest iteration for each time unit uses
v=v+a: x=x+v: a= fn(x), (same for y), repeat

That can generate quite accurate ellipses.....but the ends do not quite 
match. Is it possible to make an exact correction so they will?





>

[toc] | [prev] | [next] | [standalone]

#384579

On Sunday, May 29, 2016 at 4:01:07 PM UTC-5, HGWilson, DSc. wrote:
> On 30/05/16 03:35, alsor@interia.pl wrote:
> > W dniu niedziela, 29 maja 2016 01:35:27 UTC+2 użytkownik HGWilson, DSc. napisał:
> >
> >> I actually create ellipses by iterating Newton's force equation and they
> >> are sufficiently accurate over one orbit for brightness curve
> >> simulation. (using about 40000 points) The operation takes a fraction of
> >> a second on a pretty fast PC. Over many cycles, the generated orbit
> >> naturally precesses, which made me wonder if the integration 'error' is
> >> actually simulating the finite speed of gravity, which in turn could
> >> conceivably be a contributing factor in planetary precession.
> >
> > Yes. The problem with the artificially generated precession,
> > during numerical integration is well known... for the experts of the numerics methods.
> >
> > This artifical precession goes backward usually,
> > thus it decreases the real precession... in the many-body problem simulaion.
> 
> Is there a way to correct the error?
> 
> In the x direction, the simplest iteration for each time unit uses
> v=v+a: x=x+v: a= fn(x), (same for y), repeat
> 
> That can generate quite accurate ellipses.....but the ends do not quite 
> match. Is it possible to make an exact correction so they will?

You are essentially using Euler's method, a first order integration method.

Switch to a more accurate algorithm. I have provided you with source code for
implementing RK4 that should be extremely easy to adapt to Visual Basic:
https://groups.google.com/d/msg/sci.physics.relativity/mOK4P9IC5zY/2b5d63W6CQAJ 

[toc] | [prev] | [next] | [standalone]

#384620

W dniu poniedziałek, 30 maja 2016 00:22:27 UTC+2 użytkownik Prokaryotic Caspase Homolog

> You are essentially using Euler's method, a first order integration method.
> 
> Switch to a more accurate algorithm. I have provided you with source code for
> implementing RK4 that should be extremely easy to adapt to Visual Basic:
> https://groups.google.com/d/msg/sci.physics.relativity/mOK4P9IC5zY/2b5d63W6CQAJ

You are very nive.

The 4-order methods introduce the artificial precession too!

And ever worse because the precession is constant,
for a small time step h!

http://arxiv.org/pdf/0809.0914.pdf

formula for the artificial precession of 4-order method integrator (38):
lim df / h^4 = const; for h -> 0.

So, You cant avoid this artifact...
even increasing the precission of the numbers to quadruple, octets, ... any!

[toc] | [prev] | [next] | [standalone]

#384624

W dniu niedziela, 29 maja 2016 23:01:07 UTC+2 użytkownik HGWilson, DSc. napisał:
> On 30/05/16 03:35, alsor@interia.pl wrote:
> > W dniu niedziela, 29 maja 2016 01:35:27 UTC+2 użytkownik HGWilson, DSc. napisał:
> >
> >> I actually create ellipses by iterating Newton's force equation and they
> >> are sufficiently accurate over one orbit for brightness curve
> >> simulation. (using about 40000 points) The operation takes a fraction of
> >> a second on a pretty fast PC. Over many cycles, the generated orbit
> >> naturally precesses, which made me wonder if the integration 'error' is
> >> actually simulating the finite speed of gravity, which in turn could
> >> conceivably be a contributing factor in planetary precession.
> >
> > Yes. The problem with the artificially generated precession,
> > during numerical integration is well known... for the experts of the numerics methods.
> >
> > This artifical precession goes backward usually,
> > thus it decreases the real precession... in the many-body problem simulaion.
> 
> Is there a way to correct the error?
> 
> In the x direction, the simplest iteration for each time unit uses
> v=v+a: x=x+v: a= fn(x), (same for y), repeat
> 
> That can generate quite accurate ellipses.....but the ends do not quite 
> match. Is it possible to make an exact correction so they will?

There are some special methods to reduce this 'numerical' precession..
for example the force-gradient metods.
http://arxiv.org/pdf/1602.01049.pdf

the best "C" method :
http://arxiv.org/pdf/physics/0006082.pdf
(21)

it looks like this in my C++ version:
void grad4()
{

     h = dt;
     h2 = h*f_half;
     double h6 = h/6;

     force(a,y,nB);  

	 //   v1 = v + a*h/6; r1 = r + v1 h/2;
     for(int i = 0; i < nB; i++)
      {
         y[i].v.addm(a[i],   h6); // y[i].v += a[i]*h6
         y[i].r.addm(y[i].v, h2); // y[i].r += v[i]*h2
      }

     forceg(a, y, sqr(h)/12); // g + h^2/48 grad(g^2); grad g^2 = 4 g^2 ...
     //   v2 = v1 + a*h 2/3; r1 = r1 + v2 h/2;
     for(int i = 0; i < nB; i++)
      {
         y[i].v.addm(a[i], h*(2.0/3));
         y[i].r.addm(y[i].v, h2);
      }
     
     force(a,y,nB);
     for(int i = 0; i < nB; i++)
      {
         y[i].v.addm(a[i], h6);
      }
}

[toc] | [prev] | [next] | [standalone]

#384637

On 31/05/16 09:27, alsor@interia.pl wrote:
> W dniu niedziela, 29 maja 2016 23:01:07 UTC+2 użytkownik HGWilson, DSc. napisał:
>> On 30/05/16 03:35, alsor@interia.pl wrote:
>>> W dniu niedziela, 29 maja 2016 01:35:27 UTC+2 użytkownik HGWilson, DSc. napisał:
>>>
>>>> I actually create ellipses by iterating Newton's force equation and they
>>>> are sufficiently accurate over one orbit for brightness curve
>>>> simulation. (using about 40000 points) The operation takes a fraction of
>>>> a second on a pretty fast PC. Over many cycles, the generated orbit
>>>> naturally precesses, which made me wonder if the integration 'error' is
>>>> actually simulating the finite speed of gravity, which in turn could
>>>> conceivably be a contributing factor in planetary precession.
>>>
>>> Yes. The problem with the artificially generated precession,
>>> during numerical integration is well known... for the experts of the numerics methods.
>>>
>>> This artifical precession goes backward usually,
>>> thus it decreases the real precession... in the many-body problem simulaion.
>>
>> Is there a way to correct the error?
>>
>> In the x direction, the simplest iteration for each time unit uses
>> v=v+a: x=x+v: a= fn(x), (same for y), repeat
>>
>> That can generate quite accurate ellipses.....but the ends do not quite
>> match. Is it possible to make an exact correction so they will?
>
> There are some special methods to reduce this 'numerical' precession..
> for example the force-gradient metods.
> http://arxiv.org/pdf/1602.01049.pdf
>

>        }
>
>       forceg(a, y, sqr(h)/12); // g + h^2/48 grad(g^2); grad g^2 = 4 g^2 ...
>       //   v2 = v1 + a*h 2/3; r1 = r1 + v2 h/2;
>       for(int i = 0; i < nB; i++)
>        {
>           y[i].v.addm(a[i], h*(2.0/3));
>           y[i].r.addm(y[i].v, h2);
>        }
>
>       force(a,y,nB);
>       for(int i = 0; i < nB; i++)
>        {
>           y[i].v.addm(a[i], h6);
>        }
> }

I think there might be an easier and more straightforward way using 
computers but it might be a bit slower. Knowing the final error after 
one cycle, it should be possible to empirically correct each step until 
the error disappears.

[toc] | [prev] | [next] | [standalone]

#384655

W dniu wtorek, 31 maja 2016 12:55:54 UTC+2 użytkownik HGWilson, DSc. napisał:
> On 31/05/16 09:27, alsor@interia.pl wrote:
> > W dniu niedziela, 29 maja 2016 23:01:07 UTC+2 użytkownik HGWilson, DSc. napisał:
> >> On 30/05/16 03:35, alsor@interia.pl wrote:
> >>> W dniu niedziela, 29 maja 2016 01:35:27 UTC+2 użytkownik HGWilson, DSc. napisał:
> >>>
> >>>> I actually create ellipses by iterating Newton's force equation and they
> >>>> are sufficiently accurate over one orbit for brightness curve
> >>>> simulation. (using about 40000 points) The operation takes a fraction of
> >>>> a second on a pretty fast PC. Over many cycles, the generated orbit
> >>>> naturally precesses, which made me wonder if the integration 'error' is
> >>>> actually simulating the finite speed of gravity, which in turn could
> >>>> conceivably be a contributing factor in planetary precession.
> >>>
> >>> Yes. The problem with the artificially generated precession,
> >>> during numerical integration is well known... for the experts of the numerics methods.
> >>>
> >>> This artifical precession goes backward usually,
> >>> thus it decreases the real precession... in the many-body problem simulaion.
> >>
> >> Is there a way to correct the error?
> >>
> >> In the x direction, the simplest iteration for each time unit uses
> >> v=v+a: x=x+v: a= fn(x), (same for y), repeat
> >>
> >> That can generate quite accurate ellipses.....but the ends do not quite
> >> match. Is it possible to make an exact correction so they will?
> >
> > There are some special methods to reduce this 'numerical' precession..
> > for example the force-gradient metods.
> > http://arxiv.org/pdf/1602.01049.pdf
> >
> 
> >        }
> >
> >       forceg(a, y, sqr(h)/12); // g + h^2/48 grad(g^2); grad g^2 = 4 g^2 ...
> >       //   v2 = v1 + a*h 2/3; r1 = r1 + v2 h/2;
> >       for(int i = 0; i < nB; i++)
> >        {
> >           y[i].v.addm(a[i], h*(2.0/3));
> >           y[i].r.addm(y[i].v, h2);
> >        }
> >
> >       force(a,y,nB);
> >       for(int i = 0; i < nB; i++)
> >        {
> >           y[i].v.addm(a[i], h6);
> >        }
> > }
> 
> I think there might be an easier and more straightforward way using 
> computers but it might be a bit slower. Knowing the final error after 
> one cycle, it should be possible to empirically correct each step until 
> the error disappears.

This method has order of 4, thus it's thousands
times faster than any 2-order, like the Euler-Cromer, Verlet, Frog, etc.


Simply: use a bigger time step for higher order method.

for 4-order optimal step is about: h = 1/1000 of the orbital period,
thus for Mercury it's 88days/1000 =~ day / 12 = 2 hours.


for 2-order the step should be squared:
h = 1/1000000... = 7 seconds for this case!
4/2 = 2.

[toc] | [prev] | [next] | [standalone]

#384802

On 01/06/16 01:40, alsor@interia.pl wrote:
> W dniu wtorek, 31 maja 2016 12:55:54 UTC+2 użytkownik HGWilson, DSc. napisał:
>> On 31/05/16 09:27, alsor@interia.pl wrote:
>>> W dniu niedziela, 29 maja 2016 23:01:07 UTC+2 użytkownik HGWilson, DSc. napisał:
>>
>>>        forceg(a, y, sqr(h)/12); // g + h^2/48 grad(g^2); grad g^2 = 4 g^2 ...
>>>        //   v2 = v1 + a*h 2/3; r1 = r1 + v2 h/2;
>>>        for(int i = 0; i < nB; i++)
>>>         {
>>>            y[i].v.addm(a[i], h*(2.0/3));
>>>            y[i].r.addm(y[i].v, h2);
>>>         }
>>>
>>>        force(a,y,nB);
>>>        for(int i = 0; i < nB; i++)
>>>         {
>>>            y[i].v.addm(a[i], h6);
>>>         }
>>> }
>>
>> I think there might be an easier and more straightforward way using
>> computers but it might be a bit slower. Knowing the final error after
>> one cycle, it should be possible to empirically correct each step until
>> the error disappears.
>
> This method has order of 4, thus it's thousands
> times faster than any 2-order, like the Euler-Cromer, Verlet, Frog, etc.
>
>
> Simply: use a bigger time step for higher order method.
>
> for 4-order optimal step is about: h = 1/1000 of the orbital period,
> thus for Mercury it's 88days/1000 =~ day / 12 = 2 hours.
>
>
> for 2-order the step should be squared:
> h = 1/1000000... = 7 seconds for this case!
> 4/2 = 2.

The iteration time interval can be easily adjusted in my current method. 
I have found that about 40000 points produces a pretty accurate ellipse. 
But not good enough to simulate precession.
I reckon I can reduce that error to near zero by applying a simple 
correction at each point.
....no complicated equations...just programming factors.

[toc] | [prev] | [next] | [standalone]

#384854

W dniu czwartek, 2 czerwca 2016 01:40:44 UTC+2 użytkownik HGW napisał:
> On 01/06/16 01:40, alsor@interia.pl wrote:
> > W dniu wtorek, 31 maja 2016 12:55:54 UTC+2 użytkownik HGWilson, DSc. napisał:
> >> On 31/05/16 09:27, alsor@interia.pl wrote:
> >>> W dniu niedziela, 29 maja 2016 23:01:07 UTC+2 użytkownik HGWilson, DSc. napisał:
> >>
> >>>        forceg(a, y, sqr(h)/12); // g + h^2/48 grad(g^2); grad g^2 = 4 g^2 ...
> >>>        //   v2 = v1 + a*h 2/3; r1 = r1 + v2 h/2;
> >>>        for(int i = 0; i < nB; i++)
> >>>         {
> >>>            y[i].v.addm(a[i], h*(2.0/3));
> >>>            y[i].r.addm(y[i].v, h2);
> >>>         }
> >>>
> >>>        force(a,y,nB);
> >>>        for(int i = 0; i < nB; i++)
> >>>         {
> >>>            y[i].v.addm(a[i], h6);
> >>>         }
> >>> }
> >>
> >> I think there might be an easier and more straightforward way using
> >> computers but it might be a bit slower. Knowing the final error after
> >> one cycle, it should be possible to empirically correct each step until
> >> the error disappears.
> >
> > This method has order of 4, thus it's thousands
> > times faster than any 2-order, like the Euler-Cromer, Verlet, Frog, etc.
> >
> >
> > Simply: use a bigger time step for higher order method.
> >
> > for 4-order optimal step is about: h = 1/1000 of the orbital period,
> > thus for Mercury it's 88days/1000 =~ day / 12 = 2 hours.
> >
> >
> > for 2-order the step should be squared:
> > h = 1/1000000... = 7 seconds for this case!
> > 4/2 = 2.
> 
> The iteration time interval can be easily adjusted in my current method. 
> I have found that about 40000 points produces a pretty accurate ellipse. 
> But not good enough to simulate precession.
> I reckon I can reduce that error to near zero by applying a simple 
> correction at each point.
> ....no complicated equations...just programming factors.

There is no problem to draw an allipse...

[toc] | [prev] | [next] | [standalone]

#384639

On Monday, May 30, 2016 at 6:27:19 PM UTC-5, al...@interia.pl wrote:
> W dniu niedziela, 29 maja 2016 23:01:07 UTC+2 użytkownik HGWilson, DSc. napisał:

> > Is there a way to correct the error?
> > 
> > In the x direction, the simplest iteration for each time unit uses
> > v=v+a: x=x+v: a= fn(x), (same for y), repeat
> > 
> > That can generate quite accurate ellipses.....but the ends do not quite 
> > match. Is it possible to make an exact correction so they will?
> 
> There are some special methods to reduce this 'numerical' precession..
> for example the force-gradient metods.
> http://arxiv.org/pdf/1602.01049.pdf
> 
> the best "C" method :
> http://arxiv.org/pdf/physics/0006082.pdf
> (21)
> 
> it looks like this in my C++ version:
> void grad4()
> {
> 
>      h = dt;
>      h2 = h*f_half;
>      double h6 = h/6;
> 
>      force(a,y,nB);  
> 
> 	 //   v1 = v + a*h/6; r1 = r + v1 h/2;
>      for(int i = 0; i < nB; i++)
>       {
>          y[i].v.addm(a[i],   h6); // y[i].v += a[i]*h6
>          y[i].r.addm(y[i].v, h2); // y[i].r += v[i]*h2
>       }
> 
>      forceg(a, y, sqr(h)/12); // g + h^2/48 grad(g^2); grad g^2 = 4 g^2 ...
>      //   v2 = v1 + a*h 2/3; r1 = r1 + v2 h/2;
>      for(int i = 0; i < nB; i++)
>       {
>          y[i].v.addm(a[i], h*(2.0/3));
>          y[i].r.addm(y[i].v, h2);
>       }
>      
>      force(a,y,nB);
>      for(int i = 0; i < nB; i++)
>       {
>          y[i].v.addm(a[i], h6);
>       }
> }

If you want to help Henry, you need to provide a COMPLETE code sample with all
input and output variables documented and all dependencies accounted for.
Missing external dependencies include force(), forceg(), addm()

As it stands, your code snipped is unusable.

Henry, please try using a PROVEN solution instead of attempting to make up your
own ad hoc fix. Many, many people have devoted thousands of man-years in the
development of accurate, reliable and stable techniques for numerically solving
differential equations.

[toc] | [prev] | [next] | [standalone]

#384641

W dniu wtorek, 31 maja 2016 13:25:04 UTC+2 użytkownik Prokaryotic Caspase Homolog napisał:

> Henry, please try using a PROVEN solution instead of attempting to make up your
> own ad hoc fix. Many, many people have devoted thousands of man-years in the
> development of accurate, reliable and stable techniques for numerically solving
> differential equations.

See, the same can be told about euclidean geometry,
and your idiot guru rejected it anyway.

[toc] | [prev] | [next] | [standalone]

#384692

On 31/05/16 21:58, mlwozniak@wp.pl wrote:
> W dniu wtorek, 31 maja 2016 13:25:04 UTC+2 użytkownik Prokaryotic Caspase Homolog napisał:
>
>> Henry, please try using a PROVEN solution instead of attempting to make up your
>> own ad hoc fix. Many, many people have devoted thousands of man-years in the
>> development of accurate, reliable and stable techniques for numerically solving
>> differential equations.
>
> See, the same can be told about euclidean geometry,
> and your idiot guru rejected it anyway.

Those theoretical physicists/mathematicians have mmade physics so 
difficult that no kids want to take it up any more. One cannot blame 
them when there are so many logical errors in the first paragraphs of 
theories like Einstein's. His RoS on which it is reliant is 
fundamentally flawed. The devious plagiarizing bastard didn't specify 
the light sources that were to be used. Again, the 'light clock' idea as 
it is taught is completely wrong. Sagnac, the MMX...etc., The list of 
blunders goes on......

[toc] | [prev] | [next] | [standalone]

#384696

On 5/31/2016 3:31 PM, HGWilson, DSc. wrote:
> Those theoretical physicists/mathematicians have mmade physics so
> difficult that no kids want to take it up any more.

You underestimate students, I believe. There seems to be no drop in the 
number of physics PhDs over the last two decades, if you'll actually 
look at stats. Nor is there a drop in undergraduate degrees with physics 
declared as a major.

Now I believe your chief complaint is that it is too complicated for 
YOU, and you find that offensive. You'd like physics to be high-school-easy.

> One cannot blame
> them when there are so many logical errors in the first paragraphs of
> theories like Einstein's. His RoS on which it is reliant is
> fundamentally flawed. The devious plagiarizing bastard didn't specify
> the light sources that were to be used. Again, the 'light clock' idea as
> it is taught is completely wrong. Sagnac, the MMX...etc., The list of
> blunders goes on......


-- 
Odd Bodkin --- maker of fine toys, tools, tables

[toc] | [prev] | [next] | [standalone]

#384803

On 01/06/16 07:30, Odd Bodkin wrote:
> On 5/31/2016 3:31 PM, HGWilson, DSc. wrote:
>> Those theoretical physicists/mathematicians have mmade physics so
>> difficult that no kids want to take it up any more.
>
> You underestimate students, I believe. There seems to be no drop in the
> number of physics PhDs over the last two decades, if you'll actually
> look at stats. Nor is there a drop in undergraduate degrees with physics
> declared as a major.
>
> Now I believe your chief complaint is that it is too complicated for
> YOU, and you find that offensive. You'd like physics to be
> high-school-easy.

I certainly do like physics to be PHYSICS and not meaningless 
mathemagics based on fallacies.

>> One cannot blame
>> them when there are so many logical errors in the first paragraphs of
>> theories like Einstein's. His RoS on which it is reliant is
>> fundamentally flawed. The devious plagiarizing bastard didn't specify
>> the light sources that were to be used. Again, the 'light clock' idea as
>> it is taught is completely wrong. Sagnac, the MMX...etc., The list of
>> blunders goes on......
>
>

[toc] | [prev] | [next] | [standalone]

#384701

On Tuesday, May 31, 2016 at 1:30:35 PM UTC-7, HGWilson, DSc. wrote:
> On 31/05/16 21:58, mlwozniak@wp.pl wrote:
> > W dniu wtorek, 31 maja 2016 13:25:04 UTC+2 użytkownik Prokaryotic Caspase Homolog napisał:
> >
> >> Henry, please try using a PROVEN solution instead of attempting to make up your
> >> own ad hoc fix. Many, many people have devoted thousands of man-years in the
> >> development of accurate, reliable and stable techniques for numerically solving
> >> differential equations.
> >
> > See, the same can be told about euclidean geometry,
> > and your idiot guru rejected it anyway.
> 
> Those theoretical physicists/mathematicians have mmade physics so 
> difficult that no kids want to take it up any more.

You can always pick a different hobby. Why do you insist on physics?

--
Jan

[toc] | [prev] | [next] | [standalone]

#384690

On 31/05/16 21:25, Prokaryotic Caspase Homolog wrote:
> On Monday, May 30, 2016 at 6:27:19 PM UTC-5, al...@interia.pl wrote:
>> W dniu niedziela, 29 maja 2016 23:01:07 UTC+2 użytkownik HGWilson, DSc. napisał:

>>           y[i].v.addm(a[i], h6);
>>        }
>> }
>
> If you want to help Henry, you need to provide a COMPLETE code sample with all
> input and output variables documented and all dependencies accounted for.
> Missing external dependencies include force(), forceg(), addm()
>
> As it stands, your code snipped is unusable.
>
> Henry, please try using a PROVEN solution instead of attempting to make up your
> own ad hoc fix. Many, many people have devoted thousands of man-years in the
> development of accurate, reliable and stable techniques for numerically solving
> differential equations.

They didn't have double precision numbers and fast computers.
I have given up differential equations altogether. Real situations are 
never exact anyway. It is much easier to simulate and produce a series 
of graphs directly.

I can easily correct my ellipses by doing what I just 
suggested....monitoring the error and applying a factor throughout the 
iteration until the error is minimized.

[toc] | [prev] | [next] | [standalone]

#384750

On Tuesday, May 31, 2016 at 3:23:45 PM UTC-5, HGWilson, DSc. wrote:
> On 31/05/16 21:25, Prokaryotic Caspase Homolog wrote:

> > Henry, please try using a PROVEN solution instead of attempting to make up your
> > own ad hoc fix. Many, many people have devoted thousands of man-years in the
> > development of accurate, reliable and stable techniques for numerically solving
> > differential equations.
> 
> They didn't have double precision numbers and fast computers.
> I have given up differential equations altogether. 

No you haven't. In a previous post, you wrote:
   "In the x direction, the simplest iteration for each time unit uses 
    v=v+a: x=x+v: a= fn(x), (same for y), repeat" 

This is the classic Euler method for solving ordinary differential equations.

The Euler method is a first order method, the simplest and most primitive.
An easy step up would be a second order method. I'll post one for you later, 
but I have to be getting to work right now.

> Real situations are 
> never exact anyway. It is much easier to simulate and produce a series 
> of graphs directly.
> 
> I can easily correct my ellipses by doing what I just 
> suggested....monitoring the error and applying a factor throughout the 
> iteration until the error is minimized.

That is pretty much what most advanced methods do: take a step, figure out
an estimate for the error, and then take a revised step based on what you've
found out.

Later...

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | sci.physics.relativity

csiph-web