-
-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rise/Meridian/Set calculations - interesting effect of low precision #453
Comments
PS. Apologies for the poor formatting above, I'll have a look at this later. |
Thanks for the note! That's really interesting, and I think your interpretation makes sense. Do you think it'd be a reasonable solution for this use-case to use a higher |
Hi Brett,
Yes that might work. I currently use a global variable to set which precision level should be used in the code as we have calculated several levels of precision per target to test the difference it makes. However, it would be trivial to amend this slightly to use different levels of precision depending on the declination of the target.
Thanks for your help.
Best regards
Ian
From: "Brett M. Morris" <notifications@github.com>
Reply to: astropy/astroplan <reply@reply.github.com>
Date: Friday, 17 January 2020 at 10:43
To: astropy/astroplan <astroplan@noreply.github.com>
Cc: "Wellaway, Ian" <I.J.Wellaway@exeter.ac.uk>, Author <author@noreply.github.com>
Subject: Re: [astropy/astroplan] Rise/Meridian/Set calculations - interesting effect of low precision (#453)
Thanks for the note! That's really interesting, and I think your interpretation makes sense. Do you think it'd be a reasonable solution for this use-case to use a higher n_grid_points value for the stars at higher declinations, and lower n_grid_points values for, say, targets with dec < 80 deg?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fastropy%2Fastroplan%2Fissues%2F453%3Femail_source%3Dnotifications%26email_token%3DAAMX4SBALUBOAUEQ4O2BYI3Q6GDFTA5CNFSM4KIGENDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJHIUAQ%23issuecomment-575572482&data=02%7C01%7CI.J.Wellaway%40exeter.ac.uk%7C528c136d28844d64753208d79b3a1354%7C912a5d77fb984eeeaf321334d8f04a53%7C0%7C0%7C637148546039433927&sdata=mosn85bcFbmAcSIXM8wXkJIoca9RKmLL4aNzlb%2BvZ94%3D&reserved=0>, or unsubscribe<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAMX4SCWEZXNL2UNBWXWHELQ6GDFTANCNFSM4KIGENDA&data=02%7C01%7CI.J.Wellaway%40exeter.ac.uk%7C528c136d28844d64753208d79b3a1354%7C912a5d77fb984eeeaf321334d8f04a53%7C0%7C0%7C637148546039438922&sdata=UYEkZ4PxBiQu5yKrTAcKaU7J%2BqaxCVNPHNHyFdavy2w%3D&reserved=0>.
|
I'm not an astrophysicist, so I hope I am not making a dumb mistake or assumption. but I noticed different times being computed for solar noon, and wrote this little test program:
Which yields
Should these not all be the same value? |
@rlabbe in fact, they shouldn’t all be the same time. The UTC time of solar noon moves around a bit because the Earth’s orbit is not circular. If you look for photos of the analemma you can see a striking visualisation of this. @iwellaway using a two pass approach mostly fixes this issue. I’ve got a Code branch where I’m working on it, but there are a few subtleties I want to iron out first. |
@StuartLittlefair – just a ping to see how progress is coming on the two-pass solution. Hope all is well 😄 |
Hi @bmorris3 ! All well here thanks. The status of this is that I've a working solution that is really nice, except that it doesn't handle cases where objects don't rise/set at the moment. The issue is that the first pass returns I'll hopefully get some time to work on this over the next few weeks... |
Hi,
We've been testing the new precision setting in the AstroPlan observer object’s target_rise_time, target_set_time and target_meridian_transit_time functions.
Generally, setting a lower precision drastically reduces the time it takes to run the calculations with only a little effect on the rise/meridian/set times. Our setup used to take over 11 hours and it ran in 3 with a precision of 10 n_grid_points. We only found this difference in precision caused a difference in the rise/set times of a couple of minutes art most. The difference in the meridian could be a little higher but this is understandable with a 'gentle curve' of the target as goes from rising to setting.
What we did find though is quite a large difference in calculations when the declination approaches 90 degrees:
See the larger differnce when Dec is 85. This seems to only start occurring when the Dec is 80deg or above and happens regardless of RA and date.
We think this is caused by the gentle rise/set arc that the target makes at higher declinations. It's not too much of an issue, we can raise the precision to compensate for this if needed and we only use a lower precision for simulations to see how the scheduler runs.
However, if you've any thoughts then we'd be interested to hear them. I've added my test code below. Feel free to have a play:
The text was updated successfully, but these errors were encountered: