Attractor surface visibility

[Yash-10]

This is an attempt inspired by section 5.2 ("Direct Visibility of a Planetary Surface") of Escobal's book and uses equation 5.5.

• Trying to find what tests can be included.

As mentioned in the book, this might have application for planetary probes to study some properties of a planet, its composition, atmosphere, etc.

Just added a test to check if it doesn't give any errors.

[codecov]

Codecov Report

Merging #1298 (f48862c) into main (48c854a) will increase coverage by 0.03%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #1298      +/-   ##
==========================================
+ Coverage   92.25%   92.29%   +0.03%     
==========================================
  Files          81       81              
  Lines        4260     4281      +21     
  Branches      358      358              
==========================================
+ Hits         3930     3951      +21     
  Misses        248      248              
  Partials       82       82              

Impacted Files	Coverage Δ
src/poliastro/core/events.py	100.00% <100.00%> (ø)
src/poliastro/twobody/events.py	99.02% <100.00%> (+0.08%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 48c854a...f48862c. Read the comment docs.

[Yash-10]

We had discussed whether the addition of elevation wouldn't get too complicated. It seems we could add the elevation parameter without changing the "visibility function" much, barring some more additional computations.

[astrojuanlu]

I guess this is somewhat related to #1299, could you clarify what are the differences between the two?

[Yash-10]

Satellite visibility aims to detect when a satellite becomes visible from a ground station on an attractor whereas satellite view (here) tries to detect the case when a satellite will be able to view the sunlit part of its attractor. So the satellite view event:

• Doesn't account for any specified ground station.
• Instead, thinks from the point of view of the satellite instead of the ground station.

From Escobal's book:

Hence, the geometry seems to be almost the opposite of the eclipse event

[Yash-10]

As decided earlier, the added test checks eclipse doesn't trigger when satellite view triggers. This might not be as robust as a check since I think there could be situations where neither event is triggered. But such a test could be a good starting point.

I think this is ready to be reviewed.

[astrojuanlu]

I think this is good to go!

[astrojuanlu]

I did a very short-sighted review and @Yash-10 rightly told me that the tests are incomplete. Removing the approval, sorry for the noise 🙏🏽

[Yash-10]

For validating this event, I am trying to use this equation from Escobal's book (Page 155 under Analytics of the Two-body problem):

I believe the variable t would give the event occurrence time. It needs T, the time of latest perigee pass. I am thinking whether what I added is plausible. Below is the diff:

diff --git a/tests/tests_twobody/test_events.py b/tests/tests_twobody/test_events.py
index 898a568a..08de0603 100644
--- a/tests/tests_twobody/test_events.py
+++ b/tests/tests_twobody/test_events.py
@@ -11,7 +11,7 @@ from poliastro.core.events import line_of_sight
 from poliastro.core.perturbations import atmospheric_drag_exponential
 from poliastro.core.propagation import func_twobody
 from poliastro.twobody import Orbit
-from poliastro.twobody.angles import nu_to_E
+from poliastro.twobody.angles import nu_to_E, E_to_M
 from poliastro.twobody.elements import mean_motion
 from poliastro.twobody.events import (
     AltitudeCrossEvent,
@@ -484,11 +484,11 @@ def test_satellite_view_event():
     epoch = Time("2020-01-01", scale="utc")
     coe = (
         6828137.0 * u.m,
         0.0073 * u.one,
         87.0 * u.deg,
         20.0 * u.deg,
         10.0 * u.deg,
         0 * u.deg,
     )
     orbit = Orbit.from_classical(attractor, *coe, epoch=epoch)
 
@@ -515,7 +515,8 @@ def test_satellite_view_event():
     n = mean_motion(orb.attractor.k, orb.a)
 
     # Equation 5.14 from Escobal.
-    expected_view_t = t_perigee + (E - ecc * np.sin(E) * u.rad) / n
+    M = E_to_M(E, ecc)
+    expected_view_t = t_perigee + M / n
 
     assert_quantity_allclose(satellite_view_event.last_t, expected_view_t)

[jorgepiloto]

Hi @Yash-10, you may also use the logic from the t_p property of Orbit class to compute the time since periapsis, see:

poliastro/src/poliastro/twobody/orbit.py

Lines 233 to 244 in 2eb557c

	def t_p(self):
	"""Elapsed time since latest perifocal passage."""
	t_p = (
	delta_t_from_nu_fast(
	self.nu.to_value(u.rad),
	self.ecc.value,
	self.attractor.k.to_value(u.km ** 3 / u.s ** 2),
	self.r_p.to_value(u.km),
	)
	* u.s
	)
	return t_p

[astrojuanlu]

(Renaming this PR for clarity)

[Yash-10]

I wonder if:

• AngularSeparationDetector: https://www.orekit.org/site-orekit-9.0/apidocs/org/orekit/propagation/events/AngularSeparationDetector.html, or
• GeographicZoneDetector: https://www.orekit.org/site-orekit-10.3/apidocs/org/orekit/propagation/events/GeographicZoneDetector.html

could be used somehow for validation?

Also, using the above equation from Escobal was a bit tough for me. Even though one could get the eccentric anomaly and mean motion at the event instance, getting the time of perifocal passage (and not since the perifocal passage) is still confusing. One idea might be to get the time of perifocal passage from the orbit epoch.