Search for previous moon conjunction

[hidp123]

Using the following code I can search for the next moon conjunction, but can I search for the previous one as well? I tried putting in a negative value but it returned None.

new_moon = astronomy.SearchMoonPhase(0, astronomy.Time.Make(2022, 9, 25, 0, 0, 0), 35)

I guess I can use the adddays function to take the date back a few days?

[cosinekitty]

This is a great question. I had not thought about searching backwards in time, but I can understand why that would be useful. This can be a little tricky for it to always work without accidentally skipping over a new moon.

Just to get your code working for now, I would suggest this: search for the next new moon after the starting time t. Then take the result, subtract 35 days (using AddDays like you said), and search for the next new moon after that. This should always find the most recent new moon before time t.

This will work, but it's not as efficient as it should be. So I will think about how I can support backward searches for lunar phase events. I like your idea that the limitDays argument could be negative to indicate the caller wants a reverse search. That way I don't have to break the existing interface.

[hidp123]

Thanks

A somewhat related question:

The above method allows searching for the new moon geocentric-ly (i.e. when the difference in longitude between the Earth's centre, the sun and the moon is zero), in addition to this, how can I search for the new moon based on a given location (i.e. the topocentric longitude difference is zero)?

[cosinekitty]

That is an interesting one. There is no ready-made function to do this currently. That is the bad news. The good news is it shouldn't be too hard to make one. Here is the approach I suggest:

1. Find the geocentric new moon. Then we can assume the topocentric new moon will be within plus or minus a few hours of the geocentric full moon.
2. Use the generic Search function, passing in t1 = newmoon - (0.5 days), t2 = newmoon + (0.5 days). The func and context parameters will be crafted to return the difference of ecliptic longitudes of the Sun and Moon as seen by the topocentric observer, such that the number is negative at t1 and positive at t2. The search will find when the function ascends through zero, which is the time of the topocentric new moon.

To get a better understanding of how to do this, look at the line of code where SearchMoonPhase calls Search. You need to create a function like _moon_offset that returns the topocentric longitude difference rather than the geocentric difference. It will probably be helpful to pass in the observer object as the context parameter for the search, which gets passed to your custom function.

I can help you with this, but it may take a while. I live in Florida USA, and right now we have a hurricane coming directly toward us! I'm in the middle of preparing for that. It is possible I will also lose internet service at some point. But hopefully this is enough to get you started.

Also, I have already made a separate branch for this repo called reverse_search in which SearchMoonPhase works forward or backward in time. Feel free to experiment with that! Following your idea, you pass in a negative value for limitDays (I recommend -40.0) to search backwards. I believe there will be other search functions that can benefit from the same kind of enhancement. Once I work through all of them, I will merge into the master branch and release a new version.

[matheo]

@cosinekitty thanks for all the great stuff and suppoort and please take care! best wishes for you

[hidp123]

I can help you with this, but it may take a while. I live in Florida USA, and right now we have a hurricane coming directly toward us! I'm in the middle of preparing for that. It is possible I will also lose internet service at some point. But hopefully this is enough to get you started.

No worries, stay safe and all the best!

[hidp123]

Also, I have already made a separate branch for this repo called reverse_search in which SearchMoonPhase works forward or backward in time. Feel free to experiment with that!

I have played with this (reverse moon phase search) and it works well. Thanks!

[cosinekitty]

I'm glad SearchMoonPhase is working for you! I am in the process of making SearchRiseSet, SearchAltitude, and SearchHourAngle all work forward or backward in time. They are all related, so it makes sense to do them together. Once I get those working in all languages, I will release another version.

[cosinekitty]

Thanks, guys!

Here are the other functions that could be adapted to a reverse chronological search by allowing a negative value for their limitDays parameter:

• SearchSunLongitude
• SearchRiseSet
• SearchAltitude

Here are functions which would require changes/additions to the interface:

• SearchMaxElongation
• SearchMoonQuarter / NextMoonQuarter
• SearchRelativeLongitude
• SearchHourAngle
• SearchPeakMagnitude
• SearchLunarApsis / NextLunarApsis
• SearchPlanetApsis / NextPlanetApsis
• SearchLunarEclipse / NextLunarEclipse
• SearchGlobalSolarEclipse / NextGlobalSolarEclipse
• SearchLocalSolarEclipse / NextLocalSolarEclipse
• SearchTransit / NextTransit
• SearchMoonNode / NextMoonNode

This would be a lot of work, with uncertain usefulness. My intuition is that SearchRiseSet would be the most useful one to allow searching backwards in time. In most of these functions, I had envisioned a use case like this: someone wants to create a calendar, and you start at January 1 of the year and work forward to find all the interesting events. I'm open to feedback on a case-by-case basis about wanting reverse search for solving particular problems.

[hidp123]

I think:

• those that require no extra work, or only minimal work then enable reverse search functionality for them.
• those that require more work then only enable it based on usefulness, or user request.

Also note: a lot of times it is only the most recent event which is sought for, not all previous events in backwards order.

Reverse in the following I think maybe useful, at least finding the most recent event (however, I've not used all of them to have a definitive say on them):

• SearchMoonQuarter
• SearchRiseSet
• SearchPeakMagnitude
• eclipses

[hidp123]

Also, regarding geocentric and topocentric, there are a number of functions that could benefit from this dual choice of geo and topo output (based on user choice). Some where I will hopefully be using both are:

• RA & DEC.
• ecliptic lat & long.
• elongation.
• phase angle.
• new moon.
• angular diameter (significant mainly for the moon, and to a lesser degree for the sun).
• crescent width.
• distance.

PS. You may want to move this to another discussion.

[cosinekitty]

This is all very good feedback. As far as RA/DEC, we already have topocentric support through the Equator function. The Ecliptic function will correctly convert a topocentric vector from equatorial to ecliptic. I believe all the other items above will matter most for the Moon. Topocentric parallax for the Sun will be tiny (8.8 arcseconds max).

However, in many cases, avoiding breakage of existing code would require creating new functions that accept an observer parameter. If I do this, in many cases it would be no extra work to support all bodies, not just the Moon.

But this would be quite a lot of work, so it's better to postpone until there is a demonstrated need. I may prefer to help you implement some of these outside Astronomy Engine, to reduce the overall workload (documentation, unit tests, etc, across all 5 languages), if the judgment is that most users don't need the extra functionality to justify it.

For specialized topics that might benefit a minority of developers, a compromise is to provide a demo program in this repo that shows how to do something special without changing the core library. So let's keep that in mind as a possibility.

So yes, let's keep the discussion going, and keeping it here is fine with me. Later on, I may change the name of this discussion to better reflect what it ended up being!

[ebraminio]

Just to note, @hidp123 and I, are already using negative limitDays you provided, thanks for unblocking us again, our output now almost matches those publicly provided ones maps like this we were (at least I was) once clueless on how to generate.

[cosinekitty]

That's great! Meanwhile, I believe I have finished enhancing the following 3 functions in all 5 programming languages:

• SearchRiseSet
• SearchAltitude
• SearchHourAngle

I want to add a little more testing to verify special cases before I merge into the master branch.

[cosinekitty]

Now officially released as Astronomy Engine version 2.1.4.