VLSR corrected velocity for observed frequency

[Jack Lobingier]

I would like some feedback on the correctness of the correction computed by this program.

Thanks,

Jack

[fasleitung3]

Hi Jack,

Not sure why but it throws an error when entering the time:

Enter Observed Freq = 1.420405

()

('Doppler velocity of observed freq = ', <Quantity 0.15829586 km / s>)

Enter RA Observed (Degrees) = 22.

Enter DEC Observed (Degrees) = 56.

Enter Observation Date yyyy-mm-dd = 2021-05-30

Enter Observation Time hh:mm:ss.s UTC = 11:57:42.3

Traceback (most recent call last):

  File "observed_freq _to_VLSR.py", line 30, in <module>

    myobstime=input('Enter Observation Time hh:mm:ss.s UTC = ')

  File "<string>", line 1

    11:57:42.3

      ^

SyntaxError: invalid syntax

Cheers,

Wolfgang

--
--
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/28e1c601-e96e-48d9-9060-b7ce52868ac2n%40googlegroups.com.

[Dave Typinski]

Executes without errors here on Python 3.8.3 with astropy 4.1rc1. Can't speak
to the accuracy of the output.
--
Dave

>> <mailto:sara-list+...@googlegroups.com>.

>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/sara-list/28e1c601-e96e-48d9-9060-b7ce52868ac2n%40googlegroups.com

>> <https://groups.google.com/d/msgid/sara-list/28e1c601-e96e-48d9-9060-b7ce52868ac2n%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> --
> 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

> <mailto:sara-list+...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/sara-list/831cfe44f377e3d94ffa95a3eedff4420b0c3c8b.camel%40googlemail.com
> <https://groups.google.com/d/msgid/sara-list/831cfe44f377e3d94ffa95a3eedff4420b0c3c8b.camel%40googlemail.com?utm_medium=email&utm_source=footer>.

[Jack Lobingier]

Wolfgang, thanks very much for looking at the program.  I ran it with your numbers, and the attached screen capture shows the result.  Also, I re-zipped the program, so you can try it again.  For reference I am running Python 3.8.5.  Dave thank you for checking that it runs.

Regards,

Jack

[fasleitung3]

Thanks, Dave for pointing out that it wants Python3. I had used
Python2.
Wolfgang

> --

[fasleitung3]

Jack, it was my fault as I was using Python2 rather than Python3.

No problem with Python3.

It will be a little while before I can do some testing for the numbers.

Wolfgang

[fasleitung3]

Hi Jack,

I did a very quick test. I found the barycentric velocity in good agreement (~0.01 km/s), but the VLSR was off by up to 3 km/s compared to my algorythm.

Maybe there is something not right when going from barycentric to LSR.

I will look further into this later.

Cheers,

Wolfgang

Am Sonntag, den 30.05.2021, 05:53 -0700 schrieb Jack Lobingier:

[Jack Lobingier]

Wolfgang, thank you for looking into this, I’ve had a hard time finding worked out examples and at least one of the online calculators is no longer available.  So, thanks again.

Regards,

Jack

--

--
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 a topic in the Google Groups "Society of Amateur Radio Astronomers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sara-list/FNE6amtGs4E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sara-list+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sara-list/d0d89d89329fa7fc517f4d079eab56cd3f586b95.camel%40googlemail.com.

[fasleitung3]

Jack,

I am not sure yet but it seems that the difference is in the definition of the motion of the sun.

The common definition is (or maybe was) to assume the motion of the sun to be 20 km/s towards ra = '18:03:50.29', dec = '+30:00:16.8' in the ICRS reference frame. This was adopted by the IAU as standard, and is what we are using as basis. This is also used in the python code by the CAMRAS people: 

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

Some time ago I checked their calculation against ours and I found them in very good agreement. At that time I wanted a check since our code is still using VSOP87 for the solar system motion. But it seems that any differences to more recent data from that are negliable.

