On 19 Feb 2007 00:41:06 -0800, "George Dishman"
wrote:

On 19 Feb, 04:44, HW@....(Henri Wilson) wrote:
On Mon, 19 Feb 2007 00:36:42 -0000, "George Dishman"
wrote:
"Henri Wilson" HW@.... wrote in message
.. .
On Sun, 18 Feb 2007 10:59:26 -0000, "George Dishman"
But you cannot ever get that because the variable
speed messes up the Doppler equation. As with any
modelling technique, you put in your initial guess
of the actual parameters, the program caclulates
the observed signals and then you iterate until
the predicted observables match that actuals.

Ah, but I only need a value for the MAXIMUM orbital speed.

Ah, but you cannot know that, all you know is the
maximum Doppler shift.

That's all I need.

Yes but you have to process it appropriately. Your
program is not doing that at present.

It's near enough to do what I want at present.... although I will have to take
Yaw angle into acount eventually..
All I am doing now is matching curves. The value of (distance x max velocity)
is rather arbitrary because I dont really know the unification distance and it
is not easy to obtain velocity diagrams.

The BaTh and SR
doppler equations are effectively the same.

No they aren't, that's the whole point. Look at the
bottom of your reply where you agree the _apparent_
speed should reach c at the critical distance!

Yes.... but during extinction, the wavelength contracts or expands, so as to
still maintain the correct details of source velocity.

No, the speed matching causes the 'wavelength',
which in this case is the distance between pulses,
to eventually settle down to a constant value but
it will not be the original.

Not according to me.
The final distance between adjacent pulses will vary according to their initial
velocity relative to the barycentre. Some will move closer together, others
further apart.

The extreme test
example here is for viewing at 8 light years with
negligible extinction, or equivalently at infinity
with an exponential extinction distance of 8 light
years, and the wavelength is zero. Your software
still gives v/c=0.00009 when it should be v/c=1.

George, unless I have access to a curve showing variation in pulse arrival
times I cannot help you much.

Reading the papers about this pulsar is quite confusing for me because the
authors make such a big issue of Shapiro delay. (They even admit light is
slowed by gravity). The BaTh interpretation would be quite different from
theirs.

I have removed most of the bugs although it doesn't have comprehensive
instructions as yet. Extinction doesn't work for circular orbits.

That's OK, your existing distance factor can be
essentially used as the extinction factor as long
as we are observing from a much greater distance.

It can. ..or you can set eccentricity at 0.01

No, set it to 2.3*10^-7 if anything, but you
don't need an explicit extinction term. Just
treat your program as an observer at infinity
and distance is the characteristic extinction
length.

Yes I can do that.
I only introduced the 'extinction' facility in order to try to obtain a value
for its rate.

Like I said, all I need is period, distance and a value for the maximum
radial
velocity.

Like I said, what you have is maximum Doppler shift.

No problem.

Indeed, but you need to fix the bug in the
software to convert from the shift to the
speed correctly.

George, this is a circular orbit and there is no difference between my and your
value of maximum velocity. I have tried to explain that extinction will not
affect measured doppler and its interpretation.


The red curve for the apparent speed. If you enter
27km/s the red curve should show that deviation
above and below the white axis. It would help if
you added a vertical scale or we cannot confirm
that. I'm presuming the value in the table on the
left called "Max. Vel." is your assumption for the
actual speed which you entered rather than the
highest point on the red curve.

The velocity curves are set to always have the same size on the screen. The
scale is linear and yes, the maximum is that shown in the velocity box. Ity
should be the same fro both red and blue curves.

No, it should be 0.00009c for the blue curve
at 8 light years and 1.0c for the red curve.
The 'wavelength' at that distance is zero.

George, I don't think we're taking about the same things here.
The blue curve is the true radial velocity curve towards the observer.
The red curve is generated in this way:

For the purpose of counting the arrival of pulses, the orbit period is divided
into 500 divisions, which form the elements of an array. The program adds all
the pulses that arrive in that division to make up the value of that array
element. It also follows each pulse individually so that it records the speed
at which the pulse left the source barycentre. It averages the velocities of
all the pulse that are placed into each array element.

Introducing extinction doesn't really change anything.

I have realised though that when using ellitical orbits I have to compensate
for Yaw angle because the maximum observed velocity is not necessarily the
velocity at periastron.

That could be the cause of your extra phase
change.

It shouldn't make much difference at low eccentricities and doesn't affect
brightness curve shape anyway. ..just the distance.


There is second
order term involving the 'rate of change of acceleration'. You have
omitted it.

I don't believe there is such a term but that's why
I want to do the short distance test first.

No, I was wrong there, although not entirely. The main reason the point moves
is due solely to the difference in emission times. For short distances, a half
period is quite significant.

Getting the correct location for the maximum speed
will matter too, but for our circular orbit it
shouldn't matter.

Anyway, bottom line at the moment is that you are
not calculating the apparent velocity correctly
from the pulse period so let's get that fixed
before worrying about the effects of eccentricity.

George you have it all back to front.

I don't want to calculate the velocity. I want to read about it in a table or
graph.
Can you provide that info for me?


George