Hello and question please


Helen
 

Hi All,

I'm new to this group, but known to some of you!

I'm trying to analyse some old 67P from 2016 (not my data) using Astrometrica for comparison purposes.  After some playing around with settings I have got it to solve. 
There are some quirky things though.  When I choose 67P when preparing to solve the RA and Dec that appear bear no resemblance to what they should be for the date and time.  So I manually input the centre of the FoV from an astrometry.net solve, and it solved (on manual).
But when I do an overlay or try to measure the comet it is not recognising 67P as in the field, and not giving me the option of 67P in the dropdown - even though the position of the comet is where Horizons says it should have been at that time.  I'm assuming that is because it thinks the comet is somewhere completely different!  Any suggestions on what's going wrong please?

thanks
Helen


Umair Asim
 

When did you last updated Astrometrica?

Regards,

Umair Asim
www.edenobservatory.com
www.lahoreastronomy.com

President: Lahore Astronomical Society
Joint Secretary: Khwarizmi Science Society
Director: CBSAP Pakistan
Mentor@American Association for Variable Star Observers

Owner: Zeds Astronomical Observatory & Eden Astronomical Observatory
Minor Planet Center (IAU) Observatory Code N30 & N31


From: astrometrica@groups.io <astrometrica@groups.io> on behalf of Helen via groups.io <helen.usher@...>
Sent: Thursday, February 18, 2021 1:23:51 AM
To: astrometrica@groups.io <astrometrica@groups.io>
Subject: [astrometrica] Hello and question please
 
Hi All,

I'm new to this group, but known to some of you!

I'm trying to analyse some old 67P from 2016 (not my data) using Astrometrica for comparison purposes.  After some playing around with settings I have got it to solve. 
There are some quirky things though.  When I choose 67P when preparing to solve the RA and Dec that appear bear no resemblance to what they should be for the date and time.  So I manually input the centre of the FoV from an astrometry.net solve, and it solved (on manual).
But when I do an overlay or try to measure the comet it is not recognising 67P as in the field, and not giving me the option of 67P in the dropdown - even though the position of the comet is where Horizons says it should have been at that time.  I'm assuming that is because it thinks the comet is somewhere completely different!  Any suggestions on what's going wrong please?

thanks
Helen


Helen
 

Hi Umair, 

I'm running this Astrometrica version   I updated MPCOrb today.  Helen


Luca Buzzi
 

Hi Helen,
you simply cannot use the current epoch MPCORB with images that are 5 years old. Known object overlay works fine when images and MPCORB have the same epoch (date).

Regards,
Luca
# 204

Il 17/02/2021 22:23, Helen via groups.io ha scritto:
Hi All,
I'm new to this group, but known to some of you!
I'm trying to analyse some old 67P from 2016 (not my data) using Astrometrica for comparison purposes.  After some playing around with settings I have got it to solve.
There are some quirky things though.  When I choose 67P when preparing to solve the RA and Dec that appear bear no resemblance to what they should be for the date and time.  So I manually input the centre of the FoV from an astrometry.net solve, and it solved (on manual).
But when I do an overlay or try to measure the comet it is not recognising 67P as in the field, and not giving me the option of 67P in the dropdown - even though the position of the comet is where Horizons says it should have been at that time.  I'm assuming that is because it thinks the comet is somewhere completely different!  Any suggestions on what's going wrong please?
thanks
Helen


Peter Birtwhistle
 

Hi Helen,

Astrometrica doesn't calculate perturbations, so for your 2016 images you would be ideally have a copy of MPCORB from 2016 available and Astrometrica would show 67P approximately in the right place.

Rather than solving via astrometry.net you could use Horizons, or anything else that calculates the right position for the dates you are looking at and manually enter them into the coordinates window to get Astrometrica to solve, but to get the overlay working well you'll need a copy of MPCORB for approximately the date of your images.

I think Bill Gray did have a program to change the epoch of MPCORB to a date of your choosing but I can't find details of it now, maybe someone on list knows?

Peter
J95

On 17/02/2021 22:15, Helen via groups.io wrote:
Hi Umair,

I'm running this Astrometrica version   I updated MPCOrb today.  Helen


Helen
 

