On 28 Feb 2007 06:05:46 -0800, "George Dishman"
wrote:

On 27 Feb, 22:11, HW@....(Henri Wilson) wrote:
On Tue, 27 Feb 2007 09:22:01 -0000, "George Dishman"


f'/f = c/(c-v)

or using the time between arrivals and turning it round
to find v:

v = c(1 - t'/t)

Distance does not appear in this equation.


I am making an assumption that your current code is correct
and includes all the effects in the way it calculates the
pulse arrival times.

No, there are many complications.
I'm quite confident my program is correct.

If your program is correct, so will the result
found from it.

This is how I will have to approach it.

My program assumes that identical pulses are emitted at regular intervals from
some 30000 points around the orbit. (the pulsar does much the same) The true
radial velocities towards the observer are known and are stored in an array.
The emission 'lag' between consecutive pulses is period/30000. ...that provides
the value of t.

Yes, so far so good.

The program calculates the maximum and minimum travel times over the observer
distance of the pulses emitted in one cycle . (I actually use three period
cycles to avoid end effects but we will only talk about 1 period here.)
The max and min are divided into 167 equal time divisions, into which each
pulse is appropriately placed as it arrives..

"as it arrives" is the key phrase there. I am assuming you
take into account both the location of the source in its
orbit and the radial speed in order to calculate the time
taken. If you are ignoring the location and just dividing
the distance between the barycentres of the binary system
and the solar system by the c+v speed then you will have
another error that I wasn't previously aware of.

Both Androcles and I soon realised that it is not necessary to include the
Rsin(theta) term because it is always very small compared with relative
movement of pulses over many lightyears.
Ignore it George.

For large magnitude variations that would be true but
Cepheids variability ranges over roughly 0.6 to 2.0
mag which is quite small. At 0.6 mag, ignoring the
velocity part will give a phase error of around 40
degrees (mental arithmetic) so definitely cannot be
ignored.

...although, it might be significant for your pulsar.

It is significant for both stars and pulsars for a
brightness variation of less than about 3 to keep
the phase error below about 10 degrees.

We have been talking about different things here.


If 'n' pulses arrive in a particular time division at distance D, then
n/180 is
an indication of the bunching there.

Right, or say b = n/180 and you plot b as the green curve.

Yes.....well, I actually plot n with a scaling factor.

If you calculate v = c(1 - 1/b) then you get the "willusory"
radial speed so v = c(1 - 180/n). Just plot v as the red
curve and the job is done.

But I don't have to.

Yes you do, that's what is published and what you
have to compare against.

The program has already recorded the true radial velocities of all the pulses
that arrive in a certain time division. It takes the average and plots that.

I concede that when the number of pulses that arrive in a division becomes
quite high, for instance for magnitude changes above about 2, the 'average
speed' will not be a very accurate indicator of what is happening. So at
present my red curve is not to be taken seriously for large star magnitude
variations. It is quite accurate for mag changes below about 1, which covers
most cases we want to investigate.

It is phase shifted for magnitudes below about 3.

I'm working on it.

If I want greater accuracy, I can increase the number of sample points around
the orbit, shorten the arrival time divisions and lengthen the graph on the
screen. My method is still 100% sound.

Not if it ignores the velocity component of the Doppler.

It MUST give the same answer as your
equation.

My suggestion was an equation you could apply to your
existing output to cater for pulsars. It will be quite
diffferent, but if you have ignored the classical
Doppler then it will be wrong too.


My approach if I was to do it your way would be slightly
simpler. You are tracking N=30000 pulses emitted equal
times T apart to take account of the Keplerian orbit. For
each point n you find the distance to the observer and
the speed at emission. From those and the extinction
distance you calculate the time of arrival t(n). Then the
compression ratio is:

[You can assume the distance is the same for all points.
Travel times across the orbit are generally negligible.]

No you can't, the travel time across the orbit is
small (3.8s compared to 1.5 days) but the Doppler
due to the change of distance is significant. You
cannot ignore the 27km/s velocity component.

I'm not ignoring that George.

r = ( t(n) - t(n-1) ) / T

That is related to what I do....but you need lots of sample points for
elliptical orbits.

or better if you want to remove a small phase error:

r = ( t(n+1) - t(n-1) ) / (2T)

yes....better..

The more points the better but you only use two
either side, you don't average lots.

Right, I have used this method to produce brightness curves for both circles
and ellipses. All the infrastructure is already in my program so this was a
fairly simple exercise.

You'll be pleased to hear it produces the same curves...or nearly the same.
Actually your method is better because I found a way to eliminate the averaging
that was always a problem before.

I used a few tricks.
I calculate the travel time from selected points around the orbit then use:
r = ( t(n) - t(n-1) +T) / T
My program has arrays containing all the details about the ellipse that is
used...namely velocity and velocity angle at each of the 30000 or more points
around the orbit..

I use every 100th point and compare its arrival time with that of the adjacent
one.... 99th, 199th...etc., point. This reduces the averaging effect and I
think gives higher accuracy that before. The curves are sharper. My 'Eclipsing
binary' curves are closer to the published ones.

I still have to do the red curve. There's something missing from your equation
I think.



The brightness is


b(n) = 1 / r(n)

and you can trap the infinity at r(n)=0

The "willusory" velocity is

v(n) = c(1 - r(n))

which is always finite.

Then just plot b(n) as the green curve and v(n) as the
red curve versus t(n).

I'm not convinced the method works....I don't think it takes into account the
emission time lag around the orbit.

You just told me to ignore it!

we have been talking about different things here.

All you are really doing is calculating the compression that adjacent pulses
emitted at a certain point on the orbit will experience at distance D. This
doesn't tell you the overall picture..

It is the whole picture, it includes all the factors
I listed at the top which you said I expressed well.

Well the method produces virtually the same brightness curves as mine so it
must be valid. I don't see why it shouldn't be. It is certainly simpler and
faster.
I still have to convert to log output and calculate the magnitude changes but
the program is basically set up to do that.. So that's easy.

.but it might work for small magnitude
changes.

The reason I used the current method was that I wanted to be able to
investigate what happens when the critical distance is exceeded. I don't need
to now because it obviously never IS, due to extinction.

That's harder. For your view of stars you get multiple
overlapping spectra so the star looks like several and
there is no single answer for velocity, you would get a
velocity for each image.

Yes, I wasn't sure what to expect and so I had to use a method that allowed
lots of 'overtaking'....maybe even from orbits widely separated.
Because of extinction, I don't need to worruy about that any more. It is
unlikely that pulses ever overtake other pulses.
I probably would never have bothered to simplify my program if you hadn't
suggested it. So I thank you for that George. This shows the advantages of
cooperation.
I can already see that my curves will now be even closer to the observed ones.

For pulsars a large number of
copies would look like a source with random pulse times.
A few copies would be recognisable as separate pulsars
with pulse streams that could be separated. The identical
mean rates would then be identifiable as two copies.
Neither of these situations ever arises of course.

That appears to be the case.


George


"When a true genius appears in the world, you may know
him by this sign, that the dunces are all in confederacy against him."
--Jonathan Swift.