Post-facto VLSR correction

[Marcus D. Leech]

Can someone suggest a method for post-facto correction of spectral data
that was recorded with an uncorrected
  receiver?

I'm thinking about our H166a and C166a RRL problem, in that if you
"stack" multiple days of data, things will
  have shifted in that time, which means you're not really "stacking",
except in a kind of fuzzy sense, and thereby
  losing sensitivity...

[Dr. Rich Russel]

Here are two calculators:

There is a third that allows you to put in your observer Lat/Long - still looking for that one.

https://ned.ipac.caltech.edu/velocity_calculator

and

Calculate radial velocity (nrao.edu)

https://www.gb.nrao.edu/cgi-bin/radvelcalc.py?UTDate=2022%2F03%2F28&UTTime=17%3A15%3A00&RA=24%3A15%3A00&DEC=40%3A00%3A00

--

--

You received this message because you are subscribed to the Google

Groups "Society of Amateur Radio Astronomers" group.

To post to this group, send email to sara...@googlegroups.com

To unsubscribe from this group, send email to

sara-list-...@googlegroups.com

For more options, visit this group at

http://groups.google.com/group/sara-list?hl=en

---

You received this message because you are subscribed to the Google Groups "Society of Amateur Radio Astronomers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sara-list+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sara-list/1d34bb40-fe69-fccf-ed90-3ff6bc8a7c34%40gmail.com.

[Alex P]

http://f4klo.ampr.org/vlsrKLO.php

[Eduard Mol]

Hi Marcus, 

I ran into similar issues when trying to compare water maser spectra from different dates. Initially I tried using different online calculators such as the one linked by Alex, but these gave errors of up to several hundred meters per second. Because the width of the water lines was often in the same order of magnitude, this was a problem. Now I am using the Astropy radial_velocity_correction function (see this example: https://gitlab.camras.nl/dijkema/HPIB/blob/185d241ad9bd7507ed90c9fa91fe0a63009d3eee/vlsr.py), which produces much more stable results. However, RRLs are often tens of km/s wide, so deviations of a few hundred m/s really should not matter for your application. 

Best regards,

Eduard

--
--
You received this message because you are subscribed to the Google
Groups "Society of Amateur Radio Astronomers" group.
To post to this group, send email to sara...@googlegroups.com
To unsubscribe from this group, send email to
sara-list-...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sara-list?hl=en
---
You received this message because you are subscribed to the Google Groups "Society of Amateur Radio Astronomers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sara-list+...@googlegroups.com.

[Michiel Klaassen]

I use an app.
It can be downloaded from the parac.eu download site.

Not suitable for you, because it is a Windows app.

To view this discussion on the web visit https://groups.google.com/d/msgid/sara-list/CAFcm1Q72_GRZFqtyCNARFfQQVHmxnYOMkeUkYPcDEWqJVb6Kkg%40mail.gmail.com.

[Marcus D. Leech]

On 2022-10-06 03:44, Eduard Mol wrote:

Hi Marcus, 

I ran into similar issues when trying to compare water maser spectra from different dates. Initially I tried using different online calculators such as the one linked by Alex, but these gave errors of up to several hundred meters per second. Because the width of the water lines was often in the same order of magnitude, this was a problem. Now I am using the Astropy radial_velocity_correction function (see this example: https://gitlab.camras.nl/dijkema/HPIB/blob/185d241ad9bd7507ed90c9fa91fe0a63009d3eee/vlsr.py), which produces much more stable results. However, RRLs are often tens of km/s wide, so deviations of a few hundred m/s really should not matter for your application. 

Best regards,

Eduard

Thanks everyone!  I got the CAMRAS vlsr.py working last night after I struggled a bit to get astropy installed on Ubuntu 22.04,
  and THEN ran into a weird issue that was my Own Damn Fault(tm).

Now to the mechanics of actually shifting the spectrum around a bit on a daily basis to make sure that the "stackings" line up.
  The H166a line is quite broad, but we're also going to try for the C166a line, which is quite a bit narrower.

To view this discussion on the web visit https://groups.google.com/d/msgid/sara-list/CAFcm1Q72_GRZFqtyCNARFfQQVHmxnYOMkeUkYPcDEWqJVb6Kkg%40mail.gmail.com.

[Dr. Rich Russel]

Eduard,

Could you do a 5+ minute tutorial of using this.

Just video yourself on zoom and hit record. Send me the link to the recording and I'll post as a new tutorial on the SARA YouTube channel.

Thanks!

Rich

To view this discussion on the web visit https://groups.google.com/d/msgid/sara-list/CAFcm1Q72_GRZFqtyCNARFfQQVHmxnYOMkeUkYPcDEWqJVb6Kkg%40mail.gmail.com.

[Marcus D. Leech]

On 2022-10-06 03:44, Eduard Mol wrote:

> Hi Marcus,
> I ran into similar issues when trying to compare water maser spectra
> from different dates. Initially I tried using different online
> calculators such as the one linked by Alex, but these gave errors of
> up to several hundred meters per second. Because the width of the
> water lines was often in the same order of magnitude, this was a
> problem. Now I am using the Astropy radial_velocity_correction
> function (see this example:
> https://gitlab.camras.nl/dijkema/HPIB/blob/185d241ad9bd7507ed90c9fa91fe0a63009d3eee/vlsr.py),
> which produces much more stable results. However, RRLs are often tens
> of km/s wide, so deviations of a few hundred m/s really should not
> matter for your application.
>
> Best regards,
>
> Eduard
>

The change in doppler over the 18 days we've been accumulating data is
less than 1 bin-width for H166a, so failing to do
  VLSR correction isn't a main contributor to our failure to detect
that line.  For C166a, it will be an issue, due to the
  much-narrower line width, and about 3 times less bright than H166a.

[Michiel Klaassen]

I was surprised to see that there were suddenly so many (recurrent) visitors to the parac website the past few days.
It must be caused by my casual mentioning the Windows VLSR app.

--
--
You received this message because you are subscribed to the Google
Groups "Society of Amateur Radio Astronomers" group.
To post to this group, send email to sara...@googlegroups.com
To unsubscribe from this group, send email to
sara-list-...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sara-list?hl=en
---
You received this message because you are subscribed to the Google Groups "Society of Amateur Radio Astronomers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sara-list+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sara-list/fe30c90e-c206-43e2-a5fa-9d1fa5c9ccc7%40gmail.com.

[Kimmo]

Hi

I compared the LSR velocities calculated by the following methods:

1) https://www.gb.nrao.edu/cgi-bin/radvelcalc.py

2) https://gitlab.camras.nl/dijkema/HPIB/blob/185d241ad9bd7507ed90c9fa91fe0a63009d3eee/vlsr.py

3) https://astronomy.stackexchange.com/questions/41196/looking-for-a-routine-to-correct-for-local-standard-of-rest-lsr

