Radial Velocity Not Correct

[alexji]

Comparing between old and new SMH, something is really off with the radial velocity in the new SMH. By eye, all lines are off a bit from where they should be. In one case I had to apply a 4km/s offset to get things to look okay.

It is possible this is an effect of not finding a sufficiently accurate optimum in the cross correlation, or edge effects in computing the cross correlation itself, or in changing the actual wavelengths.

[andycasey]

It's possible this could be a zero-index to 1-index pixel problem too when changing from wavelength space to Fourier space or vice versa, because that's about the pixel scale velocity for mike spectra.

Sent from my Commodore 64

On 17 Aug 2017, at 22:01, Alex Ji notifications@github.com wrote:

Comparing between old and new SMH, something is really off with the radial velocity in the new SMH. By eye, all lines are off a bit from where they should be. In one case I had to apply a 4km/s offset to get things to look okay.

It is possible this is an effect of not finding a sufficiently accurate optimum in the cross correlation, or edge effects in computing the cross correlation itself, or in changing the actual wavelengths.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[alexji]

That would make sense, when you cross correlate a spectrum with itself you get a velocity offset too.

On Thu, Aug 17, 2017 at 9:03 AM Andy Casey notifications@github.com wrote:

It's possible this could be a zero-index to 1-index pixel problem too when changing from wavelength space to Fourier space or vice versa, because that's about the pixel scale velocity for mike spectra.

Sent from my Commodore 64

On 17 Aug 2017, at 22:01, Alex Ji notifications@github.com wrote:

Comparing between old and new SMH, something is really off with the radial velocity in the new SMH. By eye, all lines are off a bit from where they should be. In one case I had to apply a 4km/s offset to get things to look okay.

It is possible this is an effect of not finding a sufficiently accurate optimum in the cross correlation, or edge effects in computing the cross correlation itself, or in changing the actual wavelengths.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/andycasey/smhr/issues/257#issuecomment-323051997, or mute the thread https://github.com/notifications/unsubscribe-auth/AC8IjpuaZhgwh9kqDKwhvsTERc5m5YJRks5sZCwUgaJpZM4O6Kaa .

[andycasey]

Yeah, that'd definitely be the issue then I think

Sent from my Commodore 64

On 18 Aug 2017, at 02:19, Alex Ji notifications@github.com wrote:

That would make sense, when you cross correlate a spectrum with itself you get a velocity offset too.

On Thu, Aug 17, 2017 at 9:03 AM Andy Casey notifications@github.com wrote:

It's possible this could be a zero-index to 1-index pixel problem too when changing from wavelength space to Fourier space or vice versa, because that's about the pixel scale velocity for mike spectra.

Sent from my Commodore 64

On 17 Aug 2017, at 22:01, Alex Ji notifications@github.com wrote:

Comparing between old and new SMH, something is really off with the radial velocity in the new SMH. By eye, all lines are off a bit from where they should be. In one case I had to apply a 4km/s offset to get things to look okay.

It is possible this is an effect of not finding a sufficiently accurate optimum in the cross correlation, or edge effects in computing the cross correlation itself, or in changing the actual wavelengths.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/andycasey/smhr/issues/257#issuecomment-323051997, or mute the thread https://github.com/notifications/unsubscribe-auth/AC8IjpuaZhgwh9kqDKwhvsTERc5m5YJRks5sZCwUgaJpZM4O6Kaa .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[alexji]

Sorry I'm just dumb and mixed up HD122563 and HD140283 because they both started with HD.

I think it has something to do with this: the peak always seems lightly to the left of the red line.

[alexji]

Some quick tests show it might have to do with how the wavelength is sampled. If I use the raw order, I get a different answer than if I export the normalized spectrum from the old SMH. I need to investigate more but this is really weird.

It is not an algorithmic difference as I ported the old code to the new SMH and it gives identical answers with identical inputs.

On Thu, Aug 17, 2017 at 5:40 PM Andy Casey notifications@github.com wrote:

Yeah, that'd definitely be the issue then I think

Sent from my Commodore 64

On 18 Aug 2017, at 02:19, Alex Ji notifications@github.com wrote:

That would make sense, when you cross correlate a spectrum with itself you get a velocity offset too.

On Thu, Aug 17, 2017 at 9:03 AM Andy Casey notifications@github.com wrote:

It's possible this could be a zero-index to 1-index pixel problem too when changing from wavelength space to Fourier space or vice versa, because that's about the pixel scale velocity for mike spectra.

Sent from my Commodore 64

On 17 Aug 2017, at 22:01, Alex Ji notifications@github.com wrote:

Comparing between old and new SMH, something is really off with the radial velocity in the new SMH. By eye, all lines are off a bit from where they should be. In one case I had to apply a 4km/s offset to get things to look okay.

It is possible this is an effect of not finding a sufficiently accurate optimum in the cross correlation, or edge effects in computing the cross correlation itself, or in changing the actual wavelengths.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/andycasey/smhr/issues/257#issuecomment-323051997, or mute the thread < https://github.com/notifications/unsubscribe-auth/AC8IjpuaZhgwh9kqDKwhvsTERc5m5YJRks5sZCwUgaJpZM4O6Kaa

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/andycasey/smhr/issues/257#issuecomment-323187948, or mute the thread https://github.com/notifications/unsubscribe-auth/AC8Iji8-Me6F9jdr7jCZeHQUXfj1nyI7ks5sZKU7gaJpZM4O6Kaa .

[andycasey]

All of that would make sense if it were a sub-pixel interpolation issue, I think.

[alexji]

So it also makes sense that this would be a problem with the old algorithm that was partially hidden by the finer wavelength sampling when it created the normalized spectrum?

[andycasey]

Quite possibly, yes.

[alexji]

After some investigation it appears the problem is probably not the radial velocity, but rather the normalized spectrum itself. Something in the RV + stitching causes the spectrum to be shifted off approximately one pixel, i.e. when you apply 0 RV and use "d" for don't normalize, the exported spectrum is off by one pixel.

[alexji]

I've verified that it is not a problem with the precision of writing out the spectrum dispersion/flux. Also running scripts with just the session without a GUI does not appear to have this problem.

It seems likely that if all the continuum normalization is properly refactored out of the normalization gui into the session, this will either go away or the bug will be found.

[alexji]

OK it turns out the RV algorithm is fine (although since we do it in linear space, it could be a bit off for very large velocities and not be right at all wavelengths; but I think this doesn't matter for stars). The actual problem was a bug in READING the template files.

Old SMH had this:

        dispersion_base = (np.arange(num_pixels) + 1 - crpix) * cd + crval

And we have this:

            dispersion = \
        crval + (np.arange(naxis) - crpix) * cdelt - ltv * cdelt

So we are missing the +1. This is perhaps because FITS files are 1-indexed? Astronomers used fortran for so long that wouldn't surprise me.

I will make a fix.

[alexji]

BTW I verified that the old SMH is correct by using wspectext in IRAF.