Looking at the Astropy documentation I found that they are using the analysis bei Schönreich at al (https://ui.adsabs.harvard.edu/abs/2010MNRAS.403.1829S/abstract) for the peculiar motion of the sun as default. Unfortunately it is not quite straightforward to compare his values with the IAU values as he gives it in galactic cartesian coordinates rather than in equatorial coordinates. So it remains open whether the difference can be accounted to that.

To complicate things even more, there is another analyis based on Gaya data: https://iopscience.iop.org/article/10.1088/1674-4527/19/5/68/meta. This again has another set of parameters in galactic cartesian coordinates.

There are a couple of options now: You could adopt the code from the CAMRAS people. This is using up to date solar system ephemeris based on astropy, but is using the IAU convention for the sun peculiar motion. You could also convert the IAU equatorial data to galactic cartesian, put that into the astopy call and see how that compares when using your code. This would clarify whether the difference is actually due to the definition of the solar motion.

Best regards,

Wolfgang

[fasleitung3]

Ok, somehow it left me uneasy ;-)

Yes, I could confirm that the difference is acutally in the definition of the peculiar motion of the sun.

I have converted the IAU definition into galactic cartesian coordinates and entered it into your code. Then the comparison with our code is spot on (within a few meters/s)

If you want to use IAU convention, your conversion should look like this:

new_rv = my_observation.transform_to(LSR(v_bary=(10.27,15.32,7.74)*u.km/u.s)).radial_velocity

So it is your choice what you want to use. If you compare with existing publication you are probably better off going IAU.

Cheers,

Wolfgang

[Jack Lobingier]

Wolfgang, great job of explaining the issue, thanks very much.  As a practical matter, is it more common for the VLSR to be computed for each frequency / time / coordinate set of data in real time and stored with the collected data, or just computed as needed in post processing?  Thanks again for helping me understand all this.

Regards,

Jack

--
--
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/50060a6bf23624f38772d8754c77f7a69ed70be8.camel%40googlemail.com.

[fasleitung3]

What we are doing is to calculate the required correction to LSR at the beginning of the measurement and then adjust the observed freqency. In case of a downconversion we adjust the LO to accomodate the required offset. In case of SDRs where we do not downconvert, we adjust the frequency directly .

I was advised that this is the way the professional telescopes are doing it. The philosophy behind this is that the recorded data should be independent of the observatory location and time of measurement.

In any case we record in the header of the data what adjustments were made.

Of course doing it in post-processing is also a valid approach.

Cheers,

Wolfgang

[Dave Typinski]

Hi Wolfgang,

In my opinion, one should always save the raw data.

Saving /only/ the transformed data /without/ including all the relevant
transformation parameters would be very poor form, regardless of whether the
professionals are doing it that way.

You have struck a good middle ground by including the transformation parameters
in the header. That way one could -- at least in theory -- get back to the raw
data if needed.

Nevertheless, hard drive data storage is inexpensive. One can easily save the
raw data /and/ the transformed data side by side. That way when the IAU or
whoever decides to redefine a standard (or one discovers a processing error),
re-adjusting the raw data to the new standard (or to fix a processing error) is
trivial.
--
Dave

On 5/31/21 15:11, 'fasleitung3' via Society of Amateur Radio Astronomers wrote:
> What we are doing is to calculate the required correction to LSR at the
> beginning of the measurement and then adjust the observed freqency. In case of a
> downconversion we adjust the LO to accomodate the required offset. In case of
> SDRs where we do not downconvert, we adjust the frequency directly .
> I was advised that this is the way the professional telescopes are doing it. The
> philosophy behind this is that the recorded data should be independent of the
> observatory location and time of measurement.
> In any case we record in the header of the data what adjustments were made.
> Of course doing it in post-processing is also a valid approach.
> Cheers,
> Wolfgang
>
>
> Am Montag, den 31.05.2021, 07:01 -0500 schrieb Jack Lobingier:
>> Wolfgang, great job of explaining the issue, thanks very much. As a practical
>> matter, is it more common for the VLSR to be computed for each frequency /
>> time / coordinate set of data in real time and stored with the collected data,
>> or just computed as needed in post processing? Thanks again for helping me
>> understand all this.
>>
>> Regards,
>> Jack
>>
>> On Mon, May 31, 2021 at 5:16 AM 'fasleitung3' via Society of Amateur Radio

>> Astronomers <sara...@googlegroups.com <mailto:sara...@googlegroups.com>>

>> wrote:
>>> Ok, somehow it left me uneasy ;-)
>>> Yes, I could confirm that the difference is acutally in the definition of the
>>> peculiar motion of the sun.
>>> I have converted the IAU definition into galactic cartesian coordinates and
>>> entered it into your code. Then the comparison with our code is spot on
>>> (within a few meters/s)
>>> If you want to use IAU convention, your conversion should look like this:
>>> new_rv =
>>> my_observation.transform_to(LSR(v_bary=(10.27,15.32,7.74)*u.km/u.s)).radial_velocity