Thanks Luca and Peter, that makes sense.  I did indeed input the proper coordinates, from an astrometry.net solve, which then allowed Astrometrica to solve.  So could I use the elements from Horizon (dated 2013) by substituing those data into the MPCOrb manually?  I'm not needing the overlay per se, but need the correct position so that 67P becomes an option when verifying and so measuring the comet.   

I'm learning a lot!

Thanks
Helen


Peter Birtwhistle
 

Helen,

You don't need the elements at all and entering elements in manually sounds like (relatively!) hard work - if you've got the position from Horizons, then just manually enter the RA and Dec into the coordinates window (or Coordinates, Tracking and Stacking window if stacking).

Your measured position of the comet should agree well with Horizons and you should be able to see plenty of identified reference stars (Images/Select markings/Reference stars) and in the Data reduction results at the bottom of screen after solving you should hopefully see small (sub-arcsecond) values for dRA and dDec, depending on your image scale.

The overlay is only ever an approximation for where objects should be, sometimes pretty good but don't rely on it because of the epoch issue. If you see the overlay doesn't match your image, then assume the overlay is probably off and check your measurements against a good source like Horizons.

Peter
J95

On 17/02/2021 22:37, Helen via groups.io wrote:
Thanks Luca and Peter, that makes sense.  I did indeed input the proper coordinates, from an astrometry.net solve, which then allowed Astrometrica to solve.  So could I use the elements from Horizon (dated 2013) by substituing those data into the MPCOrb manually?  I'm not needing the overlay per se, but need the correct position so that 67P becomes an option when verifying and so measuring the comet.

I'm learning a lot!

Thanks
Helen


Peter Birtwhistle
 

... but if you do want to go down the elements route, you can display 67P using the MPC's orbits database at https://minorplanetcenter.net/db_search where it lists 11 different epochs, closest for you would be August 2015, not perfect but better than 2013 or 2021.

Peter
J95

On 17/02/2021 23:01, Peter Birtwhistle wrote:
Helen,

You don't need the elements at all and entering elements in manually sounds like (relatively!) hard work - if you've got the position from Horizons, then just manually enter the RA and Dec into the coordinates window (or Coordinates, Tracking and Stacking window if stacking).

Your measured position of the comet should agree well with Horizons and you should be able to see plenty of identified reference stars (Images/Select markings/Reference stars) and in the Data reduction results at the bottom of screen after solving you should hopefully see small (sub-arcsecond) values for dRA and dDec, depending on your image scale.

The overlay is only ever an approximation for where objects should be, sometimes pretty good but don't rely on it because of the epoch issue. If you see the overlay doesn't match your image, then assume the overlay is probably off and check your measurements against a good source like Horizons.

Peter
J95

On 17/02/2021 22:37, Helen via groups.io wrote:
Thanks Luca and Peter, that makes sense. I did indeed input the proper coordinates, from an astrometry.net solve, which then allowed Astrometrica to solve. So could I use the elements from Horizon (dated 2013) by substituing those data into the MPCOrb manually?  I'm not needing the overlay per se, but need the correct position so that 67P becomes an option when verifying and so measuring the comet.

I'm learning a lot!

Thanks
Helen




.


Helen
 

Thanks Guy, yes I added the observatory details.

Best wishes

Helen


On Wednesday, 17 February 2021, 23:04:15 GMT, Guy Wells <rasskipper@...> wrote:


Hi Helen,

Have you set the observatories location?


Regards,

Guy 
Z80


Helen
 

OK, I'll test a couple of options.  As I'm going to run a few different sets of 67P observations through Astrometrica, then a small amount of overhead at the start might pay dividends in the longer term!

Thanks

Helen


Cristovao Jacques
 

Hi Peter and Helen,


Yes there is a program developed by Bill Gray that does the task to convert mpcorb.dat to the desired epoch. 

You can find it here with instructions:




Cristovao
Y00
SONEAR






Em quarta-feira, 17 de fevereiro de 2021 19:30:19 BRT, Peter Birtwhistle <peter@...> escreveu:


Hi Helen,

Astrometrica doesn't calculate perturbations, so for your 2016 images
you would be ideally have a copy of MPCORB from 2016 available and
Astrometrica would show 67P approximately in the right place.

Rather than solving via astrometry.net you could use Horizons, or
anything else that calculates the right position for the dates you are
looking at and manually enter them into the coordinates window to get
Astrometrica to solve, but to get the overlay working well you'll need a
copy of MPCORB for approximately the date of your images.

