"Henri Wilson" <HW@..> wrote in message
> On Fri, 17 Mar 2006 14:45:09 -0000, "George Dishman"
>>"Henri Wilson" <HW@..> wrote in message
>>> On Wed, 15 Mar 2006 23:53:55 -0000, "George Dishman"
>>>>I don't have time to write any more tonight
>>>>but I found part of the problem, low values
>>>>of eccentricity cause the blue curve to blow
>>>>up. Try using 0.1 then 0.01 then 0.001 and
>>>>you should see what I mean. The graph vanishes
>>>>for zero. I used an orbital period of 0.0041
>>>>years (1.5 days) but I don't think it matters
>>> Why do you want to use such small eccentricities?
>>The measured value is 2*10^-7. That means the
>>Doppler shift is almost a perfect sine wave
>>which I'm fairly sure implies a circular orbit
>>in Ritz as well. It's only a starting point
>>though, the idea is to tweak the values to see
>>if Ritz can match the observations.
> there is very little diference between e=0 and e=0.05
If your code is wrong, all of the effect at e=0.05
may be due to the error. You need to sort the bug.
>>> It does go crazy for some
>>> reason but there is very little difference between the curves of e=0.0
>>> and you shouldn't try to use them. The program uses a very complex
>>> method to derive the ellipses. I didn't realize it failed at these low
>>> eccentricities but don't worry about it. I'll look into the problem.
>>It is symptomatic of an error in your coding so
>>all the curves become suspect, I'll wait until
>>you debug it before trying again.
> I've fixed the simplified program. There was a '1/e' term. I made it a
> 1/(e+0.1) which doesn't matter because the height scale is arbitrary
> Il fix the other program soon.
Perhaps it should be 'e' instead of '1/e'. The
point is that the results are untrustable unless
you can find the error and fix it.
>>>>The program crashes if the number of orbits
>>>>is >25. For the pulsar we need to use at least
>>>>1200, probably more.
>>> That would take days to process even on the fastest computers.
>>> You are trying to achieve the near impossible.
>>Nah, it should be possible to solve it analytically
>>and do it in a fraction of a second on-line.
> Processing time is directly proportional to the number of orbits used.
I should have mentioned you can't solve elliptical
motion itself analytically but I meant you could
approximate it with a series of sines and then
calculate the contribution for each orbit from
those. There are still some bits that are difficult,
you may need to solve sin(x) = ax+b but again you
should be able to use approximations effectively.
Even with a thousand orbits, good coding should
get you below a second. I've spent most of my
working life doing that sort of thing.