Currently, most units are defined in si.py, cgs.py, and astrophys.py. As noted by @adrn in astropy/astropy#10586 (comment), the latter has become a bit of a miscellaneous bunch, including units that are not particular to astronomy at all. It would make sense to move those to a new misc.py. Indeed, some are sufficiently obscure that it might be an idea to allo

Hi. I can imagine calendar options that would allow people to try different types of calendars. For example with lunar calendars like the Chinese, Vietnamese, Hindu, and Thai calendars.
I see this a powerful aid in teaching the importance of calendars and how they can help us relate to cosmic influences.
By the way... stellar work so far!

Lots of sunpy/map/maputils.py assumes that a helioprojective map is being passed. Therefore, if (e.g.) a synoptic map is passed into lots of those functions, I suspect there will be lots of unhelpful errors. We should

• Create a helper function is_helioprojective_map that returns True if a map is helioprojective, False otherwise
• Use this check in maputil functions
• Raise a user-f

Problem

Lightkurve has a lot of unit tests which access the data archive at MAST. This causes a number of problems:

• our tests are slow;
• many of our tests require internet access;
• tests sometimes fail due to intermittent issues at MAST rather than Lightkurve issues;
• we add an unnecessary load on MAST's services.

Current workaround

We have flagged the tests which require inte

The python implementation of leapfrog does not make use of the fact that drifts can be combined when not storing output, causing it to be slower than necessary. Comparing to the C implementation, it also appears to not be as precise.