I think Bill Gray did have a program to change the epoch of MPCORB to a
date of your choosing but I can't find details of it now, maybe someone
on list knows?

Peter
J95


On 17/02/2021 22:15, Helen via groups.io wrote:
> Hi Umair,
>
> I'm running this Astrometrica version   I updated MPCOrb today.  Helen
>







Enrico Prosperi
 

Hello Helen,
Luca and Peter and Guy are right.
You have to set observatory location data correctly and use Comet data of the epoch of image acquisition.
I'm used to record also the comet and mpcorb together with images for every observing session I do, so that I can process them also after years if it is the case.
So I attach here the comet data of three different epoch in 2016, say March, June and September. You must copy them and use the nearest to the time of your data. So you must put it in the folder where Astrometrica reads ephem data from and rename it as COMET.DAT. (to find this folder location, in Astrometrica open the "Program Setting" window and the click on Open -> Then open Astrometrica.cfg with notebook and search the AstrometricaVariable MPCOrbDir=(directory of mpcorb.dat and comet.dat) - there you must put the comet.dat file!)
I hope these notes have been useful for You!
Sincerely,
Enrico Prosperi
160 Castelmartini


>----Messaggio originale----
>Da: helen.usher@...
>Data: 17-feb-2021 22.23
>A:
>Ogg: [astrometrica] Hello and question please
>
>Hi All,
>
>I'm new to this group, but known to some of you!
>
>I'm trying to analyse some old 67P from 2016 (not my data) using Astrometrica for comparison purposes.  After some playing around with settings I have got it to solve.
>There are some quirky things though.  When I choose 67P when preparing to solve the RA and Dec that appear bear no resemblance to what they should be for the date and time.  So I manually input the centre of the FoV from an astrometry.net solve, and it solved (on manual).
>But when I do an overlay or try to measure the comet it is not recognising 67P as in the field, and not giving me the option of 67P in the dropdown - even though the position of the comet is where Horizons says it should have been at that time.  I'm assuming that is because it thinks the comet is somewhere completely different!  Any suggestions on what's going wrong please?
>
>thanks
>Helen
>
>
>
>
>
>


Helen
 

That is fantastic! 

Many, many thanks for providing the files Enrico!  And its a good lesson to learn about archiving useful information for future use too.

Best wishes

Stay safe

Helen


Cicero Lopes Silva
 

I am using an old image bank (2014, 15, 16, 17 ..) to study astronomy.
When I do the (time-consuming) conversion using integrat.exe or recompiled Linux integrat from the author's lunar git, some objects have their orbits corrected while others don't.
Is there a possibility to resolve this?
I have three prints. In two of them, the asteroids have their orbits corrected and Ariane does not.
This has occurred on several different dates.
And MPCORB.dat file properly recompiled.
https://github.com/Bill-Gray/lunar/blob/master/integrat.cpp
Compiling the integrat:
By default the makefile has CC = g ++, it must be changed to clang
The integrat is also not included in the standard build list for find_orb and must be added to the list or compiled separately.
When converting to use date in JD format, just click the date or for YYYYMMDD vsop.bin should be in the folder:
integrat.exe MPCOrb.dat 20170127.dat 20170127 20:00:00
./integrat MPCOrb.dat 20170127.dat 20170127 20:00:00 (Linux).
Move the file to the usage location and rename.
The process takes many hours.
It would be interesting to have a converter in Fortran.

Cicero

According to the colleague:
It is my understanding that Integrat only handles epoch changes when the data in MPCORb is at a standard epoch. If the epoch of the orbit in MPCOrb is not at a standard epoch I'm not sure what it does, but it will not do as you want. Be aware that a considerable proportion of the objects in MPCOrb are not at the current standard epoch of K20CH. Many are at the previous standard epoch of K205V and all the ones classed as un-perturbed have their own individual epochs.


Herbert Raab
 


> When I do the (time-consuming) conversion using integrat.exe or recompiled Linux integrat from the author's lunar git, some objects have their orbits corrected while others don't.

Orbits that do not refer to the standard epoch are preliminary orbits with large uncertainties that were calculated without taking planetary perturbations into account. It would make no sense to integrat these orbits to other epochs.

 - Herbert