The method 1 is fixed to the coordinates of the GBT telescope, so I fixed the other methods to the same coordinates.

I have been using the method 3 in my hydrogen 21cm observations.

I wondered why the method 3 gives different results than methods 1 and 2, up to about 2 km/s.

The reason turned out to be that method 3 uses a different LSR velocity frame. For a discussion of the different frames, see

https://docs.astropy.org/en/stable/_modules/astropy/coordinates/builtin_frames/lsr.html

The frame usually used at radio astronomy is LSRK, which the document above defines in the following way:

"A coordinate or frame in the Kinematic Local Standard of Rest (LSR). This frame is defined as having a velocity of 20 km/s towards RA=270 Dec=30 (B1900) relative to the solar system Barycenter. This is defined in: Gordon 1975, Methods of Experimental Physics: Volume 12: Astrophysics, Part C: Radio Observations - Section 6.1.5. This coordinate frame is axis-aligned and co-spatial with `ICRS`, but has a velocity offset relative to the solar system barycenter to remove the peculiar motion of the sun relative to the LSRK."

So in the method 3 the Python commands

from astropy.coordinates import ICRS, LSR

new_rv = my_observation.transform_to(LSR()).radial_velocity

should be changed to

from astropy.coordinates import ICRS, LSRK

new_rv = my_observation.transform_to(LSRK()).radial_velocity

After that, the calculated LSR velocities are very similar, for example

1) 23.317 km/s

2) 23.301

3) 23.301

In addition, in the method 2 the command

psun = SkyCoord(ra = "18:03:50.29", dec = "+30:00:16.8",frame = "icrs",unit = (u.hourangle,u.deg))

could be replaced with

psun = SkyCoord(ra = 270.0*u.deg, dec = 30.0*u.deg, equinox='B1900', frame='fk4')
psun = psun.transform_to(ICRS())

which is clearer, I think.

I will start using method 2 because it shows explicitly that there is a dot product involved in the calculation of LSR velocity.

cheers, Kimmo

[Michiel Klaassen]

Hi Kimmo,

What are the exact input parameters you entered for these results.

Michiel

--
--
You received this message because you are subscribed to the Google
Groups "Society of Amateur Radio Astronomers" group.
To post to this group, send email to sara...@googlegroups.com
To unsubscribe from this group, send email to
sara-list-...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sara-list?hl=en
---
You received this message because you are subscribed to the Google Groups "Society of Amateur Radio Astronomers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sara-list+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sara-list/947190ff-e15c-428a-8235-28fa13cea341n%40googlegroups.com.

[Kimmo]

Hi

The input parameters were the following

the location of the observer (GBT telescope) was derived with the following Python commands:

>>> from astropy.coordinates import EarthLocation

>>> gbt = EarthLocation.of_site('green bank telescope')

>>> gbt.geodetic
GeodeticLocation(lon=<Longitude -79.839722 deg>, lat=<Latitude 38.433056 deg>, height=<Quantity 807. m>)

so the observer is at

longitude = - 79.8397  

latitude =  38.4330

(a faster way may be to get the coordinates from internet... but note that Astropython wants 'Earth East longitude', while at internet the longitude given is 'West longitude')

The RA/Dec coordinates of the source:

RA = 181.1  degrees

Dec = 22.1 degrees

Time of observations:

2018-06-21 at 12:00:00 UT

Then the derived LSR values are the values given in my previous mail

cheers, Kimmo

[Michiel Klaassen]

Thanks,

I tried to reproduce your result, but instead of 23.301, I got a different value; 17.991; perhaps I did something wrong. see screendump.

Michiel

To view this discussion on the web visit https://groups.google.com/d/msgid/sara-list/1507d937-6ff8-435d-b9ea-f67329a0a36fn%40googlegroups.com.

[Steve Olney]

Hi Michiel - the clue is the 3rd-last line in your screen dump.

[Steve Olney]

Or alternatively...

On Wednesday, October 12, 2022 at 10:38:25 PM UTC+11 vmin...@gmail.com wrote:

[Michiel Klaassen]

Hi Steve,

Indeed the old h versus d trap.

Michiel

To view this discussion on the web visit https://groups.google.com/d/msgid/sara-list/011e13b4-b529-4dac-b097-62f4833e48cbn%40googlegroups.com.

[Steve Olney]

I have tripped over this 'hazard' more than once.

BTW - for fun I have replicated my old online calculators in Python (with GUI). The code for the calculators was a port of 1970s-era MIT FORTRAN code which - as has been noted here - is only accurate to about 0.5 km/s these days. For the test case we are talking about it returns 23.6 km/s.