>>> <http://u.km/u.s)).radial_velocity>

>>>
>>> So it is your choice what you want to use. If you compare with existing
>>> publication you are probably better off going IAU.
>>> Cheers,
>>> Wolfgang
>>>
>>>
>>> Am Montag, den 31.05.2021, 10:12 +0200 schrieb fasleitung3:
>>>> Jack,
>>>> I am not sure yet but it seems that the difference is in the definition of
>>>> the motion of the sun.
>>>> The common definition is (or maybe was) to assume the motion of the sun to
>>>> be 20 km/s towards ra = '18:03:50.29', dec = '+30:00:16.8' in the ICRS
>>>> reference frame. This was adopted by the IAU as standard, and is what we are
>>>> using as basis. This is also used in the python code by the CAMRAS people:

>>>> <https://gitlab.camras.nl/dijkema/HPIB/blob/185d241ad9bd7507ed90c9fa91fe0a63009d3eee/vlsr.py><https://gitlab.camras.nl/dijkema/HPIB/blob/185d241ad9bd7507ed90c9fa91fe0a63009d3eee/vl><https://gitlab.camras.nl/dijkema/HPIB/blob/185d241ad9bd7507ed90c9fa91fe0a63009d3eee/vls><https://gitlab.camras.nl/dijkema/HPIB/blob/185d241ad9bd7507ed90c9fa91fe0a63009d3eee/vlsr><https://gitlab.camras.nl/dijkema/HPIB/blob/185d241ad9bd7507ed90c9fa91fe0a63009d3eee/vlsr.>https://gitlab.camras.nl/dijkema/HPIB/blob/185d241ad9bd7507ed90c9fa91fe0a63009d3eee/vlsr.py

>>>> Some time ago I checked their calculation against ours and I found them in
>>>> very good agreement. At that time I wanted a check since our code is still
>>>> using VSOP87 for the solar system motion. But it seems that any differences
>>>> to more recent data from that are negliable.
>>>>
>>>> Looking at the Astropy documentation I found that they are using the
>>>> analysis bei Schönreich at al
>>>> (https://ui.adsabs.harvard.edu/abs/2010MNRAS.403.1829S/abstract) for the
>>>> peculiar motion of the sun as default. Unfortunately it is not quite
>>>> straightforward to compare his values with the IAU values as he gives it in
>>>> galactic cartesian coordinates rather than in equatorial coordinates. So it
>>>> remains open whether the difference can be accounted to that.
>>>> To complicate things even more, there is another analyis based on Gaya data:
>>>> https://iopscience.iop.org/article/10.1088/1674-4527/19/5/68/meta. This
>>>> again has another set of parameters in galactic cartesian coordinates.
>>>>
>>>> There are a couple of options now: You could adopt the code from the CAMRAS
>>>> people. This is using up to date solar system ephemeris based on astropy,
>>>> but is using the IAU convention for the sun peculiar motion. You could also
>>>> convert the IAU equatorial data to galactic cartesian, put that into the
>>>> astopy call and see how that compares when using your code. This would
>>>> clarify whether the difference is actually due to the definition of the
>>>> solar motion.
>>>>
>>>> Best regards,
>>>> Wolfgang
>>>>
>>>>>>>>>
>>> --
>

> --
> --
> 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

> <mailto:sara-list+...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/sara-list/71652d1f248f046bfaacd150a69e2509001b63a5.camel%40googlemail.com
> <https://groups.google.com/d/msgid/sara-list/71652d1f248f046bfaacd150a69e2509001b63a5.camel%40googlemail.com?utm_medium=email&utm_source=footer>.

[fasleitung3]

Hi Dave,
I tend to disagree. I believe there is no advantage in recording the
data in a location specific reference frame vs. recording it in a
defined generally adopted reference frame. As long as you know what
reference frame has been used you can convert back and forth as you
please. I would not even have to record the transformation parameters
(as we do) as you can always calculate that.
As we exchange data with other scientific institutions it would be
extremely cumbersome/confusing if we would use a non-standard reference
frame.
I should note that transformation of reference frame does not reduce
the amount of data and there is no loss of information associated with
such a transformation.
I believe it is also beneficial in the amateuer arena to record spectra
in a defined standard reference frame if one wants to compare own
results with others.
Cheers,
Wolfgang

> --